twisla/roro9stack
Public Access
1
0
Fork 0
Code Issues 51 Pull Requests 1 Actions 2 Packages Releases 14 Activity

Add domain glossary and initial architecture decisions

Browse Source 
CONTEXT.md captures the roro9stack domain language (Apps, Services,
Mesh Service, Nodes, Channels, Storage rules). ADR 0001 records building
our own firmware that speaks Meshtastic instead of forking it; ADR 0002
records an own widget kit on M5GFX instead of LVGL.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
twisla
2026-10-01 18:25:36 +02:00
co-authored by Claude Opus 5.5
commit 87b6b845fb
3 changed files with 122 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/adr/0001-own-firmware-speaking-meshtastic.md
+11
View File
@@ -0,0 +1,11 @@
# Own firmware that speaks Meshtastic, not a Meshtastic fork
We build our own firmware from existing libraries (PlatformIO + Arduino-ESP32, M5Cardputer/M5Unified, RadioLib, TinyGPSPlus, nanopb with Meshtastic's published protobufs). We implement the Meshtastic protocol ourselves as one pluggable Mesh Protocol, rather than forking the Meshtastic firmware, which already supports this exact hardware.
A fork would give full compatibility on day one, but its architecture is built around being a single-purpose Meshtastic node. That conflicts with our goals: a multi-app OS with a fully custom UX, and room for other mesh protocols (e.g. MeshCore) later.
## Consequences
- We accept partial Meshtastic compatibility at first: text on channels, Direct Messages, node list, position and relaying.
- The phone-app (BLE) API and PKI-encrypted Direct Messages are deferred, and we must re-implement protocol details ourselves.
- Multi-boot with stock Meshtastic via a launcher was rejected: it gives none of our own UX.
docs/adr/0002-own-widget-kit-on-m5gfx.md
+10
View File
@@ -0,0 +1,10 @@
# Own small widget kit on M5GFX, not LVGL
The UI is drawn with M5GFX into an off-screen buffer, using a small widget kit we own: list, text view, line editor, dialog, Status Bar and Toast. We chose this over LVGL.
LVGL would give us ready-made widgets, but it costs roughly 40–60 KB of RAM on a device with no PSRAM. It would also need to coexist with the Mesh Service, the Wi-Fi stack and TLS, and it brings a large learning surface. Most of our Apps are lists and text on a 240×135 screen, and full control of the UX is a primary goal.
## Consequences
- We write and maintain our own widgets.
- Switching to LVGL later would mean rewriting every App's view layer.