flit/MULTI_ROOM_PROBLEM.md

The Multi-Room Peer ID Collision Problem

What's happening

The flit daemon runs one goroutine per trusted peer, and each goroutine opens its own WebSocket connection to the anchor and joins a separate pair room. Both connections authenticate with the daemon's real Ed25519 identity — the same peer ID.

The anchor stores connected clients in a Go map keyed by peer ID:

// waste-go/cmd/anchor/main.go
type anchor struct {
    clients map[string]*client  // keyed by hex peer id
}

func (a *anchor) register(c *client) {
    a.mu.Lock()
    a.clients[c.id] = c          // ← overwrites any existing entry for this id
    a.mu.Unlock()
}

When the Samsung goroutine connects first, clients["c639a691..."] points to the Samsung room WebSocket. When the Laptop goroutine connects a millisecond later, clients["c639a691..."] is overwritten to point to the Laptop room WebSocket. The Samsung entry is gone.

The Samsung room WebSocket is still open. The daemon's read goroutine is still blocked on it. But the anchor no longer routes any messages to it — it's orphaned. When Samsung joins, networkPeerIDs("e1d686b9...", samsung_id) finds no entry for the daemon in that net hash, returns an empty list, logs peers=0, and never sends the daemon a peer-join.

Why it's not a bug in the anchor

The anchor was designed for human-scale use: one device, one room at a time. A single peer ID being in two rooms simultaneously isn't a use case it was built for. The map[string]*client design is correct for that model.

---

Options

Option A — Ephemeral signaling identity per session (recommended)

Generate a fresh Ed25519 keypair for each dialSignaling call. The anchor sees a unique, throwaway ID per room. The real identity is only used inside the WebRTC DataChannel, in the hello message where it matters for security.

Anchor changes: none.

Protocol changes: none at the DataChannel level (hello is unchanged).

PWA change required: the pair-room trustedPeerID filter currently rejects any peer whose signaling ID doesn't match the expected peer ID. Since the daemon now uses an ephemeral signaling ID, the PWA must not filter by signaling ID in pair-room mode — instead, connect to the first peer in the room and rely on hello for identity verification. This is safe:

• The pair room name is hash("flit-pair:" + sorted(idA, idB)) — private to the two parties; not publicly guessable unless you know both real peer IDs.
• hello binds the peer's real Ed25519 identity to the DTLS session, so an impostor can't pass verification even if they discover the room name.

The trade-off: a peer in the wrong room (or a race-condition join) triggers a failed hello instead of being silently ignored at the signaling level.

Summary of code changes:

• dialSignaling: accept a *crypto.Identity parameter (currently does); callers pass a freshly-generated ephemeral identity instead of the real one.
• Session.Join: generate ephemeral identity before calling dialSignaling.
• Session.PeerID(): unchanged — returns the real identity's ID.
• offerByOrder comparison: compare real peer IDs (unchanged).
• PWA transport/flit.ts: in pair-room mode, remove signaling-level ID filter; connect to any peer present in the room and let hello sort out identity.

---

Option B — Daemon-only room (single WS)

The daemon joins one room derived solely from its own real ID:

room = hash("flit-daemon:" + daemon_real_id)

All trusted peers know this room (it's computable from the daemon's public ID). The daemon filters incoming peer-join events against its trusted list. One WebSocket connection, no collision.

Anchor changes: none.

Protocol changes: yes — pair-room name derivation changes for daemon mode. The PWA needs a "connect to daemon" flow that uses hash("flit-daemon:" + daemon_id) instead of pairRoomName(myId, daemonId). Existing QR/pair-room flow is unaffected for non-daemon peers.

Trade-off: all trusted peers share one room — each peer can see the others' peer IDs (via peer-join events from the anchor). For most home setups this is fine; for higher privacy requirements it's undesirable.

---

Option C — Per-peer sub-identity stored in config

For each trusted peer, the daemon config stores a unique Ed25519 keypair used only for signaling into that peer's pair room. The real identity is still used for hello.

[[peers]]
id         = "ba3e38bf..."   # peer's real ID
label      = "Samsung"
signal_key = "aabb1122..."   # daemon's per-peer signing key (hex Ed25519 private key)

The PWA must be told the daemon's per-peer signing key (its public half) to compute the pair room and recognise the peer-join. This means re-pairing every time a new signal_key is generated.

Anchor changes: none. Protocol changes: minor. Pairing complexity: high — effectively adds a second identity per pair.

---

---

Option D — Per-network derived identity (how waste-go solves this)

waste-go/internal/netmgr already has this problem and solves it cleanly:

// waste-go/internal/crypto/crypto.go
func DeriveForNetwork(master *Identity, networkHash string) (*Identity, error) {
    r := hkdf.New(sha256.New, master.privateKey[:32], []byte(networkHash), []byte("yaw2-net-identity"))
    var seed [32]byte
    io.ReadFull(r, seed[:])
    priv := ed25519.NewKeyFromSeed(seed[:])
    return &Identity{privateKey: priv, ...}, nil
}

HKDF(master_private_key, network_hash) produces a deterministic, per-room keypair. Same master key + same room hash → same derived ID, always. Different rooms → different IDs. No collision in the anchor's clients map.

Anchor changes: none.
Protocol changes: none — hello still uses the real identity.
PWA changes: none — the daemon's derived ID is stable per room, so the pair room derivation and trustedPeerID filter are unaffected (they operate on the other peer's ID).
Security: same as before. The derived key signs the anchor challenge legitimately. hello inside the DataChannel still uses and verifies the real Ed25519 identity.

This is the recommended fix. Flit's crypto package needs DeriveForNetwork added (HKDF, same as waste-go), then Session.Join passes the derived identity to dialSignaling instead of the master identity.