I don't think I would use this: #[0], but if it worked it would create a certain aura of exclusivity for content posted in this relay. Better yet if you restrict reads somehow, make them harder to get or something like that.
Discussion
Other relay ideas (not very good, just to sparkle your imagination):
- a relay only for people with top-level domain names (no "@" at the NIP-05)
- a relay that only stores the most recent post of people
- a relay that only stores posts that have received at least 10 replies from other people (big threads)
- a relay that only serves posts to people "bitcoin" on their profile metadata
The most interesting crazy relay idea to comment on this post will earn a marvelous prize of 10000 sats.
A yellow page relay that only accept user metadata and following list, serve as social graphs list
A relay that only serves a specific public key range, and redirects to other relays if the public key range is not served. The intention is to enforce some level of distribution. Relays will communicate amongst themselves as to what public key ranges they will serve.
a relay optimized to be the metadata transport layer to never have data loss between clients again
A relay that sends 'gm' or 'pv' every morning to every one that uses it jajaja just kidding...
A darwinist relay for posts.
Posts not replied in one day will disappear, let the posts struggle to survive😈.
Relay specialization to achieve optimum functionality
V2
Requirements:
Noone misses out on any event
Efficiency / lower bandwidth usage
Fast queries
Resilient against attacks
Long term storage of all the events
Explanation of Requirements:
Noone wants to miss out on events. If I am following someone I want to be sure that I am getting their events. There is no guarantee in current paradigm. If I am posting something I want it to go to everywhere. With lots of events shared between relays and eventually users, the interactivity and excitement will increase on nostr.
Right now the responses to queries are similar, coming from several or more relays, which makes nostr traffic to be very inefficient. Efficiency is important for especially mobile clients.
Current relays store the events for long term. Which adds load for most queries which look for recent events. Some relays can specialize in delivering recent events quickly and deleting after some time except maybe some kinds like 0 (metadata) and 3 (contacts).
Simply increasing the number of servers should deter some DoS attacks from even beginning.
Other relays can specialize for long term storage of everything else and not for speed.
Proposal:
To solve these I am proposing some specialization of relays. There will be like 32 read only servers which specialize in speed, fast queries, high bandwith, each temporarily storing a shard (1/32) of complete set of all events on nostr. The events can be sharded based on their last 5 bits. Storage can be mem only. If someone connects to all these 32 relays they will get all the ‘live’ events.
Secondly, the general purpose read/write servers which specialize in long term storage to make sure the events are preserved. They copy events to the read only servers (above). When a client wants to write, they can do to any of the general purpose servers. The events are then distributed to read only servers based on last bits of their event id. There may be hundreds of these servers.
Clients can connect to 32 read only plus some read/write servers in order to achieve everything.
We can have a copy of all shards to increase redundancy or resiliency against DoS attacks, or just to increase speed by having a lower ping.
Mobile clients need lower traffic. By connecting to 32 shards they are making sure they get unique events from each, thereby reducing the traffic. If mobile clients don't mind more querying traffic, # of shards (32) can be increased even more to 64, 128…
If # of shards is 64, last 6 bits of the events will be used for sharding purposes.
Really interesting concept though. Probably wouldn’t be too hard to make a Substack-like system using Nostr… 🤔