NIP-92: Rendezvous Beacons

[shafemtol]

Draft, a bit unstructured at the moment. Related: #306

Things that may be worth discussing at this point:

• expiration tag. Rendezvous beacons generally don't have to be kept around indefinitely, clients should at least not rely on that being the case. Having extra deletion events seems excessive and increases the amount of metadata. Having an expiration tag therefore seems like the best option. In order to reduce fingerprintability, all stored beacons should have the same interval between created_at and expiration. I've set this to 10000000 seconds, or ~3.8 months. The round number means that most digits will be the same between the two fields, aiding compression.

• The requirement for a 0000 prefix on id. This gives some minimal POW requirement, helping to protect against a large volume of "frivolous" beacons. It's also necessary for meaningful subprefix support, as most relays will not let you subscribe to a prefix shorter than 4 hex digits.

• subprefix. It lets recipients choose to subscribe to only 1/16 of all beacons, at the cost of a proportional reduction in their anonymity set. As an option, a recipient can choose to subscribe to beacons on a set of relays with a smaller total volume of beacons. If the subprefix feature and 0000 prefix (and accompanying POW requirement) are both removed, it would reduce the complexity of generating beacons and could save 4 base64 characters in content.

• Subscription metadata location. I've put this in the set_metadata event for now. That means it gets widely distributed, which is good because it lets the sender easily retrieve it without signalling intent to send a beacon to this specific recipient. Another option is to put this in a different event kind, which would allow it to be updated more easily without race conditions on other set_metadata fields, allowing for frequent changes to recipient_pubkey, which must be updated regularly in order to maintain forward secrecy.

[bu5hm4nn]

I've been reading all discussions around DM's and this sounds like an interesting approach.

I couldn't follow the last paragraph. What is n and what is G there? I think it would also help comprehension to have JSON examples of the messages sent and received.

[shafemtol]

I couldn't follow the last paragraph. What is n and what is G there?

These are constants defined for secp256k1. n is the curve order (i.e. scalars / private keys are modulo this constant) and G is the base point (the point that is multiplied by a private key to get the corresponding public key). See BIP340 for details.

[bu5hm4nn]

I'm not a cryptography genius so I will number my takeaways so you can correct me.

a. In layman's terms S would be the private key of the beacon a that was encrypted with the public key of the recepient B, and therefore only the recepient can decode it with his private key b and the pubkey of the beacon A. Correct?

b. So what the recepient does is he listens to all or the subset of beacons he indicated and for each beacon he calculates his candidate of S using the pubkey of the beacon A with his messaging private key b. He then calculates R from S and A and subscribes to any events from R. This would imply that the recepient has to issue a subscription for every beacon he receives, is that correct?

[shafemtol]

a. In layman's terms S would be the private key of the beacon a that was encrypted with the public key of the recepient B, and therefore only the recepient can decode it with his private key b and the pubkey of the beacon A. Correct?

S is a shared secret derived using elliptic-curve Diffie–Hellman. There's not really any encryption or decoding involved. Rather, each party arrives at the same value by combining their keys. Algebraically, A = a⋅G and B = b⋅G, thus S = a⋅b⋅G = a⋅B = b⋅A.

b. So what the recepient does is he listens to all or the subset of beacons he indicated and for each beacon he calculates his candidate of S using the pubkey of the beacon A with his messaging private key b. He then calculates R from S and A and subscribes to any events from R. This would imply that the recepient has to issue a subscription for every beacon he receives, is that correct?

The recipient must issue a subscription for every beacon that decrypts to a matching i value. The beacon contains i encrypted using the shared secret. If this value matches a valid position in the list of relays in the nip92 attribute, the recipient must look for the event signed by R at the corresponding relay. As i is encoded as a 16-bit integer, there's a false positive rate of x in 65536, where x is the number of relays in the nip92 attribute.