Entscheidung: Relay-Implementierung Rust (groups_relay) oder Go

[usekaneo]

Gesetzt ist: das eigene Relay ist die Autorität, ab Phase 4 läuft verse-pbc/groups_relay (Rust). Offen ist nur noch die Frage, ob es dabei bleibt oder max21dev/groups-relay (Go) besser passt — relevant, sobald wir das Relay selbst patchen wollen.

Zu entscheiden: vor dem Produktiv-Deployment, weil Betrieb und Patch-Fähigkeit daran hängen.

Quelle: docs/11-open-questions.md Frage 4, docs/08-relay-setup.md

---

_{Task: fhc527l12ptf82r2uepz1ph5}

[usekaneo]

CON-24

[usekaneo]

**** commented:

Technical refinement (decision ticket)

Status: the decision stands and needs no code. What it lacks is an explicit, testable exit condition and a conformance baseline, so that 're-evaluate later' does not become 'forgot about it'.

What the decision commits us to

• verse-pbc/groups_relay (Rust, AGPL-3.0) stays the authority relay. It is a single binary, verified against phases 1-5, and enforced the invite-only model when CON-22 was implemented.
• The two things it deliberately leaves open are now separate: (1) no relay-wide member allowlist, (2) attachments outside the group boundary — the latter is CON-26 and no longer a reason to switch.
• A relay swap is not a config change: the relay defines what NIP-29 means. Every measurement in docs/04 (private groups serve nothing to a non-member even after AUTH; restricted rejects non-member writes; apply_tags is additive; supported_kinds behaviour; ephemeral handling; NIP-09 in groups; 9021 behaviour) would have to be redone.

Where it actually stands today

• Enforcement was measured, not assumed (docs/04, CON-22): a stranger without AUTH reads 0 events; a stranger with valid NIP-42 AUTH but no membership still reads 0 1818; publishing as a non-member is rejected with restricted: User … is not a member of this group. That is the core of the security posture and it holds.
• The missing second line of defence is real but bounded. Without a connection-level allowlist, an authenticated non-member can still connect, read the NIP-11 document and be silent about everything else. They cannot read content and cannot write. A relay-wide allowlist (Buzz's BUZZ_REQUIRE_RELAY_MEMBERSHIP / BUZZ_PUBKEY_ALLOWLIST) would reject the connection earlier and give a place to hang abuse controls — defence in depth and operations, not confidentiality that is missing today.
• Known gaps to keep on the list: no NIP-29 timeline references (previous, also CON-17); no built-in file store (CON-26 stands on the dev server; production is CON-4); no relay-wide allowlist; AGPL-3.0 (matters if we ever patch and distribute); a native build needs tokio_unstable.

Exit conditions (make them explicit)

Re-open the choice if any of these becomes true:

1. connection-level protection is wanted (abuse, a stricter threat model, or an org policy),
2. groups_relay proves insufficient in operation (crashes, data loss, no export, unacceptable limits),
3. we want to work on the relay source anyway — then Rust vs. Go returns (docs/11 Q4) and buzz-relay (Apache-2.0, NIP-29 + NIP-42 native, Blossom built in) becomes the leading candidate.

Next steps (no relay switch needed to do them)

1. Freeze the conformance baseline. Turn the CON-22 measurements into a repeatable script (scripts/relay-conformance.sh): NIP-11 supported_nips contains 29; unauthenticated read is empty; authenticated non-member read is empty; non-member write is rejected; the three invite-only flags are present and additive. Any future relay — or a relay upgrade — is validated against this before anything is called supported.
2. Record the gaps in one place (docs/08 'Operations' or a short docs/14-relay-evaluation.md), each with 'does this block us?'. The Blossom gap already has CON-26/CON-4; the allowlist gap deserves its own line and, if pursued, its own ticket.
3. Decide the allowlist question on its own merits. It is independent of the relay choice: either patch groups_relay (AGPL obligations, Rust) or adopt buzz-relay (Apache-2.0, but a full re-measurement). A spike comparing both against the conformance script is the honest way to decide.
4. Operational readiness belongs to CON-4: supervision, backup/restore, monitoring, disk — the relay choice does not remove those.

Subtasks

• scripts/relay-conformance.sh encoding the CON-22 measurements
• Update docs/11 Q4 and docs/08 with the decision, date and the exit conditions
• List the known gaps with 'blocks us? yes/no' (allowlist, previous, file store, license, build flags)
• Optional spike: connection-level allowlist via patch vs. buzz-relay, judged by the conformance script
• Note AGPL-3.0 consequences before any relay patch is distributed

Acceptance criteria

• The decision and its exit conditions are written down where the next reader finds them.
• The conformance script exists and passes against the current relay, so a swap is a measured decision, not an opinion.
• The allowlist gap is either scheduled as its own ticket or explicitly accepted.
• Nothing in this ticket changes application code.

Risks / notes

• Coupling: choosing a relay also chooses file storage, ephemeral semantics, license and language. Do not decide the allowlist in isolation from those.
• Re-measure everything on a swap — flags mean what the implementation says, not what the NIP says (docs/04 already makes this point).
• Documentation drift is the main failure mode of a 'leave it as is' decision; the conformance script is what keeps it honest.

Depends on / relates to

CON-22 (measurement, done), CON-26 (attachments, In Review), CON-4 (production deployment and operations), CON-17 (previous), docs/11 Q4, docs/08.