Katja Lutz on Nostr: Lets image a world, where the main feed would not be sorted by creation date, but by ...

Lets image a world, where the main feed would not be sorted by creation date, but by the time the client received the note. If the client doesn't have to list the notes by creation date, the client gains the ability to schedule retrieval of new notes, basically setting up short-term subscriptions for X relays, then e.g. 1 minute later for Y relays, then for Z and so on. This could be a tactic to avoid having 100ths of parallel open sockets.

What would be the tradeoff from a UX perspective? You loose the ability to know where to find the most recently created notes, but does that actually matter? You gonna miss out on most notes anyways, unless you are a 24/7 doom scroller 😁.

The other tradeoff coming to mind would be if you wanna read the replies on a note, you have to wait until the client went through all relays... Unless we find a way to somehow tell the client where to look for the replies of a specific note 🤔.

quoting
nevent1q…wcyn

Why can't we just open one subscription to two or three relays of each followed person in order to build the default feed?


If that was possible that would make implementing "outbox" even easier than implementing a client that just uses a static set of relays. Caching notes from is easy, it's easy to continue fetching from where your cache ends. Relay selection is easy, no need to build complex filters aggregating multiple requests and do fancy relay selection based on whom you're following matches whom. Everything is just one loop.


Nostr is easy again, developers are happy. Even the dumbest web developer can do censorship-resistant Nostr clients for everything.