relay cluster replication protocol #2094
Conversation
|
added the ability to declare replication policies for kinds to enable negotiated and automated replication for less central data types for their specific userbase. |
…ise trust attestations to trust acts, and enhance key management protocols with BIP32 HD derivation details. Adjust event kind descriptions and clarify signing and encryption key usage.
|
this expanded to include a DNS style namespace with optional multisig control, a two witness escrow protocol, because DNS requires a consistently replicated database (well, eventually consistently is the best it can do). |
|
This is so huge. I can't imagine anyone implementing it. Or at least it would have to prove itself a lot first. I must confess I haven't read the protocol description, only the abstract and motivation, but I don't understand the goals even, is it just for syncing events between relays? Can't that be achieved with a much simpler protocol, like Negentropy? |
it's a database replication algorithm that uses web of trust declarations. in fact i could add more replication rules than just directory and arbitrary kind list, there could be other types of group identities, pubkeys, group keys, hashtags, anything replicated as well. the big problem with nostr, as anyone who knows DST will tell you is that it has very weak consistency. that's fine, if you want people to get stuck in their little island in the archaepelago but you need a directory to be spread across the network if you want to build bridges between the nodes, and you know, the more nodes the better the censorship resistance. relay operators are already peering and scraping and aggregating, so that extra part of it is about making the process into a formal protocol that is automatic and peer to peer, and discoverable. the uses for knowing where what kind of events flow are simple to imagine - when one is down, the other has it. if one can't connect to one relay, then another relay that syncs with it might. it can solve the "event not found" problem. there is also other issues around broadcasting and aggregating, one of them is auth. this bypasses the problem of a user needing to auth to other relays and thus make redundant queries, if the data is already being synced, most of the time they can just go to one relay and get everything they want, and if not, maybe two. if a user's client has to go to 10 or 20 relays to find everything we are starting to get into bad latency territory. so, facilitating that kind of propagation of events helps relieve the mobile battery/bandwidth problems for users. it makes the loading of feeds faster. keeping the directory updated across the network means you never see a hex pubkey on your feed again. having a name service system that is built on the same base database replication protocol then means groups can be distributed across many relays and have all their content broadcast between nodes that is of interest to the users. ps: also, i realise that the actual replication protocol part is missing. it's mostly implementation detail, but the trust acts should affect the relay's access control and override it to the extent of the specifications of the peering relationship, and there needs to be more than just kinds, there should be pubkeys, hashtags, probably other things, like the signing address of the names registry to include community related events. and yes, it requires an active worker process that does subscription and catch-up REQs for event sync, and when it saves events they should be pushed to subscribers that match the filter. |
mleku
changed the title
There was a problem hiding this comment.
I've been planning to draft something for relay replication/federation/migration for a while, so I'm very interested in this. I do think though that it should be split into multiple PRs. The text is also really long, it would be good to shorten it as much as possible so people will actually read and implement.
I left a ton of comments, but to summarize, I don't think nostr is a suitable place to register global identifiers (Group Tag Act), since it's inherently bad at global consensus. Transfers also can't be done without a trusted third party or a blockchain, so I don't think this part of the design is going to work.
I also think the HD keys stuff should be part of a different NIP, and might as well be generalized to be usable for any keypair, not just relays.
Overall, I think the replication stuff is a little too rigidly focused on the particular use case you have in mind, and could be refined to be more generally useful. I'll try to open a PR for what I have in mind tomorrow and we can compare notes.
XX.md
Outdated
|
|
||
| Each participating relay MUST generate and maintain a long-term identity keypair separate from any user keys: | ||
|
|
||
| - **Identity Key**: A secp256k1 keypair used to identify the relay in the consortium. The public key MUST be listed in the `pubkey` field of the NIP-11 relay information document, and the relay MUST prove control of the corresponding private key through the signature mechanism described below. |
XX.md
Outdated
| 5. Verify the signature using the public key and computed hash | ||
| 6. If verification succeeds, the relay has proven control of the private key AND binding to the network address | ||
|
|
||
| This mechanism ensures that only the entity controlling the private key can generate a valid NIP-11 document for a specific network address, preventing relay impersonation attacks where an attacker might copy another relay's public key without controlling the corresponding private key. The inclusion of the relay address in the signature prevents an attacker from copying a valid NIP-11 document and hosting it at a different address. |
There was a problem hiding this comment.
This could be annoying if a relay is hosted at multiple addresses, or is ok with some kind of reverse proxy
XX.md
Outdated
| ``` | ||
|
|
||
| **Tags:** | ||
| - `d`: Identifier for the relay identity (always "relay-identity") |
There was a problem hiding this comment.
This should be a 1xxxx event then
XX.md
Outdated
| ```json | ||
| { | ||
| "kind": 39100, | ||
| "content": "{\"name\":\"relay.example.com\",\"description\":\"Community relay\",\"contact\":\"[email protected]\"}", |
There was a problem hiding this comment.
Just make these tags, no need to repeat our json-in-json mistakes
| - `relay`: WebSocket URL of the relay | ||
| - `signing_key`: Public key for verifying acts from this relay (MAY be the same as identity key) | ||
| - `encryption_key`: Public key for ECDH encryption | ||
| - `version`: Protocol version number |
There was a problem hiding this comment.
Just use a new event kind if the version needs to change
XX.md
Outdated
|
|
||
| **Tags:** | ||
| - `p`: Public key of the target relay being attested | ||
| - `trust_level`: Replication percentage (0-100) indicating probability of replicating each event |
There was a problem hiding this comment.
Is replication push or pull? I could see use cases for both
XX.md
Outdated
|
|
||
| **Registration Model:** | ||
| - Group tags are **alienable** (transferable) and follow first-come-first-served registration | ||
| - The first valid Group Tag Act for a given `group_id` establishes initial ownership |
XX.md
Outdated
| **Registration Model:** | ||
| - Group tags are **alienable** (transferable) and follow first-come-first-served registration | ||
| - The first valid Group Tag Act for a given `group_id` establishes initial ownership | ||
| - Ownership can be transferred through Group Tag Transfer events (Kind 39106) with optional escrow |
There was a problem hiding this comment.
This runs up against the double spend problem, so unless you're anchoring in a block chain this isn't going to work
XX.md
Outdated
| The following existing event kinds are considered "directory events" and subject to consortium replication: | ||
|
|
||
| - **Kind 0**: User Metadata | ||
| - **Kind 3**: Follow Lists | ||
| - **Kind 5**: Event Deletion Requests | ||
| - **Kind 1984**: Reporting | ||
| - **Kind 10002**: Relay List Metadata | ||
| - **Kind 10000**: Mute Lists | ||
| - **Kind 10050**: DM Relay Lists |
There was a problem hiding this comment.
I think a lot of this is redundant, and only kind 10002 should be replicated since everything else by a given author can be found on their outbox relays (at least in theory). This would reduce complexity and resources required for indexers.
There are kinds that don't fit that paradigm though, like geo-tagged stuff, or reports (which are fetched by tagged event/pubkey rather than author). I don't know how to solve that, although I speculated on it a bit in https://building-nostr.coracle.social.
XX.md
Outdated
| 1. If Relay A trusts Relay B with "high" trust | ||
| 2. And Relay B trusts Relay C with "medium" trust | ||
| 3. Then Relay A may automatically trust Relay C with "low" trust | ||
| 4. Trust inheritance follows configurable policies and confidence thresholds |
There was a problem hiding this comment.
I don't think it's this simple. What if you have a network split with multiple separate trusted in groups? How do you prevent a cabal from taking over the global namespace?
|
thanks for the comments @staab i will be adding this, i agree, probably the keychain is a separate protocol. probably there is 3 or 4 in here. the trust levels and interest filter list thing/replication is more the communication mechanism for coordinating the actual replication of relevant event streams in a way that is not a consensus but forms little bubbles of consensus. this is probably the foundational part and i will strip out the rest. the main thing i want to do is create a stronger consistency guarantee that is stronger provisional to the information that the relays are chattering about each other helping you find where the data is. i'll just focus on the main goal of getting that stronger consensus in this NIP, and move the key and name systems to other NIPs later on, they will depend on this existing anyway, and other people will think of many uses for this improved consistency. there is other ways to replicate databases than pBFT and nakamoto consensus. nostr's protocol just doesn't specify one, partly because of the plague of problems caused by trying to join social networks with them. fartcaster is basically dead. bluesky uses a particular federation funnel replication pattern, which gives them the editorial power they want as an instrument of cointelpro lol. nostr is freedom tech, so it needs a consensus that is looser. where consistency can be increased by simply spreading events around and letting people know where they get sent. then with that better guarantee that a any given user will find the latest version of some event with less messaging cycles and lower chances of not finding it means you can do other things with nostr that the shitcoiners have probably already tried to do but it failed bcause of perverse incentives. i'm trying to unify all the existing methods of spidering and propagating events so that we can do those things without the unacceptable compromise and inevitable failure of uusing known stupid ideas such as blockchain forums. |
|
i have been given the task of creating an effective replication protocol for groups of nostr relays, and it is much simpler in this new version. there is an event kind that defines the cluster membership and all particpating relays accept that as instructions to update their sync peers accordingly. it uses a replication strategy that i thought of in discussions with Semisol based on the monotonic identifiers of event records in the database, relays can be interrogated for their current biggest event serial, then you can ask for the event ids of a range of these serials, and fetch them and do whatever. it uses a request/response REST type messaging pattern and polls every 5 seconds for the current state to determine whether to ask for the IDs and fetch the events. |
mleku
changed the title
3 participants
This is a proposal for creating a distributed consensus for maintaining maximum broad distribution of the most current versions of events associated with nostr identities, by which i mean the constellation of event kinds that enable users clients to do things like render your avatar and find your outboxes.
The need for this kind of data to be replicated well is obvious to me on a pretty regular basis as I browse feeds that for whatever reason the kind 0 is missing and that should just never happnen anywhere. the total data size of all 30-50k nostr users directory events probably weights in under a gigabyte.
The bonus is that if you have a functioning replication protocol for one set of data types, then it makes no sense to not find ways to use it, and for this the group, relay trust and delegated key advertising messages enable users to use a new npub for every event while clients can trace that back to the user's directory events to render properly.