feat(relay): accept kind:30621 multi-repo projects at ingest

[wpfleger96]

Buzz renders one card per kind:30617, so a project spanning several repositories has no representation. NIP-MP defines kind:30621 as an addressable container holding a group's name, description, channel binding, and member coordinates. This adds the kind to buzz-core and its structural validation to the relay ingest path.

Event shape

{
  "kind": 30621,
  "tags": [
    ["d", "platform"],
    ["name", "Platform"],
    ["description", "Relay, desktop, and mobile."],
    ["a", "30617:<owner-a-hex>:buzz"],
    ["a", "30617:<owner-b-hex>:buzz-infra"],
    ["buzz-channel", "<channel-uuid>"],
    ["buzz-visibility", "listed"]
  ]
}

Validation at ingest

Rule	Behavior
d tag	exactly one, non-empty (length already bounded by the generic D_TAG_MAX_LEN check)
member a tag arity	exactly 2 or 3 elements per NIP-01's a tag grammar; a 4th element has no defined meaning and is rejected
member a tag coordinate	must parse as 30617:<lowercase-64-hex-owner>:<non-empty-d>
duplicate members	rejected on exact string match of the canonical coordinate
member cap	64, counted over raw a tags
metadata cardinality	at most one each of name, description, buzz-channel, buzz-visibility
metadata length	name ≤ 256 bytes, description ≤ 2048 bytes, buzz-channel ≤ 256 bytes, buzz-visibility ≤ 256 bytes
zero members	valid
unknown tags	ignored

Rejection order is normative so a client can predict which rule fires: d-cardinality → d-empty → member-cap → member-arity → coordinate parse → member-duplicate → metadata cardinality → metadata length.

Design notes

No membership authorization. Members are a tags, so one project may name repositories owned by different pubkeys — the entire point of the kind. That is safe because membership grants nothing: push policy reads a repository's own kind:30617 (api/git/policy.rs) and never a project. buzz-channel is a metadata reference, not a routing directive, so projects are classified global-only.

Owner-only editing is free. NIP-33 addressing keys replacement on (pubkey, kind, d), so one signer can never overwrite another's project. No relay-side permission check exists or is needed, and test_project_same_d_under_two_authors_are_independent pins it.

Duplicates are rejected, not deduped. A relay cannot rewrite tags inside a signed event without invalidating its id and signature, so the alternative to rejection is a stored duplicate-member head that every consumer must apply a first-wins rule to.

The cap is checked before the duplicate set is built. Counting raw a tags rather than distinct coordinates means an event naming one coordinate thousands of times is refused on count, instead of being bounded only by the relay frame limit.

No side-effect handler. Generic NIP-33 replacement and generic NIP-09 coordinate soft-delete already cover replacement and deletion; kind:30621 needs no entry in is_side_effect_kind.

Generic NIP-09 fix carried along

soft_delete_by_coordinate (crates/buzz-db/src/event.rs) previously deleted the live coordinate head regardless of the tombstone's own created_at, so a delayed or replayed a-tag deletion signed between two versions destroyed the newer replacement. NIP-09 scopes an a-tag deletion to versions at or before the deletion request, so the UPDATE now carries created_at <= $5 and handle_a_tag_deletion threads the deletion event's created_at through.

The bug predates kind:30621 and affected every parameterized-replaceable kind on the generic path — kind:30617 repository announcements included — so the fix lands there rather than as a project special case. events.created_at is immutable per row, so the predicate guarantees a tombstone can never erase a version newer than itself; the UPDATE re-evaluates its WHERE clause after any lock wait. Under READ COMMITTED, a same-coordinate replacement racing the deletion may cause the deletion to evaluate before the new head lands, returning Ok(false) — but that outcome is state-identical to the deletion having arrived first, a valid Nostr ordering Nostr never fixes. The return value feeds only a debug log. No coordinate-level lock is needed.

Coverage

32 unit tests in crates/buzz-relay/src/handlers/ingest.rs pin the envelope contract (accept: minimal, cross-owner, zero-member, same repo d under two owners, colon-bearing repo d, cap boundary, unknown tags, relay hint on member a tag, max-length metadata, stranger-owned member, uninterpreted metadata values, non-empty content; reject: every rule above plus valueless d/a tags). A fixture-driven test (project_envelope_validates_all_shared_fixtures) runs every case in the shared NIP-MP.fixtures.json oracle (11 accept + 20 reject) against validate_project_envelope, so any future change that breaks a case turns the test suite red.

6 #[ignore]d e2e tests in crates/buzz-test-client/tests/e2e_project.rs cover behavior that only exists past storage — coordinate round-trip, newer-wins replacement, two authors sharing a d, an a-tag tombstone that removes the project while leaving referenced kind:30617s intact, and a tombstone timestamped between V1 and V2 that must leave V2 live. The negative e2e case asserts on the rejection message so a refusal for an unrelated reason cannot satisfy it; that is what proves the validator is reachable from the live write path rather than merely correct in isolation. The new e2e binary is wired into the Relay E2E job.

The timestamp predicate is additionally pinned at the storage layer by coordinate_delete_spares_head_newer_than_the_deletion in crates/buzz-db/src/lib.rs, which asserts both directions: a stale tombstone deletes nothing and leaves the newer head readable, and a tombstone at the head's own timestamp still deletes it. This test is wired into the Backend Integration job.

Related: #3163 (the NIP-MP spec and shared conformance fixtures). Independent — either can merge first.

Known limitation

Coordinate (a-tag) deletion is not yet durable against later arrival. replace_parameterized_event never consults stored kind-5 tombstones, so a project version with created_at ≤ an existing tombstone that arrives after the tombstone becomes a live head again. This is a pre-existing relay-wide behavior for all parameterized-replaceable kinds — this PR neither introduced nor widened it; the timestamp guard added here strictly narrowed deletion risk in the opposite direction (a stale tombstone can no longer erase a newer head).

Exposure is bounded: only the authenticated signer can write a coordinate (ingest.rs pubkey check), within the ±15-min drift window.

The fix is a durable coordinate-deletion watermark extending the existing parameterized_event_watermarks pattern (used today for NIP-RS) to cover all PRE kinds. That change requires its own schema and query design and will be a separate relay-wide PR.