epoch-based deterministic wrapper keys for NIP-17

[fiatjaf]

Another take on #2396.

[Letdown2491]

Thank you @fiatjaf for this. Obviously I am in favor of this since I proposed it but curious on everyone's thoughts.

[psam21]

hkdf_extract(IKM=shared_x, salt=...) has the arguments swapped?

vs. standard hkdf_extract(salt, IKM).

Cause silent interop failures between implementations that follow the spec literally vs. those that follow the RFC.

[alexgleason]

So with this approach you would paginate by decrementing the epoch? You'd build the author(s) for the current epoch and then paginate with until until there's no events left, then decrement the epoch to continue.

Very interesting approach. But a little complex, not sure how well it would work in practice.

[fiatjaf]

Kinda, but you already know the epochs from the start, so you don't have to wait until there are no events left, you can just pinpoint the exact point in which they change.

Yeah, it's more complex, but manageable.

Ultimately I think it's not necessary because DM relays should be in charge of withholding the metadata from third-parties anyway. And relays also have to authenticate the senders to prevent spam so they already know too much.

Actually if the key is static forever (like in @staab's proposal) that makes it so that the relay can refrain from AUTHing everybody and just trust that some preauthorized conversation keys are ok to receive based on whatever rule. So having the key be static can be more private than this solution.