Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Feature Proposal] Information Board node type

Open
  • Is something wrong?
#3,535 1 comment 2 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
c
Domain
backend

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
C
Stars
3.9k
Forks
1.5k
Avg merge
1d 1h
Merged PRs (30d)
26

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from meshcore-dev/MeshCore

All issues in meshcore-dev/MeshCore

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.