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
Published at
2024-07-07 12:30:32Event JSON
{
"id": "56466cc6fb6778fe07e6b905a8214fca8756ac7511810fbfd05992ebe2948976",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1720348232,
"kind": 1,
"tags": [
[
"e",
"210e4f5b3b80a1fb555acdf9f6389f0adc2191adde1cd007ce89246bf44ce442",
"",
"root"
],
[
"e",
"3b0a206eee03f01cda429bcfa41a71c76f13297761b773ec0c2714b6567138d4",
"",
"reply"
],
[
"p",
"8aef75ca27af00a6f70c14865ae52860ccdc368f46499c7cf6b2352b09a709f5",
"wss://nostr.cercatrova.me/",
"mention"
],
[
"p",
"44dc1c2db9c3fbd7bee9257eceb52be3cf8c40baf7b63f46e56b58a131c74f0b",
"",
"mention"
]
],
"content": "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\n\nthe 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\n\nthe 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\n\nthe hardest thing in this is the broadcasting\n\ni'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\n\nthis 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\n\nthere 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\n\nbut 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... \n\nbesides, 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\n\nthese 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",
"sig": "5f6b21016ae975219a0af00ebaac3504c1dea2c62ed1ab23fefadfdcc9595304f7e1eeda59d3a1be3ed56bc55f3c682a5d59fefd8dae3205e7aaac2e0685a501"
}