@ademan@rieger_san@benjaminbellamy yeah. my first version was actually just a 16 bit integer id, if we exceed 65k activity types lets just change the protocol then and not worry about it now
@ademan@rieger_san@benjaminbellamy yeah true. i was experimenting last year a bit and also settled on numbers but what i did was hash a name+versionid to 128 bits if i revisit it i will revise it to also hash your author id into it so there's not likely to ever be a collision. 128 bits is a lot though
@ademan@rieger_san@benjaminbellamy yeah it rubs me the wrong way even though theres nothing stopping two implementors on fedi from giving their new activity the same name and confusing servers
@ademan@rieger_san@benjaminbellamy i got a little hung up over evend kind ids being seemingly centrally defined unless you literally can just pick a number and start coding a new event
Since it’s opaque to relays you can do whatever, but I don’t like kind ids being numeric because collisions are going to be common between people experimenting. You need to coordinate it somehow.
(Also encoding persistence behavior into numeric ranges is super dumb)
@ademan@benjaminbellamy@Moon Nostr is an open protocol that only exists because of the nips. There is reference implementation, which means the specs are the only source of truth
specs aren’t always followed in practice, especially when things are rapidly changing, and that seemed to be what was happening from what @Moon said, but it turned out not to be the case.