Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[Feature Proposal] Information Board node type

オープン
  • 何か問題がありますか？
#3,535 コメント 1 件 リアクション 2 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
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分
マージ済み PR（30日）
28

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

meshcore-dev/MeshCore のほかの issue

meshcore-dev/MeshCore の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。