Each relay selects a branch from above and starts serving.
Some big machines in the top layers can handle more. Smaller machines in layers below are needed for decentralization and scalability.
Some top layer machines can act in sync only mode, efficiently distributing notes among layers.
Relay or the admin posts a special kind for advertisement of the relay:
```
{
"pubkey": "...pubkey of admin or the relay itself..",
"kind": 30202,
"tags": [
["d","..10"],
["ip4","111.222.33.44:443","primary"],
["ip6","abc:def::443","backup"],
],
...
}
```
The above example says this relay will handle the note id's that are ending with bits ..10. In this case it is going to handle about 1/4th of the network.
Primary way of reaching at this relay is through ip 111.222.33.44. There is also a backup server.
Clients can accept this advertisement based on web of trust or historical reliability of the npub. Or other npubs can measure the reliability of this relay and send reactions to this note. Clients then can see these reactions and rank these services.
Solves:
- Possible future DNS ban issues:
I don't know when or if DNS will be an issue for Nostr. The above design can help with the situation.
- Scalability:
If 1 million users join the network at the same time, the machines that are handling ".." i.e. all of the traffic may fail. But if the clients are using relays on other layers, the load will be efficiently distributed to many machines. The failure of layer 0 and 1 will not stop the network.
Every layer can operate independently without the other layers (in theory).
- Traffic efficiency:
A client has to query many relays, depending on what it wants to do. It may choose to stay efficient (talk to top layers) on mobile traffic, or it may choose to help decentralization over wifi. The notes that match the queries will not be repeated as many times as current design, because relays will hold a portion of the network.
- Storage efficiency:
Relay operators can just save a part of the network that they are responsible for, on NVME drives. The rest of the network they can save in hard drives. In case of major failure the hard drives can still have a copy.
- Speed:
Since the notes will come from many different relays at the same time, there may be a slight speed increase.
- Decentralization:
If the top layer relays collude and start banning the other layers can still continue to serve notes.
- Backup relay:
In case a relay instance fails, users can find the backup server on the same note.
- Zero down time migration:
The ability to define a backup server allows zero down time migrations. An operator can set the primary to the new server and backup to the old server and do migration and continue without interruption.
- Efficient sync among servers:
A relay has to sync with 3 servers, 1 above, 2 below. But it can do 6 or 9 depending on how much reliability it wants.
- Writing to logN relays:
Clients has to write to logN relays (i.e. 1 relay in each layer), to effectively distribute their notes to everyone and also to help with decentralization.
We will definitely needs some kind of sharding when the user number and the amount of data grows.
I'm wondering if partitioning by ID fragment is a good idea. If you read a list of events almost every event needs to be read from a different relay.
It might be better to optimize for reading multiple events of a particular author and by partitioning by pubkey instead.
Oddbean new post about login | logout ){kind=link}