Portable experiences \ stacker news ~nostr

3657 sats \ 30 comments \ @k00b 12 Jul 2023 nostr

The nostr protocol directly solves two problems in internet applications: identity portability and data portability. Products built on nostr can depend on those two problems being solved. For most other equally challenging problems, the nostr protocol has no single or opinionated solution, or lacks a publicly proposed solution entirely. This is part of nostr’s design, nostr's protocol “is just the way people do things.” For products that aim to address these other challenging problems, their solutions will exist outside of the protocol and most products will provide them in a centralized way. If these other problems are difficult, important, and numerous enough, your identity and data on nostr will be portable but many of your favorite experiences on nostr will be centralized.

When the wheel was invented, some people probably just saw a wheel - a stone that moves reasonably straight and unhindered once it starts moving. Others saw a wagon, fewer saw an automobile, and even fewer if any imagined a rocket. But the wheel is just a wheel. Given a wheel, if you wanted a wagon you needed an axle and if you wanted an automobile you needed an engine. Yet, after running “the way people do things” loop long enough, we have rockets.

If people want nostr to be more than portable data and identity (and of course, all the many impressive things that directly follow), if people want nostr to yield the decentralized social media equivalent of a rocket, if people want portable experiences that they can't be banned from or censored on, we should be trying to specify and decentralize the popular centralized experiences emerging on nostr.

view all related items

120 sats \ 0 replies \ @OriginalSize 12 Jul 2023

Decentralization is a principle that needs constant reinforcement against the forces of convenience and convention. I fully expect users to centralize on a few web apps that don't burden the user with managing keys or browser extensions.

The relay situation is showing signs as you point out. Most clients use fewer relays and they aren't selected to maximize decentralization (ideally they'd be random with care taken to achieve overlap with max # of users). Amethyst should be applauded for its 19 default relays.

I suppose that from here it's just good to keep in mind that decentralization needs reinforcement so if you see a howto that doesn't touch on it, a nudge and sats to the author to fix it might be cool.

31 sats \ 9 replies \ @llamabyte 13 Jul 2023

we should be trying to specify and decentralize the popular centralized experiences emerging on nostr.

Such as Alby.

Alby has way too much power. Everyone is building on their extension, which is not friendly at all for the most privacy paranoid set ups.

10 sats \ 4 replies \ @llamabyte 13 Jul 2023

Not sure how to fix this, but being able to zap cashu tokens instead might be it.

31 sats \ 3 replies \ @k00b OP 13 Jul 2023

afaik Most of the important things that Alby does is proposed as a protocol. They are popular but they aren't locking people in.

0 sats \ 2 replies \ @llamabyte 13 Jul 2023

More info on the protocol aspect ? From what i know you need to sign up using an email, which means not condusive to a general protocol since account management is centralized.

10 sats \ 1 reply \ @k00b OP 13 Jul 2023

Nostr wallet connect and webln.

10 sats \ 0 replies \ @llamabyte 13 Jul 2023

Cool, my main beef with them is their extensions lack of support for, as i said, super paranoid OS's that will remain unmentioned. Otherwise they are doing good work

0 sats \ 3 replies \ @021e1f393f 13 Jul 2023

Yeah i think alby uses fingerprinting which i don't know why they do it

10 sats \ 0 replies \ @llamabyte 13 Jul 2023

Alby...Albeeee....beee.

Bee logo, mascot....

Honey pot......

hmmmmm

0 sats \ 1 reply \ @1GLENCoo 17 Jul 2023

Where in the code is that? https://github.com/getAlby

0 sats \ 0 replies \ @llamabyte 17 Jul 2023

It's not what is in the code, it's what is not.

Operating procedures, Open source is not magic.

Just because a company publishes it's code, does not mean what you are using compiles to what they are shipping, or their other design choices aren't part of a broader profiling risk.

They ask for an email, leaves a KYC trace. They don't support the most paranoid browser and operating system privacy conditions.

They are a risk just by being a registered company that can be subpoenaed for info.

31 sats \ 13 replies \ @siggy47 12 Jul 2023

Could you give an example of the popular centralized experiences emerging on nostr? Do you mean clients that mimic centralized ones, like blogstack or habla copying substack?

152 sats \ 12 replies \ @k00b OP 12 Jul 2023

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).

1067 sats \ 2 replies \ @super_testnet 12 Jul 2023

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.

10 sats \ 0 replies \ @Undisciplined 12 Jul

This comment was featured on This Day in Stacker News.

0 sats \ 0 replies \ @k00b OP 12 Jul 2023

There's definitely this kind of unintentional centralization happening too.

100 sats \ 8 replies \ @siggy47 12 Jul 2023

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?

1 sat \ 7 replies \ @k00b OP 12 Jul 2023

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.

100 sats \ 6 replies \ @elvismercury 13 Jul 2023

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.

10 sats \ 5 replies \ @k00b OP 13 Jul 2023

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.

1170 sats \ 4 replies \ @elvismercury 14 Jul 2023

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?

23 sats \ 0 replies \ @Undisciplined 14 Jul

This comment was featured on This Day in Stacker News.

reply on another page

10 sats \ 2 replies \ @k00b OP 14 Jul 2023

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.