Spam prevention for kind 445 events

[hzrd149]

I'm creating an issue instead of a PR because I don't fully understand the protocol yet and would like to get some feedback before proposing breaking changes.

The problem:

MIP-03 states that clients should include an h tag with the nostr_group_id value from the marmot extension data. This is separable to spam since any observer can read the h tag and publish bad data that clients will have to download and attempt to parse.

Proposal 1:

Create version 2 of the marmot group data extension that has a nostr_group_key with a 32 byte private key that can be rotated in a similar way to the existing nostr_group_id. Then this key should be used by all members of the group to encrypt, sign, and publish the kind 445 events.

This should mitigate the spam problem since only members inside the group could publish valid kind 445 events. This shouldn't' effect the anonymity of group members either since there isn't a difference between publishing with a common h tag and a common key

Proposal 2:

Similar to proposal 1 but use the MLS exporter_secret to derive a nostr private key to encrypt, since, and publish the kind 445 events.

I don't fully understand what the exporter secret is used for in MLS but its available and seems to be indented to allow MLS bind to other protocols. the downside of this would be that the nostr private key (and by extension pubkey) would rotate every commit. which could make it difficult for clients to follow?

[RogueFantasy]

The fix is probably close to proposal 2. Mdk already derives nostr keys from the exporter secret for nip44 encryption. The change would be to sign events with the exporter-derived keypair instead of an ephemeral one and drop the h tag (clients filter by the exporter-derived pubkey). This prevents spam and improves privacy.

The spec change to mip03 would be small: update pubkey field description, remove h tag from event structure, and change step 4 of the encryption process to sign with the exporter-derived keypair from step 2. But since the nostr_group_id and h tag are used elsewhere, dropping the h tag means clients need to maintain a mapping of exporter-derived pubkeys per group per epoch and the storage layer needs a new query path. This seems straightforward though: the exporter secrets are already stored per epoch in group_exporter_secrets and subscription filters just update on commit processing.