Replies (56)
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模型我感觉不太好用，要连的中继太多了，尤其是广场上的帖子，几乎可以说要连接到所有中继了。。。
Vitor Pamplona
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
@Alex Gleason 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.
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
GitHub
Releases · turizspace/hisa
Hisa is a community marketplace built on the Nostr protocol (NIP-99). Hisa aims to connect community members who need help with daily tasks with ca...
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?
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.
We don't want to pull events unfiltered. It gets ugly, fast.
We use the user's inboxes and outboxes, to an extent we feel comfortable supporting, and we integrate local relays.
We have it easier than most clients because we have community relays, which are also aggregators, and our focus is on making sure that community members can see each other.
I was originally doing it like
@Vitor Pamplona explained, but I it's too decentralized for a community client, as we're expected to moderate the threads a bit.
We also have server-side stuff a native Android client isn't dealing with and we have to be careful about the garbage we let people move over our machines. People be disgusting, fr.
Yes, but not only that. It's actually about supporting the Outbox model, so that when I set my relay list on client A, they’re automatically used on apps B, C, and D. And having the peace of mind of knowing that if my connections do the same, clients will actually fetch from their relays; no more, no less.
Lots of apps let users edit Kind 10002 (and other list events) but still hardcode a bunch of default relays and media servers, meaning users don’t really have control over where their content is fetched from or sent to. Ultimately, this is about giving the user choice; and once those choices exist, actually respecting them.
This is the way for Stela to post her personal content to friends on a small selection of relays, and for Anthony to blast his Haven release notes to as many relays as he wants, without either side feeling cheated or locked into a model that doesn’t work for their needs.
Of course, this creates technical challenges and inconveniences, and requires users to have at least a surface-level understanding of relays. But in my mind, freedom trumps convenience. And I'm sure thay with time we can have both.
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... :(
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.
What if the "community relay" is the sum of all outbox relays of each member? :)
That also works. We're doing stuff like that with Orly, where you have your follow list as the guide and it figures out the mailboxes for all of your follows and looks for their stuff over there.
That's more personalized and dynamic, but communities usually have some core relays, that are like hubs.
Like I was saying, a community expects some moderation, archiving, etc. from admins. Different that a more p2p setup.
I do both, but with different apps. Basically.
They do. But to me the "hub" is just the "hint" on how to get most of the posts/member information. Reaching out to people's outbox and inbox relays will bring more stuff that wasn't sent to those core relays.
But it does make things very complicated when you consider everything users can choose.
No, just like outbox, that puts responsibility at the wrong level.
What is wrong with Community admin just doing their job? They're value prop = taking care of hosting and moderation.
Why take that away from them? And give it to the actors least incentivized to do a good job. Guaranteeing a crappy, non coherent experience for everyone involved.
*Their
Yeah, we were gung ho on outboxes and then everyone's relay lists were really terrible and now we mostly ignore them. 😂
I have no idea why people find relay lists impossible to manage, but I've got no perspective, anymore. Too deep into the material.
Because admins don't get to choose what I say in their community. They only choose if I can post in the community relay or not. I can create community events anywhere I want. Which means clients can be built to show the "real" community that is not moderated. Which also means that clients that only bring moderated events will be bashed for censorship by members. I have been there. There will be conflicts between admins and members and when those happen, it's the clients that will suffer.
Well, we were building new, so that wasn't really a problem. But you end up juggling a gazillion connections and in the end they don't really use their relay lists. They just look at band. 😕
If posts are not there, those connections are basically zero cost. They are just checking in...
But if they are there. Then there is a massive difference.
Even I, don't care about my personal relay list beyond just being a back-up for my stuff.
I'd care a bit more about my inbox if I could put decent limits on it easily (money, auto-whitelist, etc....)
Those topical conflicts always arise because those people have their publications tied to ONLY that one Community.
That's not what I'm talking about (and building for).
We can do cross-community publications here. And step away from the false choice of posting in:
1 Community VS the global feed
Niche VS Reach
Also, because you don't have an outbox relay list for your profile, I now only see your posts after a while (after somebody re-broadcasts it to a relay that my user follows). And that only happens because Amethyst does a broader search for follows that we don't have lists for. In the majority of clients that are just implementing the base outbox, your posts might not even show up.
You'll be showing a different "real" community for everyone.
Defeating most of the purpose.
Tell that to the members when they complain about censorship. I want to see how that goes.
Censorship is part of the value communities bring. So of course I'll tell them, it's the marketing material.
And they can publish their Article, App release, Video, Story, .... to multiple Communities. So being censored yourself in one Community is less of a big deal + drives the people that resonate with your stuff organically to three other targeted communities (which can include your own that you're bootstrapping).
Yeah, communities are about moderation. Someone's personal relay is about making sure he finds all of the notes his friends have written. I think they're two different value propositions.
i woke up today and orly was broken. kept on dropping connections. tried different commits, same behaviour. i'm in the process of writing a minimal new reverse proxy to reinstate the go vanity redirector so it works again but it made me so mad i canceled all my VPS services.
i don't know whether it was the reverse proxy dropping the connections, or if something else was involved, so i'm working backwards to get it working.
@Kyle 🐆 just vibe coded an NWC client that can be set up to allow orly to manage a subscription scheme, 1 month free, and then you have to zap it like 6000 sats per month of use. when i couldn't get anything to work >_<
i'm in a very bad mood today. i'm sure it is the reverse proxy, but i wanted to just ditch the whole thing and cry.
What's orly?
Don't give up. Coding is hard.
i'm not able to be certain at this point if it was not my code at all but actually the fucking network connection. but i can't do anything work-wise at all either way. the new job is javascript and idk where anything is or what anything does or what needs doing there either.
at this point it looks like i'm gonna take a trip to the airport or something to pick up a prepaid data sim just to be able to get online again, since best case probably any other solutions are no sooner than friday and knowing how shit stuff is on this island, could be next week, and i need to be able to work by monday.
or i could just turn off the computer and stare at the ceiling and read the bible in between that. lol
well, one possibility, i just got done reverting the reverse proxy to the original codebase, and dropping in the nip-05 and go vanity redirects feature into it. if i deploy it and put orly back on the new VPS and run the test rig here it might prove to just be the reverse proxy after all.
i still need more reliable internet at this point tho. friday is another 3 days away. lol
Our network has been dodgy all day, and it's not in our house.
yeah, the geomagnetic storm also adding to the fun. and it rained last night after i finally got my washing done. and extra fun, this house doesn't have an earth circuit in the wall sockets and when i washed my rugs, finally, full of dust from the old place that makes my cat cough, i got zapped by the 240v - nbd tho, i mean 240V isn't that full on, you have to be really doing the wrong thing to get stunned by it, not even burned fingertips from the touch but omg
starting to regret moving right now, but maybe things will get better.
i have run out of nerves for today tho, probably gonna just try and sleep until the sun rises at this point. i got no brain left for any problems at this point, it's been problem after problem all day long.
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.
View quoted note →
