[barrydeen]

Stacked on #133 — the base is feat/owner-deletions, so this diff shows only the ban list. GitHub retargets it to master when #133 merges.

Problem

Blacklisting a pubkey means editing a JSON file and restarting the relay, and MustNotBeBlacklistedToPost is only wired into the chat and inbox relays. There was no way to stop a pubkey from writing to Haven from a client, on the fly.

Change

A ban list that lives on nostr: a NIP-51 style replaceable list of kind 10084 that the owner publishes to their own outbox relay. Every p tag on it is a pubkey that may not write to the relay.

nak event -k 10084 -t p=<pubkey> --sec <owner-nsec> wss://your.relay

• Cached, not queried per event. loadBanList reads the latest list from the outbox relay before the relays start serving, and refreshBanList (an OnEventSaved hook on the outbox relay) updates the cache the moment the owner publishes a new version, so an edit takes effect immediately with no restart. The cache is an atomic.Pointer, swapped whole.
• Only the owner's list counts. A kind 10084 from anybody else is stored like any other event and ignored.
• An older list never overwrites a newer one, so a replayed version can't quietly unban somebody.
• The owner is skipped when the list is read, so you can't lock yourself out of your own relay.
• Enforced everywhere. MustNotBeBannedToPost is the first reject policy on all four relays and also checks the authenticated pubkey, which is what catches a banned user sending gift wraps under a throwaway key. The three import paths skip banned pubkeys like they skip blacklisted ones.
• Delete requests too. khatru handles kind 5 before any reject policy runs, so the ban is checked in the deletion outcome as well — otherwise a banned pubkey could still send delete requests.

A ban wins over whitelisting. Private (NIP-44 encrypted) list entries are not supported: the relay has no key to decrypt them with.

Note that kind 10084 is not one of the list kinds NIP-51 assigns (its replaceable lists run 10000–10102, with 10084 unused); it is a Haven-specific list following the same shape.

Testing

Ran a real instance with fresh databases and an isolated config, driven by a go-nostr client. 15/15 checks pass:

• a pubkey that could write before the ban is rejected by the private, chat, outbox and inbox relays afterwards, with blocked: you are banned from this relay
• a banned pubkey can't delete its own events, and the event it targeted is still there
• other pubkeys are unaffected
• the ban survives a relay restart, i.e. the list is picked up from the outbox relay on boot
• publishing an updated list unbans immediately, and re-publishing the older version does not re-ban
• a kind 10084 from a whitelisted user other than the owner has no effect

The delete-request suite from #133 was re-run against the same build and still passes. go build, go vet and gofmt are clean.