Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
Proposal
Replication group
A relay replication group aims to:
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:
write
andread
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:or encrypted:
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 ofr
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.