hackclub/burrow
1
0
Fork 0
Code Pull requests Releases Packages Activity Actions

Align GTK app with Apple home surface
Some checks failed
Build Rust / Cargo Test (push) Successful in 3m50s
Details
Build Site / Next.js Build (push) Failing after 2s
Details
Lint Governance / BEP Metadata (push) Successful in 0s
Details

Browse source 
Add the GTK home screen, local account store, daemon gRPC wrapper, and embedded Linux daemon startup path so the Linux app follows the Apple client UX and daemon boundary.

Document the GTK parity expectations and update the daemon IPC and Tailnet BEPs with the cross-platform client model.
This commit is contained in:
Conrad Kramer 2026-05-03 17:36:55 -07:00
parent 9244a0476a
commit 97c569fb35
12 changed files with 1861 additions and 110 deletions
Download patch file Download diff file Expand all files Collapse all files

3
evolution/proposals/BEP-0005-daemon-ipc-and-apple-boundary.md
View file

@ -44,6 +44,7 @@ Burrow should formalize one Apple/runtime boundary: Apple clients speak only to
- Keeping control-plane I/O out of Swift UI reduces accidental secret, token, and callback sprawl across app code.
- The daemon boundary makes testing and kill-switch behavior tractable because runtime integration is localized.
- Apple daemon lifecycle ownership must be explicit: either the app ensures the daemon is running before RPC or the extension owns it and the UI surfaces daemon-unavailable state clearly.
- Non-Apple presentation clients should follow the same daemon-first lifecycle pattern: connect to a managed daemon when present, or start a user-scoped embedded daemon before issuing RPCs, without adding platform-local control-plane paths.
## Contributor Playbook
@ -54,6 +55,7 @@ Burrow should formalize one Apple/runtime boundary: Apple clients speak only to
- daemon unavailable behavior
- successful RPC path
- error propagation through the UI
- Keep Linux GTK and Apple clients visually and functionally aligned around the same daemon-backed home surface: Networks, Accounts, Tunnel, and add flows should remain corresponding views over the daemon API.
## Alternatives Considered
@ -63,6 +65,7 @@ Burrow should formalize one Apple/runtime boundary: Apple clients speak only to
## Impact on Other Work
- Governs the Tailnet refactor and future Apple runtime work.
- Governs Linux GTK daemon startup parity where the same daemon API is reused from a user-scoped presentation process.
- Interacts with BEP-0002 control-plane bootstrap and BEP-0003 transport refactoring.
## Decision