Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

[Feature Proposal] Information Board node type

未关闭
#3,535 1 条评论 2 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
c
领域
backend

调研方向

The proposal does not identify implementation files or tests. Start by reading the existing node type advert, ACL/admin, and article or message transfer code to understand where this feature would fit. Done means administrators can manage articles and users can browse and fetch versioned articles on demand, with caching, resumable transfers, and reboot behavior as described.

由索引模型根据 Issue 内容生成。

描述

Idea

Add a new node type, Information Board, for persistent administrator-published notices that users can browse and fetch on demand.

Possible uses include community information, events, emergency notices, schedules, and service announcements.

How it would work

The main goal is to keep radio traffic low.

ADVERT
  board_revision
      ↓
revision changed?
      ↓ yes
GET_INDEX
      ↓
ID + version + title
      ↓
user selects article
      ↓
GET_ARTICLE

The board does not push article bodies.

Clients cache articles locally and only fetch an article when its version differs from the cached version.

Example index:

137  v4  "Water shutoff Saturday"
136  v1  "Road work"
132  v7  "Meeting point changed"

If the client already has:

137 v4
136 v1

those articles require no radio traffic.

Advert

Suggested node type:

#define ADV_TYPE_INFO_BOARD 5

Advert contains a compact board revision:

ADV_TYPE_INFO_BOARD
name = "Community Info"
board_revision = uint16

Client logic:

same revision      -> use cache
different revision -> fetch index

No long hashes need to be transmitted.

Wrapping versions

Both board revisions and article versions use:

1 ... 65535 -> 1

0 is reserved.

Clients only compare for equality, never > or <.

So this works naturally:

cached revision = 65535
advert revision = 1

different -> fetch index

Each article has:

article_id       uint32
article_version  uint16

Editing an article keeps its ID but increments its version.

Article transfer

When selected:

GET_ARTICLE
article_id
expected_version
offset

Including the version and offset makes transfers stateless and resumable.

If an article changes during transfer:

VERSION_CHANGED
current_version = ...

and the client restarts the download.

Index consistency

If the index is paginated, each page request includes the board revision.

If the board changes between pages:

INDEX_CHANGED

and the client restarts the index fetch.

Reboots

A normal reboot keeps:

board_revision
article_versions
article_ids

so clients do not see a false change.

A separate board_epoch can identify a factory reset/new database. If the epoch changes, clients discard the old board cache and fetch everything again.

Administration

Normal users have read access.

Administrators can:

CREATE_ARTICLE
UPDATE_ARTICLE
DELETE_ARTICLE

Ideally this would reuse existing MeshCore ACL/admin mechanisms.

Why this stays radio-efficient

Typical flow:

hear advert
revision unchanged
-> send nothing

revision changed
-> fetch compact index

most article versions still match cache
-> send nothing for those

user opens one changed article
-> fetch only that article

So traffic is mostly limited to compact metadata plus the specific content users actually request.

主要语言
C
星标
3.9k
派生
1.5k
平均合并
18 小时 59 分钟
30 天内合并 PR
28

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南,环境需要你自己搭建:先看它的 README,通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

meshcore-dev/MeshCore 的其他 Issue

查看 meshcore-dev/MeshCore 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。