100 sats \ 8 replies \ @siggy47 12 Jul 2023 \ parent \ on: Portable experiences nostr
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?
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
This comment was featured on This Day in Stacker News.
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
reply