Why Nostr? What is Njump?
2024-07-07 12:30:32
in reply to

mleku on Nostr: i think it would have to be done as like a bitcoin HD wallet but the root key would ...

i think it would have to be done as like a bitcoin HD wallet but the root key would function as identity, and only be used infrequently, and derived keys would be advertised as tied to the identity, and these can be rolled over regularly, and through the use of the keychain advertisment and you would have cross-client sync

the only other thing is that the replacement of such events would need to be slow, like, you advertise a new batch every X few hundred events signed with the advertised keysets, and then generate a new one, but the old one would need to be available, and several back to provide a sufficient window of coverage for old events

the other thing might require the author pubkey, the master identity, to be put on the events for the older events, whose age would mean that they are unlikely to need such careful checking as current ones

the hardest thing in this is the broadcasting

i've suggested this before, that certain kinds of events should be broadcast to all known relays, and relays should actively rebroadcast them, these keychain advertisment events, there could be other valid types of events for which such broadcast would make sense, and because there is no consensus, this broadcast would have to be gratuitous, as in, nodes would keep sending out newly advertised ones for a period of time until some time after they get no "already seen it" replies from other relays

this is something that is not in the nips at all, and partly because most of the people designing them don't have much experience or knowledge in the area of distributed systems and especially peer to peer systems

there has been a good, prudent avoidance of creating a consensus for the protocol, and i am entirely agreed with this, that we don't want a consensus, because consensus is a barrier to scalability, the data has to be best effort replication only, no strong consistency guarantee

but this doesn't mean we can't have some reliability on the side of critical event types like identities, these events make such imprevements in security and the ability to migrate data between clients without relying on explicit migration methods (backups) while at the same time not requiring a guarantee of broad replication (consensus) to be reliable enough that the rare times they miss nobody really minds...

besides, there can also be a specialisation of service that i call "archivist" - relays that just suck up every event they can find and store them for very long periods of time, monetised by subscription to access their rich vault of data

these are all concepts that are beyond what most of nostr protocol spec goes into, they are verging towards the kind of thing you see with bittorrent in the way that it scales and maintains a weak consistent global consensus capable of handling billions of active accounts
Author Public Key
npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku