Outbox is harder than it should be just because devs make their first versions with a hardcoded relay list expecting that later they will just "add outbox".

Nah... you won't. You fucked up. Now you need to rewrite everything because your architecture cannot handle it. It's as simple as that.

Outbox requires many layers of indirections: Before loading the feed, you need to load the NIP-65 event, and before loading the NIP-65 event you need to figure out the user's home relay to get the most up-to-date NIP-65 event from. You will need to setup those layers from the beginning.

More importantly: your relay pool will change from post to post. You will need to quickly disconnect and connect to relays as the use slides through their feed.

To see all replies of a thread, you will connect to all of the inbox relays of each participant in that thread. That's the only way to see everything.

The same pool must keep Bunker connections alive at all times and randomly connect to Nostur Wallet Connect relays to send zaps.

If you are crazy enough to implement multiple NIPs, like Amethyst and Nostur do, each NIP will have their own ways of defining which list should be used. You will need different bootstrapping relays for each NIP.

Our nostr libraries are terrible. They are almost all still based in the old thinking of a fixed relay pool. Even the modern AI stuff from nostr:nprofile1qqsqgc0uhmxycvm5gwvn944c7yfxnnxm0nyh8tt62zhrvtd3xkj8fhgprdmhxue69uhkwmr9v9ek7mnpw3hhytnyv4mz7un9d3shjqg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3vamnwvaz7tmjv4kxz7fwd4hhxarj9ec82c30hyvdwq still uses fixed relay lists. That will drive your code into a direction that will be very hard if not impossible to fix later.

We can fix this. But it is hard to fix when every client also operates a main relay to centralize things on. Things get built around that relay and people forget to decentralize. It's sad. But this error is so common that it's not even fun anymore.

Every client needs to help users setup their relay lists. Every client MUST use the user's relay lists that other clients already helped him/her setup. Ignoring the user settings from a different client will only make your code unfixable overtime.

The happy path is evil. And if you go down into that direction, it will consume your soul.

Reply to this note

Please Login to reply.

Discussion

Speaking of outbox, still eagerly waiting for that to drop in a stable build.

I am shotting for this week. I am just fixing a few bugs left in the stack

outbox模型我感觉不太好用,要连的中继太多了,尤其是广场上的帖子,几乎可以说要连接到所有中继了。。。

nostr:nevent1qqs2txvkjpa6fdlhxdtqmyk2tzzchpaa4vrfgx7h20539u5k9lzgqwgpr4mhxue69uhkymmnw3ezucnfw33k76tww3ux76m09e3k7mf0qgsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqrqsqqqqqp8rhunh

so when you onboard a user on a client you should publish their relays of choice? on sign up? say a set on onboarding relays? that they can later set-up add/remove in relay settings?? asking for my app https://github.com/turizspace/hisa/releases using multiple NIPs 28/99/17

If you can make them choose (and explain what's going on) sure. But if not, just put them on semi-random list and but let them change later. The most important part is to get them in, and help them setup when they are ready.

On that note how does amerthyst know what my relays even are? I assume its a hardcoded bootstrap? Would make sense if that can be configured on first boot and is then cached.

We keep your lists in the local storage, but otherwise we search for it via bootstrap+ event hints.

But what if in theory the default relays are blocked or broken? Would we be able to custom connect to get the bootstrap over with?

Pretty much.

FWIW, I added outbox model to Corny Chat sometime ago. I rely on fixed list to get the users relay Metadata if it exists. I don't bother with giving users a way to manage their relays. It's there for advanced users but honestly it's not convenient for users nor developers and feels wrong because of the inefficiencies it generates on those connects and disconnects. In the end, everyone ends up still using common relays. We need to rethink through the problem we are trying to solve and make it easier. Not every app should need to build such robust handling as it's 90% effort for 10% gain

Then you are just another centralized app. What's the point of nostr if we don't teach people ways to control their data?

Yes. All nostr apps are centralized.

We can teach users how to create and use accounts and events across apps. But controlling data is a different matter. Censorship resistance, yes. Access management, no.

> All Nostr apps are centralized

lol. There are many apps that don't have main relays and just use what the user chooses. Just because you don't know or don't want to decentralize, it doesn't mean that all apps are centralized.

this is something vibe code cannot fix. we need sdk heros more than ever.. (ones that won't abandon us this time)

How does outbox affect data and battery consumption ?

Can user cap max connections to mitigate resource usage?

How can users be incentived to setup their own relay list? It’s really complicated when they don’t have any meaning yet of what relays are. So it’s not only about incentives but also the ability to learn something new in a digital context of sending letters through post offices. Or knowing what pidgeon you have to use to deliver a message.

Yep, this is what happened to us on Nos. Well we wrote it before the outbox model existed. Once it did we always planned to adopt it but it became the forever-put-off mega refactor that was very important but never urgent. I was able to slowly march our relay code towards it: breaking the layers apart, using relay hints in some places, keeping a dynamic pool of relay connections based on demand, but we never got to the full thing.

It's taking me 6 months for full time work to do this... :(

Damn, I'll wait a while adding Nostr to my client again.

(it's https://multipos.social/)

Yes it is a deep change.

I think one of the biggest problems is the infinite-redundancy issue. Most protocols have no redundancy. We have unbounded lists of relays. I think 3 is plenty for any particular purpose. Given how many connections we already have to make, it is just too onerous to connect to all 37 of someone's outbox servers. If people want to list 37 outbox servers, clients should use the first 3 and optionally use more if those 3 are down, but beyond the first 3 nothing is guaranteed.

Not every client needs to help users setup their relay lists direclty, they can pass users over to a different client or website that does it.

The main issue is that as a user's relay list grows, the probability for an event been in all of them decreases. This is particularly true for inbox stuff where notifications are quite spread out in the list.

I think every client has the duty to help the user setup all the lists they need to function. Otherwise, people will just complain that things don't work/nobody sees my content/I am being censored/etc.

That is also a main issue. Syncing would be useful.

Adding "outbox builder" to my to do list for applesauce. I've built a very flexible relay pool that doesn't have any "default relays" but I still have a long way to go before it can support the outbox model out of the box

although once I get there it might be easier to make micro apps. since I won't always need to build a settings view to allow the user to configure the default relays

i have two words for you: "directory events" - profile metadata, follow and mute lists, relay lists. these need to be available on all relays everywhere, for at least all of the users who post on a relay, all of their follows directory events need to be easy to find.

that's what solves this problem and i've been talking about "directory events" for at least a year now but nobody listens to me.

directory events need a consensus algorithm, basically. the rest, no, but directory events, 100% need to be proactively fetched and pushed wherever an npub appears, so should be all of those events connected to that user.

In NDK I do this via independent (and named) relay pools; outbox is just one pool, and nwc is its own pool, same for bunker connections or whatever; all independent pools -- makes this far easier.

nostr:nevent1qvzqqqqqqypzq3svyhng9ld8sv44950j957j9vchdktj7cxumsep9mvvjthc2pjuqqs2txvkjpa6fdlhxdtqmyk2tzzchpaa4vrfgx7h20539u5k9lzgqwgwcuew6