aaron on Nostr: An early dumb version that could go a long way might look something like this. A ...

An early dumb version that could go a long way might look something like this.

A relay could publish that it supports a given shard of users.

For example, my relay could publish that it supports serving npubs starting with “aa” through “az” and other relays could too.

Now clients just have to tell a user if their relay set doesn’t have enough shard coverage.

Whenever the next order of magnitude of users arrive, relays would want to reshard and other or underutilized relays would need to redeclare shards.

And there would need to be a way to get users on the new shards.

Maybe some kind of registries would be in order here. In fact registries could be the key branded thing that clients watch for censorship and change to new ones etc.

Historical data would have to get shared around for reshards but there could be people out there that just keep archives or in ipfs or something.

You still need clients to keep users able to understand and identify a bad relay share that is censoring or underperforming or even overserving — or a registry that is promoting shards you don’t like.

But I wonder how far you could scale nostr globally with a dumb strategy like this?

Really important is that niche relays should not do anything like this and should find other ways to scale (monetize etc) but this would be for just the “global” nostr network experience only.