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

Implement the announcement channel (kind 38387)

Open
  • Is something wrong?
#319 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
dart, rust
Domain
backend, mobile

Research direction

Read specs/006-announcement-channel/spec.md, especially §3, §4.1, and §10. Start with step 1: parsing, validation, and the allowlist as pure functions, without relay, database, or UI work. Use the spec’s required test cases to check completion; the issue does not name implementation files.

Written by the indexing model from the issue text.

Description

area: notifications area: rust-core feature priority: low

What

Give the project one authenticated way to reach people already running the app — "2.1 is out and fixes X", "the node is down for maintenance tonight", "this relay is being retired" — without a backend, an account, or a push token.

Announcements are signed Nostr events (kind 38387) published from a small allowlist of project keys compiled into the app. The signature is the whole trust model: a hostile relay can withhold or stale an announcement, but cannot forge one. They render in the notification surface that already exists — no new screen, no new bell.

Full specification

specs/006-announcement-channel/spec.md — event contract, trust model, freshness and expiry rules, severity levels, consent, publishing, and the test cases each phase owes. Read it before starting; the details below are only the shape of the work.

Wire contract: MostroP2P/protocol#56 (registers the kind — should land before the reader ships).

Shape of the work

Almost all of it is Rust: parsing, allowlist, verification, freshness and storage are protocol work. Dart only renders what Rust hands it.

Build order from §10 — one PR per step, and the off switch ships before the surface:

  1. §3 parsing and validation + the §4.1 allowlist, as pure functions — no relay, no DB, no UI
  2. Fetch, verify, freshness, expiry, the announcements table (SCHEMA_VERSION 3 → 4)
  3. Bridge surface + the Announcements toggle, then ./scripts/frb-generate.sh
  4. Rendering into the existing notification surface, five locales of chrome
  5. rust/src/bin/announce.rs — the publisher validator
  6. Add the real npubs — one line, its own PR

Steps 1–5 all merge without the channel existing in production: the allowlist ships empty, and an empty allowlist opens no subscription. Step 6 is the only commit that makes it live.

Blocked on a decision, not on code

Where the announcement key lives. §4.1 requires a dedicated key, kept offline, that is neither a maintainer's personal key nor a Mostro node key. Nothing can be published until that exists — but it blocks step 6 only, not steps 1–5.

Not in scope

Real push (FCM), background relay subscriptions, targeted messages to a particular user or node operator, any inbound path, and node-authored announcements. §11 says why for each.

Dominant language
Dart
Stars
11
Forks
9
Avg merge
13h 4m
Merged PRs (30d)
259

Getting set up

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 MostroP2P/app

All issues in MostroP2P/app

Similar issues

More Dart issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.