CARDBOARD PROTOCOL / PROJECT DOSSIER
KAYA CLI
Physical proximity as temporary digital infrastructure.
Chapter 01
The Trigger
The cloud was treated as mandatory, even when everyone was already in the same room.
Before the interface, there was a simpler question: why should two nearby devices need a distant server?
FIELD OBSERVATION
People can be in the same room, connected to the same network, and still depend on a server thousands of kilometres away to speak to each other.
The first question was not how to build another messaging interface. It was whether the cloud needed to exist in the loop at all.
The inherited route
- 01Device
- 02Internet
- 03Cloud
- 04Central identity
- 05Internet
- 06Device
Chapter 02
The Hidden Assumption
Communication systems assume permanent infrastructure for groups that may only be temporary.
ASSUMPTION
Permanence
Accounts are permanent. Servers are permanent. Identity is centralized. But many human groups are temporary.
KAYA starts from the opposite model: the digital space appears when the group appears and fades when the group leaves.
Boundary after removal
- 01Peer
- 02Local network
- 03Peer
Chapter 03
The First Model
Prove local presence, rooms and messaging before investing in a broader interface.
PROTOCOL
Smallest credible system
- Automatic LAN peer discovery
- Public rooms and direct messages
- Terminal interface
- No login, cloud or central server
Why terminal-first
The terminal kept the binary light, the state inspectable and the interaction model visible on modest hardware.
It was a product decision: prove the network and command model before paying for GUI complexity.
Chapter 04
The Friction
The first model worked only while the network behaved like the diagram.
REWORKED
- Multicast can be blocked
- Peers disappear and routes become stale
- Identity without accounts still requires trust
- Secure direct messages require cryptographic sessions
- File transfers and reachability can fail
- Public rooms and secure DMs have different security properties
The first model worked only under an ideal network.
The real problem began when the network stopped behaving like the diagram.
Chapter 05
The Breakthrough
Preserve local-first as the primary path while adding controlled alternatives.
SYSTEM BOUNDARY
Local remains preferred
Direct TCP, VPN addressing and an optional WAN relay extend reach without redefining the product as cloud-first.
Encrypted payloads may cross intermediate nodes without exposing plaintext. Mesh remains explicitly experimental.
- Trust fingerprints
- Ed25519 and X25519 identity material
- Encrypted DM sessions
- TTL, route scoring and route inspection
- Persistent local configuration and peer cache
Chapter 06
The System
Networking, identity, commands, persistence and UI remain separate concerns.
Rust workspace
app commands direct events
files mesh peer persistence
protocol relay rooms security
shared transport ui sdkRuntime event flow
- 01LAN discovery
- 02Peer state
- 03Room membership
- 04Packet validation
- 05Event bus
- 06UI update
Secure DM flow
- 01Peer identity
- 02Fingerprint
- 03Key agreement
- 04Encrypted session
- 05Selected transport
- 06Recipient decryption
Chapter 07
Trade-offs
Every dependency extends one capability and introduces a visible cost.
Rust + terminal UI
Safety, concurrency, networking control and native distribution.
Trade-off: a terminal interface is not suitable for every end user.
Multicast + optional relay
Multicast minimizes local setup; relay extends reach.
Trade-off: multicast is not universal and relay must not become an invisible central dependency.
Experimental mesh
Mesh explores resilience across local routes.
Trade-off: topology, routing and security become substantially more complex.
Chapter 08
Current Limits
The limitations remain explicit because the system is exploratory infrastructure.
CURRENT LIMIT
- Automatic discovery requires IPv4 UDP multicast
- Mesh routing is experimental
- Public rooms are plaintext
- File chunks are not relayed through mesh
- No general NAT traversal or mobile client
- Cryptography has not received an external audit
- Not a finished production communications platform
Chapter 09
What I Would Change
Future work is framed as disciplined extraction, not as completed functionality.
NEXT EXTRACTION
- Formal protocol versioning and property-based tests
- Stronger threat modelling and external cryptographic audit
- NAT traversal and discovery transport research
- Better observability and chaos testing
- Mobile or desktop client above the SDK
- Resumable file transfer and more precise trust UX
Chapter 10
Technical File
The implementation evidence behind the product thesis.
VERIFIED
language: Rust
runtime: Tokio
ui: Ratatui
identity: Ed25519 + X25519
encryption: ChaCha20-Poly1305
discovery: UDP multicast
reach: direct / optional relay / experimental meshKAYA began as a communication tool. It became an argument: a local network can be social infrastructure, not merely plumbing.
Back cover
A local network can be social infrastructure, not merely plumbing.