Usenet-Semantik
mit SMS-Ökonomie.
Kernthese: Das Mesh trägt nicht die Nachrichten, sondern die Existenzbehauptung. Damit wird das Funk-Budget zu einer Funktion der Ereignisrate, nicht der Datenmenge. Maus/ZConnect-Semantik, IPFS-Datenmodell, Reticulum-Transport. Leitprinzip: Robustheit siegt.
Das Problem
Es existiert kein System, das strukturierte, threaded, asynchrone Diskussion über Funk trägt. Vorhandene Ansätze decken je eine Hälfte ab.
| Ansatz | Kann | Fehlt |
|---|---|---|
| Meshtastic | Transport | Channels ohne Threading, ohne IDs, ohne Historie |
| Meshtastic Store & Forward | Puffern | keine Brettstruktur, keine Abos |
| TC²-BBS / meshing-around | BBS-Semantik | kein differenzieller Sync, keine Duplikat-Erkennung |
| MeshCore | Room-Server mit Historie | kein Abo-Modell |
Was fehlt, ist exakt das, was MausTausch/ZConnect ab 1986 gelöst hatte: global eindeutige Message-IDs, Referenzketten (REF:) für Thread-Rekonstruktion ohne Vollhistorie, Duplikat-Erkennung und selektive Abos pro Brett. Nur war damals die Kostenfunktion Telefongebühr — heute ist sie Airtime.
Zwei Nachrichtentypen, zwei Ökonomien
Der Anreiz für Kurznachrichten ist Publikum, nicht Preis. Wer BEACON postet, wird von Nur-Mesh-Teilnehmern nicht gelesen. Soziale Sanktion, kein Enforcement nötig.
| INLINE | BEACON | |
|---|---|---|
| Inhalt | 140 Zeichen, im Paket | Teaser + CID, Volltext im Fettnetz |
| Größe | ~76 B | ~108 B |
| Mesh-Kosten Autor | 1 Paket | 1 Paket |
| Mesh-Kosten Leser | 0 | 1 Paket + Fetch |
| Lesbar ohne Internet | ✓ ja | ✗ nein |
| Reichweite | alle Teilnehmer | nur Fettnetz-Klasse |
Brett = Regelraum
Ein Brett ist nicht nur Sortierung, sondern deklariert die geltende Ökonomie. Policy ist ein signiertes IPLD-Objekt; der Node prüft eingehende Nachrichten dagegen. Verstoß = Drop, kein Relay.
/DE/COMP/MESH/CHAT accept: INLINE /DE/SCI/PAPERS accept: INLINE, BEACON | max_size: 512K /DE/REGIO/BERLIN accept: INLINE, BEACON | max_size: 64K | beacon_quota: 3/Tag/Autor
Architekturentscheidungen (fixiert)
| # | Entscheidung | Folge |
|---|---|---|
| A4 | Alltagsnetz (nicht Notfallnetz) | Retention, Moderation, Identität sind Pflicht. Hubs brauchen 24/7 + Solar. |
| A3 | Teaser fließt in die Content-CID | Beacon manipulationssicher. Fälschung erst beim Fetch erkennbar → Relay-Reputation nötig. |
| A2 | LXMF / Reticulum als Transport | Krypto + Routing geschenkt. Duty-Cycle-Scheduling nicht enthalten → Eigenbau. |
| A1 | Duty-Cycle 1 % (kein LBT/AFA) | ~720 Pakete/Tag/Node bei SF11. Hub-Fan-out hart auf ~8–10 Nachbarn begrenzt. |
| B1 | Single-Parent | Robustheit vor Ausdrucksstärke. Multi-Parent verworfen. |
| B2 | INLINE/BEACON auf Brett-Ebene | Erzieht statt zu flexibilisieren. |
| B3 | Merkle-Batch-Signaturen | Kein BLS/Pairing-Krypto auf dem Mikrocontroller. |
| B4 | Volle CIDv1 (32 B) | +20 B/Beacon, dafür echte IPFS-Interop ohne Mapping-Layer. |
Der Stack
┌──────────────────────────────┐ │ NNTP-Frontend │ ← beliebiger Newsreader ├──────────────────────────────┤ │ Brett-Logik, Abo, Retention │ ← neu (brettd) ├──────────────────────────────┤ │ IPLD dag-cbor + CIDv1 │ ← IPFS-Datenmodell ├──────────────────────────────┤ │ Minisketch-Sync │ ← Bitcoin Erlay ├──────────────────────────────┤ │ Reticulum LXMF │ ← Transport, Krypto ├──────────────────────────────┤ │ LoRa PHY │ └──────────────────────────────┘
IPFS: was übernommen wird
CIDv1 / Content-Addressing und IPLD / dag-cbor — der REF-Baum ist ein Merkle-DAG. Pinning als Abo-Modell definiert die Hub-Rolle formal: ein Hub ist ein Pinning-Service mit Airtime-Budget. CID-Referenzen für Long-Form sind eine kostenlose Internet-Brücke.
Was nicht: Kademlia-DHT (O(log n) Round-Trips à 3 s = Minuten pro Lookup), libp2p/IPNS (Handshake sprengt das Budget). Bitswap nur im Fettnetz. Der Bruch zwischen Funk und Netz liegt exakt an der Schichtgrenze, an der IPFS ihn ohnehin hat.
Wire-Format
{
b: h'a3f1', // 2 brett
c: CID(32), // 34 content-adresse
p: CID(32), // 34 parent (single)
a: h'9c2e4b81', // 4 autor-prefix
t: 29184301, // 4 ts, Minuten
s: 3400, // 2 size hint
x: h'...' // ~28 teaser, ~40 Zeichen
}
Die CID ist die Integritätsgarantie
Keine Signatur im Beacon — Autorenechtheit kommt aus dem Content-Block (dort ist Platz für 64 B Ed25519). INLINE (~76 B): der Body ist der Block, keine Content-CID nötig — deutlich billiger als BEACON.
Kompression
Bei 140-Zeichen-Strings ist ein vortrainiertes Dictionary die gesamte Kompression — LZ77 findet in 140 Bytes nichts. Das Zeichenlimit ist damit eine abgeleitete Größe: die Grenze steht in Bytes nach Kompression, das Limit in Zeichen davor. inline_max folgt aus Messung M3, nicht umgekehrt.
Ein Dictionary ist ein content-adressiertes IPLD-Objekt (kein zentrales Enum), trägt einen 4-Bit-Index im Header zur Selbstbeschreibung, ist ein Domänen- statt Sprachobjekt, und der Kompressor lehnt nie ab — Mischsprache wird schlechter komprimiert, das ist alles. Die Physik sanktioniert, nicht die Policy.
Sync: Minisketch statt Push
ZConnect/Fido machten Push mit Wasserzeichen — das setzt geordnete, verlässliche Verbindungen voraus. LoRa hat weder Ordnung noch Verlässlichkeit. Stattdessen: Set-Reconciliation über IBLT/Minisketch.
Node A Node B
|-- SYNC_REQ(brett, sketch[128B], T-7d) ->|
| | decode(sketch_A XOR sketch_B)
|<-- SYNC_RESP(will={CID5}, sende={CID3,7})|
|-- BEACON(CID5) ------------------------->|
|<-- BEACON(CID3), BEACON(CID7) -----------|
Ein Sketch von 128 B rekonstruiert eine Differenz von bis zu ~8 Einträgen — unabhängig davon, ob das Brett 100 oder 100.000 Nachrichten enthält. Vollständiger Wochenabgleich bei typischer Differenz: ~7 Pakete ≈ 20 s Airtime bei SF11. Ein Node hält dutzende Bretter im Tagesbudget synchron.
Der Pager-Zustandsautomat
BEACON empfangen (Mesh) │ ├─ Brett abonniert? ──nein──→ DROP ├─ CID bereits lokal? ──ja──→ DROP (dupe) ▼ WANTLIST += CID │ [warten. Minuten. Stunden. Tage.] ▼ Fettnetz da? ──nein──→ Teaser bleibt sichtbar ▼ BULK FETCH → IPFS-Gateway / Hub ▼ Verify CID → Ed25519 → in DAG → Volltext
| Zustand | Kanal | Erfahrung |
|---|---|---|
| Nur Mesh | LoRa | sieht dass diskutiert wird, plus Anriss |
| Mesh + Gateway | LoRa + Uplink | Volltext auf Anforderung, mit Wartezeit |
| Fettnetz | WLAN/LTE | normales Forum |
Die CID ist in allen drei Zuständen dieselbe — kein Merge, keine Versionierung, der DAG wächst nur. Das Beacon ist ein Versprechen, die CID der Vertrag.
Topologie
[Uplink-Gateway] ←── Internet / IPFS │ (LoRa, SF7, Dachantenne) ┌─────┴─────┐ [Hub-West] [Hub-Ost] ← S&F, 24/7, Solar, max 8 │ │ │ │ [N] [N] [N] [N] ← Endnodes, opportunistisch
Die Hierarchie ist keine Bequemlichkeit, sie ist die Kostenfunktion. Ein flaches Mesh, das jede Nachricht überallhin flutet, verbrennt das Budget quadratisch. Fido hatte Zonen/Netze/Nodes aus demselben Grund — nur hieß die Währung damals Ferngespräch.
Konsequenz aus A1 und dem Fan-out-Deckel: Ein Stadtnetz braucht viele Hubs, nicht große.
Duty-Cycle-Governor: LXMF vs. 1 %
LXMF/Reticulum kennt Link-Establishment, Retries, Announces — aber keine Airtime-Buchhaltung. Der RNode-Layer droppt statt zu verzögern. Genau falsch: ein gedroppter Beacon ist verloren, ein verzögerter kommt an. LXMF ist opportunistisch, Duty-Cycle ist deterministisch — unvereinbare Scheduling-Philosophien.
| Endnode | Hub | |
|---|---|---|
| Nachbarn | 1–2 | bis 8 |
| Sendevolumen | gering | am Limit |
| Uptime | sporadisch | 24/7 |
| Lösung | LXMF vanilla | DutyCycleInterface |
An der Schichtgrenze, an der Airtime physisch entsteht. Sieht jedes Paket, auch Reticulums Eigenverkehr:
Warum kein Governor über LXMF: Reticulums Eigenverkehr (Announces, Path-Requests, Handshakes) frisst grob 20–40 % des Budgets bei 8 Nachbarn — ein Governor darüber verwaltet 60 % und glaubt, es seien 100. Der Preis von A2 ist dieser Governor — Eigenbau und der wahrscheinlichste Ort für Feldtest-Überraschungen.
Governance
| # | Frage | Entscheidung |
|---|---|---|
| C1 | Wer darf Hub sein? | Betreiber-Liste + Web-of-Trust. Offen geht nicht: 8 Nachbarplätze sind Sybil-Ziel. |
| C2 | Retention | Pro Brett in der Policy: retain: 180d / retain: pinned. Hub erzwingt. |
| C3 | Rate-Limiting | Token-Bucket pro Autor-Prefix, im Protokoll. Bei 720 Paketen/Tag existenziell. |
| C4 | Wer legt Bretter an? | Ein Brett existiert, wenn ein Hub seine Policy pinnt. Fidos Zonenkoordinator ohne Titel. |
MVP-Scope & Messungen
M1 — Announce-Overhead
2× RNode, 24 h, 8 simulierte Nachbarn. Ohne diese Zahl ist jedes Budget geraten. < 15 % → Governor über LXMF verteidigbar; darüber → DutyCycleInterface alternativlos.
M2 — RNS-Timeout-Toleranz
Wie lange darf ein Interface verzögern, bevor Links reißen? Bestimmt die maximale Queue-Tiefe.
M3 — Kompressions-Bake-off
Brotli vs. Zstd --train vs. Token-Huffman. Metrik: Rate im 5. Perzentil. Bestimmt Kompressor und inline_max. Vorentscheidung: Zstd.
Bekannte Risiken
| Risiko | Bewertung |
|---|---|
| A2 + A1 ist der wunde Punkt | LXMF weiß nichts von Duty-Cycle. Governor ist Eigenbau. |
| Fan-out 8 | Begrenzt die Topologie stärker als die Physik. Viele kleine Hubs statt weniger großer. |
| Asymmetrische Sichtbarkeit | Zwei Klassen in derselben Diskussion. Jemand antwortet auf einen Teaser, ohne den Volltext gelesen zu haben. Kulturell heikel. |
| Wantlist-Wachstum | 3 Monate ohne Fettnetz = tausende CIDs. Braucht Priorisierung + Verfall. |
| Kein Realtime | Nachbar-Brett in Minuten, entferntes in Stunden. Maus-1991-Verhalten — heute Duty-Cycle statt Modem-Latenz. |