152 sats \ 10 replies \ @k00b OP 12 Jul 2023 \ parent \ on: Portable experiences nostr
I mean relays that are centralizing all notes into their own mega-relays to provide experiences that aren't feasible without centralizing all notes. I don't really want to call out any particular project but most of them have popular clients that are really nice.
It just feels like decentralization kayfabe, ie they aren't upfront with their censorship powers and borrow heavily from nostr's halo of decentralization and call themselves nostr clients because they're nostr interoperable yet dependent on centralized data (relative to other nostr clients).
One thing I've noticed: almost all nostr profiles have a display name, a picture, and a bio, and almost all of them seem to be stored exclusively on relay.damus.io. I've connected to the top 5 relays on nostr.watch, queried for metadata for random accounts, and I only get responses from relay.damus.io. No one else has that data.
I have a theory about why this is too. I think it's because so many people use the amethyst and damus apps, which start off with damus as a default relay, and the first thing they do is create a profile. So that info goes on the damus relay. Later on, they may add other relays or remove damus. But when they created their profile, damus was their main relay. Consequently, damus has almost all profile data, and basically no one else does.
I know one way to help solve this. I could write an app that downloads all metadata posts from damus and rebroadcasts them to other relays. But it feels like there's an underlying problem there that this idea doesn't address. The underlying problem, I think, has to do with the intersection of "wanting to set reasonable defaults for your users" and "not wanting to make everyone reliant on just one relay." Setting people up on the damus relay by default is a good idea, because so many people are using it. But defaulting to damus also means damus has a bunch of data that few other relays have. And right now, at least for profile data, it seems to me there's an imbalance toward the latter.
reply
There's definitely this kind of unintentional centralization happening too.
reply
I had no idea this was the reality. Are they assuming there's always going to be a tradeoff- convenience and smooth user experience versus decentralization?
reply
I have no idea what they intend. They seem to be well liked in the community so perhaps they mean well.
My point here is that I think nostr would do better to try to solve some of the problems centralizing appears to solve rather than explicitly cheering it on.
reply
How much of this is the inherent affordances of centralization vs decentralization? People in btc seem to have swallowed the hook about "centralization = bad" but revealed preferences show that people love almost every facet of centralization for almost every use case 99% of the time.
Seems like, empirically, the only practical way the decentralized vision can happen at scale is that the most basic aspects of the network (whichever network we're talking about) are decentralized; then, when centralized actors do things that piss people off, a sufficient number of them are moved to adapt slowly and painfully to route around it.
This seems the only method that's ever worked in practice -- projects that stay too "pure" from the start never get adopted, and projects that don't have the decentralized property in their DNA get captured eventually, with no redress possible. The best way forward is the unsatisfying middle.
reply
I agree that there's a middle, and that there's a balance between UX and purity, but it's more like a tug of war than a territory. The middle has to be fought for.
Seems like, empirically, the only practical way the decentralized vision can happen at scale is that the most basic aspects of the network (whichever network we're talking about) are decentralized; then, when centralized actors do things that piss people off, a sufficient number of them are moved to adapt slowly and painfully to route around it.
This is about as idealistic as centralization = bad ime. Email is a prime example of people not being able to restore control after the number of federation members grows too small and too powerful. afaict This is Nostr's fate if it doesn't solve more hard problems in the protocol. It will be kind of censorship resistant until it isn't.
reply
I get your point, but this seems to me one of the (rare) differences where "technically possible but empirically infeasible" vs "technically impossible" matters a lot.
It's super hard to run your own email server, but not impossible. You can imagine a bunch of people getting sufficiently pissed off by the current state of affairs that they start confederating and forming pacts to do email relay with each other. The bar to enough people (not just nerds) caring about this is high, for sure. But it could happen. The reason it hasn't happened is that 99% of people don't give a shit.
Maybe that's what I'm saying: whatever the tech, the "how many people give a shit" problem remains, and there is no technical solution to that problem. What you can do (given the revealed preferences I described) is make it so that, once that threshold is reached, you have designed so that there is some recourse.
Although now that I say that, I guess the devil in the details. If you need half the globe's population to give a shit, maybe that is essentially the same as "impossible." So maybe then you're in a pickle? Design to avoid capture, where the "give a shit number" is low enough, but also keeping in mind that the "give a shit number" is directly correlated w/ p(adoption)? Low GASN (so it doesn't require that many people to care in order to rebel under tyranny) = low p(adoption) (because the precautions make the system so annoying and ornate to use that the liklihood of critical mass is lower)?
So: can the "contested middle" nostr solutions you imagine survive that equation?
reply
Great analysis! You've summarized the contest for the middle between UX and a higher order intangible really well.
Solutions must either minimize this contest, making them less anti-parallel by providing HOIs with little UX sacrifice, or introduce another contestant.
When I think of architectures that manage to do this, two things come to mind: the internet, bitcoin, and (potentially) lightning.
- the internet is relatively stateless, so the middle isn't much contested. UX and HOIs line up extraordinarily well.
- bitcoin and lightning financially conflict network participants introducing money as a third contestant
I don't know how much you're interested in the details of nostr but it's probably cleaner to keep this abstract. Within the protocol, nostr should be doing as much of (1) as possible and as much of (2) as required to keep the network decentralized.
reply
Could you define HOI for me? Not familiar w/ the term, and googling has not helped. :)
reply
Oh lol my bad higher order intangible