mirror of
https://github.com/MeshEnvy/lobbs.git
synced 2026-10-31 02:11:59 +01:00
36 lines
2.0 KiB
Plaintext
36 lines
2.0 KiB
Plaintext
---
|
|
description: LoBBS project context. Greenfield on-firmware BBS for Meshtastic + MeshCore, plugin + thin forks
|
|
alwaysApply: false
|
|
---
|
|
|
|
# LoBBS
|
|
|
|
Cross-platform, on-firmware BBS for **Meshtastic** and **MeshCore**. Greenfield: no backward compatibility, no legacy code paths. Delete rather than dual-path, simplify rather than preserve old APIs.
|
|
|
|
## Architecture
|
|
|
|
**Plugin owns everything, forks stay upstream.**
|
|
|
|
1. **Plugin** (this repo, PlatformIO library): `core/` (kernel), apps, LoScalar, LoDB, LoFS, protocol, and platform providers under `platforms/` (`meshtastic`, `meshcore`, `native` for CI only). Product platforms are Meshtastic and MeshCore only. On MeshCore the plugin owns the BBS integration surface (`lobbsMeshCoreInit`, DM helpers); the fork wires example chat.
|
|
2. **Firmware forks** (`../lobbs-meshtastic-firmware`, `../lobbs-meshcore-firmware`, both on `lobbs`): upstream plus a thin overlay that pins the plugin in `lib_deps`. The Meshtastic fork enables LoBBS on every env.
|
|
|
|
The repos are siblings under `/Volumes/Code/repos/meshenvy/`. No submodules anywhere: PlatformIO clones git deps with `--recursive`, and MeshForge builds a fork repo alone.
|
|
|
|
Meshtastic fork pulls this repo through `lib_deps` (see `../lobbs-meshtastic-firmware/lobbs-overrides.ini`).
|
|
|
|
## Fork diff policy
|
|
|
|
- Allowed: fork overlay files (`lobbs-overrides.ini`, `lobbs.local.ini.example`, gitignored `lobbs.local.ini`) and minimal upstream edits listed in fork README.
|
|
- No edits to upstream files. If an extension point is missing, make the smallest possible change, list it in [`README.md`](README.md), and open an upstream PR.
|
|
|
|
## Pins and releases
|
|
|
|
Local dev uses a gitignored `symlink://../lobbs` override. Committed fork config only ever pins a plugin commit. Tagging and pin procedure: [`release.mdc`](release.mdc).
|
|
|
|
## Style
|
|
|
|
- Bad: keep `#ifdef LEGACY_…` branches "just in case".
|
|
Good: delete the old path.
|
|
- Bad: grow BBS logic inside a firmware fork.
|
|
Good: implement it in the plugin; the fork only selects the env.
|