search

mikedilger / nostr-next

Issues with nostr that would require breaking changes to fix
4 stars 0 forks source link

Device ID #35

Open staab opened 1 month ago

staab commented 1 month ago

Having a separate device ID can help reduce conflicts. Pairs well with #34. Polycentric uses vector clocks to manage this.

mikedilger commented 1 week ago

Twitter snowflakes include a machine id of 10 bits, which means they have to be centrally coordinated to not collide and then a 12-bit sequence number allowing a maximum of 4096 events from the same machine within the same millisecond!

https://en.wikipedia.org/wiki/Snowflake_ID

I was considering events being referenced not by their hash, but by an address composed of (1) user's pubkey (2) the timestamp, (3) some unique data to prevent collisions. The idea here is that users could edit their events and references to their events don't break (since the hash isn't part of the address). Also the reference can include the kind, so that you don't have to look them up if you already know the kind is irrelevant in your circumstance.

(and they can still be referenced by hash in circumstances that require it)

But if (3) is a device id and a device sequence number, I'm wondering how to coordinate device IDs so that they don't collide... or maybe just make them long enough to be probabilistically unique (although I'd like to save some space here if possible).

mikedilger commented 1 week ago

... and also these event references including the user's pubkey mean you can go find their relays to know where the events ought to be.