Would the ideal nostr setup be: use 1 relay to download and post into as many relays as possible?

If everyone posts everywhere, there is not need to read from multiple relays (less bandwidth use to download the same info)

If that is the goal, user interfaces can start educating people to do so.

Reply to this note

Please Login to reply.

Discussion

I think that is the goal for a certain subset of people.

a) people that cannot manage their own relays because they lack the understanding and technical know-how.

b) people on metered or slow internet connections in developing nations.

if you don't fall into those categories, then people should have to choice to fully mange their relays and not fall into centralization.

How would this work with paid relays? Paying for every relay there seems unreasonable.

Wouldn't that defeat the decentralization?

I think the inverse is better: Post to just 1 place, your "outbox". Read from the "outboxes" of the people you follow. See NIP-65. You'll end up reading events only once (or twice or three times, at your chosen level of redundancy) instead of many times from many relays.

The only thing that concept doesn't cover is when you want to address a particular person, in which case you need to post to their "inbox". That includes replies, which always address people.

Since I wrote the NIP I've started calling "write relays" your "outbox" and "read relays" your "inbox" and also noticed a striking similarity to ActivityPub.

This has the disadvantage that there is much bigger risk my speech is getting censored.

I took it to the extreme to make the point. Post to 3 or 4 relays. Please don't post to all relays.

Vast majority won't want to/have the knowledge to manually manage up and down relays based on a changing follow list and each npub in the follow list also changing the relays that they're interacting with. Sounds exhausting. Unless I'm missing something?

People only have to turn on a few write relays and a few read relays, set and forget. Finding other people's outboxes and connecting to them is the software's problem... those won't be in your relay list, but they will be used.

I had a bloated list of 26 relays. I reduced it to 11. Still too much?

My followers went from 126 to 76. Can anyone explain the mechanics of why?

The model I'm describing doesn't work today because people aren't publishing their relay lists, so you have to hack around it temporarily.

How many followers you have is hard to count. With less relays surveyed you'll pick up less people.

The problem of followers disappearing from can be solved if clients implement local storage of your contact list. Each follower is tied to a certain relay that they technically followed you on. If you remove that relay that the following event is stored on, then their follow no longer appears. f you add that relay back, the follow will appear again.

I think more granular relay configs would be awesome. Is there a way to prioritize relays as well?

Frankly most relays don't stay up all the time. My efforts to find better heuristics get destroyed by a highly unpredictable uptime :(

That's why Amethyst ships with 19 relays... 🫤

A lot of relays have nginx configs which timeout after 60 seconds.

web.nostrid.app has priority settings for relays

Ideal solution for me would be running my own relay that reads and writes to the top X free known relays plus the paid relays that I specify.

wouderful!