Thread

That doesn't sound too bad if the filters are tight enough no?

nostr:nevent1qvzqqqqqqypzqquxdpn0xlh4zqw9k3patfqml9nnndqkyd9e642sfxzlycj5279pqy88wumn8ghj7mn0wvhxcmmv9uq36amnwvaz7tmwdaehgu3wvf5hgcm0d9hx2u3wwdhkx6tpdshsqgrwtvu37jny4py9m4thcxx32ccexwl5z2yup360dfedxc8q7qvk7cdftfff

I immediately thought about limiting to the first 5 outboxes for users when I started.

Gossip for my follow list usually connects to about 56 relays at peak. For RSS we had feed aggregators. They don't have to be in the client, they can be a middle box. I like gossip on desktop to continue to do the feed aggregation, but on a phone I might have looked at a different architecture... which I presume is what you were doing before this "full outbox" version?

I dont think Android works well with this volume of simultaneous connections. It feels like it is rotating connections. It's a bit slow.

I already limit to only the first 3 relays. The rest are for the other features, like chats, custom feeds, marketplaces, etc. They may all use different relays now.

I think YakiHonne does maybe 2 at most?

"Full" means connecting everything: follow lists, all chats, all communities, all nip-29 relays, marketplace, DMs, live streams, all custom feeds, notifications from all users, etc.

That's the way

Just reacted and it showed these relays. I’m not write connected to the first 2

Nice! That some good design right there.

A couple of suggestions: Add a slider so that folks can select max number on Outbox relays per contact a la Nosostros. Set the default to 2 or 3. Also, you are probably already doing this, hut aggressively timeout and remove unresponsive relays (with some sort of exponential backoff strategy where misbehaving relays have to wait longer and longer). This is how I'm optimising import / inbox subscription on Haven where users often add 300 relays (1/3 or more of which may be unresponsive or dead).

Nice tips

Another slightly more involved heuristic. Assuming that, for a given npub, all outbox relays contain all user notes (a strong and likely incorrect assumption, but useful for optimization), you can write a reasonable "greedy" relay selection algo as follows: Create a Map<Relay, List<Pubkey>> and prioritize (working) relays that are common to most "uncovered" users (this can get more complex if you want to compute a minimum set, but a greedy heuristic is good enough). This works well for general things like the following timeline as it minimizes the number of relays you need to connect to. For less general tasks, such as when someone clicks to view a specific profile, you can open a separate pool containing only the user's outbox relays to catch any notes that might not have made it to the "general" pool. "Borrow" existing open connections from the general pool so that you don’t keep reconnecting to the same relays. At least with go-nostr this is working quite well. I'm not sure if things are much different with Kotlin libraries and mobile devices/ Android resource limitations.

would be nice to do something about toning it down since forever

What do you mean? Right now you have control over the list of relays amethyst connects to. You can delete them if you think it is too much

a very large number of relays already are replicating data across many relays. would be useful if relays could tell you this so you can eliminate the ones that it wouldn't reach, based on your follows relay lists it's a general problem for nostr, and one that nobody has bothered to fix and raises the problem that if people have auth-required inboxes how can you auth to them through another relay, you literally have to do the fan-out from your client, like you are just now noticing. welcome to the club of the guys that noticed stuff.

you didn't think about the fact that it's going to be publishing them to users inboxes as well? literally could be dozens or more on many users who don't understand the implications of it. anyway, funny. i'm sure you are never going to get it that amethyst is a bandwidth pig. i've had it blow my mobile data several times in the last year.

Make sense, but I don't think this will ever be fixed. If you delete your General relay list, amethyst does offer relay recommendations based on the most optimized setting you can get. You can just add them back to the general section s then.

won't ever be fixed by someone as stubborn as you with so little concern for the plebs with expensive mobile internet. or slow devices. i know. that's why i'm so sarcastic and cynical towards you.

I did think. That's already implemented in the new version. Amethyst is supposed to consume bandwidth just by the sheer number of features that must be loaded at the same time. That's why I keep saying that micro apps should be able to beat us. But they never do. So...

You can either see less and accept that you will miss things here and there or pull from more relays like we do. Most other nostr apps I use don't show as many things as see on Amethyst.

Vitor last update to amethyst I can see is back in January. Is that correct?

Yep

Outbox getting out hand. Communities will constitute a good middle ground, or even substitute in many cases. nostr:nevent1qqs297nzg6m68frxw6ymjl9lwl8zp3h6ldnvrxa8ss83k73mw5lqtjgpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczyprqcf0xst760qet2tglytfay2e3wmvh9asdehpjztkceyh0s5r9cqcyqqqqqqghrxqa5

👀👀💪💜