yes, defaulting to relay browsing is the only sane way to build a client. the outbox model creates a cambrian explosion of complexity.
Discussion
the outbox model is still necessary in many cases. but for the feed, I lean toward a relay-centric approach, especially for web clients.
the following feed might not be a great fit for nostr, especially as more people start storing their events on personal relays. If a following feed is really needed, I’d rather run a relay dedicated to fetching and storing it, and just browse that relay directly.
That's what I do with my local Citrine relay. Pull all of my events and those of my frens, and then I add that relay to the list of relays that form my feed.
Very fast, very smooth, very thorough. Especially, as the local relay pulls from a list of other relays, so it's a personal aggregator.
Only thing missing is an automatic background-sync nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5 , so that I can tell it to sync every 5 minutes, but not when offline, or something.
I’ve been wanting to add a feature to nostr-relay-tray that automatically pulls friend events. Once I implement this feature, I’ll guide everyone on Jumble to run nostr-relay-tray to get their own following feed.
This is the sort of relay centrifuge that makes client development a heck of a lot easier, as you can just hook relays up and get the service from there.
i just got done adding that feature to #orly today. in fact all i did was change it from only fetching a few event types to just grabbing all events every time the spider runs, of all the whitelisted users on the relay.
the spider triggers hourly or any time anyone on the list publishes a new follow list, as it needs to recompute the whitelist from it.
my current task is making a push sync between relays, so you can have two or more relays that instantly receive any new events on other relays in the group.
it could be done by a pull but since implementing it on orly means just doing a nip-98 auth and a HTTP request i am just doing it by push. the other benefit is that events received by this route (or EVENT envelopes) also broadcast to subscribers with matching filters.
the reason i'm making the push sync is because i mean to set up a wireguard mesh (already done) with a round-robin DNS and this way i will have 3 relays that are all replicas and any events going to one will go to all, and if one goes down, the other two will stay up. although this does mean the one that is out of sync will not have events during that period, gotta think about that one as well. simple enough to just add the relays to each other's spider relay list, then it's done automatically.
hmm just need a state variable for last sync... hmmm