Hodlbod's book reffers to this as the routing problem. Great read if anyone wants to understand the different ways clients can read data from relays

syncing data between relays is also a part of the solution, and client devs are not fit to solve these problems, in general. but there's nobody funding relay devs

Jumble is also struggling quite a bit implementing all that complexity because it supports the following tab and outbox models.

it's on my to-read list. the routing problem is nostr's biggest issue for building reliable clients imo.

With the growing variety of relays, I believe there’ll come a day when Jumble won’t even need a following tab. I’ve barely checked it this month — it’s just way too slow haha.

yes, defaulting to relay browsing is the only sane way to build a client. the outbox model creates a cambrian explosion of complexity.

it's a fundamental problem with nostr's relay model and has no easy solution, but we are building more half-assed apps instead of rethinking how we build the apps in the first place.

Is this for kind1 or in general? Is it easier for long form?

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.

good question. it's the same problem for every app that tries to show content from the pubkeys you follow, regardless of the kind.

so get the author kind 3, and the tagged ones kind 10002 (if it's microblog), after that you have to do something smart in the selection, you can use only the author ones for a short introduction, and after that recover

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 @greenart7c3 , so that I can tell it to sync every 5 minutes, but not when offline, or something.

I was this many days old, when I found out that Jumble has a following tab. 😂 I legit never noticed. I "follow" by adding npubs to my local relay filter, so it never even occured to me to look.

If I want to catch up on my faves, or on conversations I am in, I just select "ws://localhost:4869" from the Jumble relay list.

Yeeesss :scoresoccer: Same!

i use it but i only have like 80 on my follow list a lot of them actually already post to my relay, i have whitelisted them all automatically (just finished adding that feature last week) but if they use clients that don't auth they can't post to it, so i catch them on the following tab

+ @npub18stt...7h7u + @Zapstore + ...

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.

Also the question of why does Nostr even have relays in the first place. If you abstract away relays in the UI and your Nostr app still makes sense then chances are it should have been built on a traditional stack. But if abstracting away relays in the UI would make your app fall apart then you might be on to something.

I think it makes sense to have an encrypted private following list. It’s pretty much an automation input. You’re hiring someone to ask around town if each establishment has seen these people lately. Make it feel like that, a costly, but ultimately time-saving endeavor. View quoted note →

likes are private on X which is the right thing to do so many people got in hot water for things such as liking a half naked pic of their daughter or something like this only things that NEED to be public should be. everything else should be private.

I think it just depends on what likes actually are. Change them to “rec” for “recommend” or something and then they necessarily become public. But then adding both a private and public distinction for likes adds its own trap. “Oh you’re too good to like this publicly?” 😂 I’m a fan of the “putting flyers up in public locations” metaphor for Nostr. Following this metaphor, there are no likes, there’s only graffiti added onto the flyers.

too early in the morning. i haven't found my thinking cap yet. i assume you are right.

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