NIP-67: Event Replication Groups

[KoalaSat]

trafficstars

NIP-67

Event Replication Groups

Motivation

With the expansion of the protocol, bandwidth usage has become a problem for clients and relays. So far the actual solutions increase (or do not scales) the number of single points of failure:

• Relays creating their own private network with a load balancer to avoid overload.
• Users connecting to proxies to reduce bandwidth usage and battery draining or to avoid manually managing huge lists of relays.

Proposal

Replication group

A relay replication group aims to:

• Avoid single points of failure
• Keep members independent from each other
• Help to create a network of trust
• Exclusively use the nostr protocol

A replication group must have an assigned public key. The usage of a private key is optional and will depend on which policies the members agreed on.

Replication group members

Similar to NIP-65 the group will create a new kind of event to store the list of members:

{
  "kind": 67,
  "tags": [
    ["r", "wss://alicerelay.example.com", "", "a8bb3d884...e4c4e46d"],
    ["r", "wss://brando-relay.com", "", "d5d90b413...f57f5405"],
    ["r", "wss://expensive-relay.example2.com", "write", "7d2a7af0e...fecc8b0b6"],
    ["r", "wss://nostr-relay.example.com", "read", "6f5708a45...3bf0c63fc"],
  ],
  "content": "",
  ...other fields

write and read access can optionally be included, granulating group's topology.

Replication group allow-list

Optionally, the replication group can include p tags to list public keys with access to group's network, similarly to NIP-51 the list can be public:

{
  "kind": 67,
  "tags": [
  "tags": [
    ["r", "wss://alicerelay.example.com", "", "a8bb3d884...e4c4e46d"],
    ["r", "wss://brando-relay.com", "", "d5d90b413...f57f5405"],
    ["r", "wss://expensive-relay.example2.com", "write", "7d2a7af0e...fecc8b0b6"],
    ["r", "wss://nostr-relay.example.com", "read", "6f5708a45...3bf0c63fc"],
    ["p", "3bf0c63fc...b93463407a"],
    ["p", "32e182763...0ebb3c5a7d"],
  ],
  ...other fields
}

or encrypted:

{
  "kind": 67,
  "content": "VezuSvWak++ASjFMRq...rm8HydMYJ2XB6Ixs=?iv=/rtV49RFm0XyFEwG62Eo9A==",
  "tags": [
    ["r", "wss://alicerelay.example.com", "", "a8bb3d884...e4c4e46d"],
    ["r", "wss://brando-relay.com", "", "d5d90b413...f57f5405"],
    ["r", "wss://expensive-relay.example2.com", "write", "7d2a7af0e...fecc8b0b6"],
    ["r", "wss://nostr-relay.example.com", "read", "6f5708a45...3bf0c63fc"],
  ],
  ...other fields
}

Signatures

To allow different group policies, events can be signed on different ways. It can be either a simple signature with group's private key or any sort of multi-signature, by using members' private or delegated (NIP-26) keys.

This last option is convenient in order to not depend on who knows group's private key so, for example, members might agree on signing events by using a N-1 to N multi-signature, and be able to modify the list of members with that consensus.

Clients will ignore event's pubkey and use the set of r tags instead to validate event's signature.

Use cases

Replication network

A group of relays might agree on creating a highly connected network, where any new event sent to one of the members will quickly spread to others. With that in mind, clients can just connect to one single relay of the list and expect their events to be spread through group's network. Reducing the problems initially mentioned.

If clients randomly connects to a member of the list and assuming all members have similar computational power, bandwidth will eventually balance between the members.

To increase group's access to other events, multiple groups might agree on creating join points, where an event created on any member of group 1 will spread to group 2. The usage of this method might organically create interconnected networks of trust.

With this approach, user's will see how their events exponentially spread through a huge number of relays with just a single connection.

Pay2Group

Similar to the Pay2Relay model, a group of relays will be able to collaborate together and open a Pay2Group model where users pay for using group's network to propagate their events.

Possible issues

Policies specification

It's out of the protocol to define the internal operability of every replication group, the way a group excludes or includes members and public keys should be defined and agreed on the foundation of the group.

Centralization

Same way as major relays, huge replication groups might end up centralizing a big number of events, but other groups will be also interested on having access to this information, so collaboration between groups or unilateral connections to the other's network will happen organically.

As mentioned before, this scenario scales up better, because a party will just require one connection to a highly connected group to be able to replicate the events of the entire network.

[barkyq]

Good idea. But it seems like this kind:67 event is just the cherry on the top.

Might make more sense to have this in the NIP-11 document also... Like what if some malicious user just posts an event replication list with a super popular relay and my relay as the URLs? How do clients treat this? Would they stop reading and publishing to my relay because they already publish to the super popular relay? etc etc

Are there any "in the wild" examples of event replication groups? Perhaps they can comment before we formalize it with a dedicated kind. I think https://github.com/hoytech/strfry has some sort of merkle-tree based relay syncing algorithm.

Also, event replication feels a bit ... autonomous. By which I mean the various relays don't actually plan in advance that they will form a replication group. Rather something like Relay X syncs from Relay Y without Relay Y even knowing what is happening.

Strong agree though that replication groups make for a more efficient network topology.

[KoalaSat]

Hi @barkyq, impersonation is everywhere on the nostr network, that's why the group requires a public key and multisignature to confirm that the given group is legit for all their members, which can be ultimately validated with NIP-11.

I see this not as something all clients must just follow, but a configurable option the user manually sets. Keep in mind this NIP is focused on the relays and not the clients. Clients can just ignore this information and continue sending events to the relays even if they are part of a group.

I believe collaboration between relays is critical for the network and desirable that will happen by using the protocol itself, so every relay can maintain his soberingnity.

[KoalaSat]

You just made me think about the situation where a relay doesn't want to be part of a legit group, maybe this kind can include a timestamp so it's used as a contract that requires to be updated over the time.

[staab]

NACK, but a different approach to this problem: https://github.com/nostr-protocol/nips/pull/259

Relays can mutually recommend each other to create all kinds of different replication group geometries.