Nostr Web Client

>This part is the most egregious, because their "decentralized interoperable identity" is just one server that the Bluesky company hosts. How can that be defended?

Where is that coming from?

Yeah if you sign up on BlueSky's host and never claim your identity then sure, it's on their server. But you can claim it anytime. Their whole philosophy is let the user claim control when they're ready, and in steps. A user can rely on did:web alone for their ATProtocol identity and not use did:plc at all. You end up with a did.json file that conforms to the DID spec w your public keys, your handle (e.g. fiatjaf.com), and service endpoints like your PDS URL, and that did.json file lives NIP-05 style in location on https://yourdomain.com/.well-known/did.json. I get that many people won't claim their identity, but you can claim it anytime. Even if you set up just your web handle (as many users there have done), that's enough to be able to take did:web adversarially later. Once you claim did:web you are fully in control of your identity on the protocol.

If you're talking about did:plc then yes directory operated by BlueSky, though they've announced that's moving out, and my point is that (a) let's wait and see if does move out and where it goes and (b) you don't even need did:plc if you've set up did:web.

fiatjaf 9mo ago 💬 1

Of course I'm talking about did:plc, which is used by everybody except for about 12 weirdos who have set up did:web, and here you are writing a long paragraph as if did:web was this very obvious thing that all Bluesky users use? This is kind of a shitty argumentation move you have there.

Anyway, did:plc is the only thing that matters because you cannot migrate out of it into did:web, there is no such thing as "claim your identity". Even if it was, did:web is not decentralized anyway, it's just delegating your identity to another centralized third-party.

Fair comment on the12 weirdos, that is probably an accurate count of the current number of individual weirdos on did:web. I'm in this space for the B2B opportunities, and I'm thinking more about larger companies for whom did:web wouldn't be a heavy lift, and it could easily become a general corporate IT requirement in future. (Most of the current did:webs are probably larger companies or universities.) But just having the exit door existing isn't enough, you have to take into account the number of stairs to get to it, so okay, fair comment

And yes, fair comment on no crossing between did:web and did:plc, but again, what if in two months the did:plc directory is with some ICANN like body? Still not pkarr, but for most ownership-conscious people that'd be a perfectly okay compromise. A lot is hinging on where there directory goes and when. But they have announced it publicly, so it'd be hard to go back now.

You should focus on Twitter and Facebook then, same centralised identity and much bigger market.

If did:plc became like ICANN, they would have spent too much time spewing bullshit just to become what they should have started with; registering a TLD and give people domains on signup, instead of this DID garbage.

And the 12 weirdos are not businesses by the way, businesses don't give a fuck, hell even presidents their didn't care enough to point their domain to the did:plc.

If you are in it for the business opportunity, make sure to not get high on this supply, if you have to sell it to business good for you, I am rooting for you, just don't confuse yourself.

Most importantly; don't ignore all the signs that Bluesky users don't give a shit about any of this, so if you build a business assuming there is a market for digital sovereignty enthusiasts... you are going to lose your shirt.

I think Nostr is *the* protocol for businesses, I've been pitching Nostr these past months to businesses in Asia and a decent reception so far (though not calling it Nostr). I think the future of Nostr is B2B. As mentioned somewhere above I'd never pitch ATProtocol to a business.

My main point at the start of this all is simply that ATProtocol is not a scam. It's a decent attempt by decent people, and it has a chance to evolve in a way that would be good for the internet at large. I'm mainly just tired of the hyperbole and the throwing of rocks when it comes to ATProtocol (and ever so often, Farcaster). That's all.

Ok, I will bite, what does Nostr offer businesses? Because my basic bias is that it offers absolutely nothing, if anything the shitcoin Wallet Connect offers more because at least you know people who use that have money and likely to waste it on stupid stuff.

What does an npub and very unreliable relays and extremely small audience offer businesses?

Cross-company social that functions like email and can also be used by frontline workers and vendors on both sides (those with no basis for SSO). It competes with https://slack.com/intl/en-gb/connect and other offerings. It's cheaper, it's open source, no third party, it's easy for IT departments to understand and with relays on both sides of the fence it can be managed as each side likes. It mirrors email in many ways, and you sell it with email analogies.

Also competes with stuff like https://uintra.com/ but only for the cross-company case.

-Current nostr audience is irrelevant

-Zaps are irrelevant (unless the companies in the mix want them, but we never pitch them).

-The Nostr brand is irrelevant (nobody knows it anyway)

Event+relay architecture w redundancy, keyparis, and the open-source candy jar of client code are all very relevant. Overall lightness is relevant. Clients are custom-deployed from open source (each side has their own client and our team will service it). We plan to use one client codebase for all customers at the start.

Early days and just pitching for feedback but so far is good.

Course none of this is what Nostr was invented for. But if you were going to draft up an architecture from scratch for cross-company social in the vendor age then Nostr is kind of like the thing you'd end up with.

I think you are thinking of the Matrix Protocol... which plenty of governments already using for what you are saying instead of relying on American companies like Slack.

If I were you I would start playing with Matrix sdk before reinventing this wheel.

Matrix we looked at but Nostr events and relays are about as complicated as we want things to get, and this is also more of a Kind1 play. This https://bettermode.com/ is an example of one we were asked to pitch against the other week.

Our pitch is if you're going to be brave, pass over the other guy and take things in house, then you're going to want the most dead simple thing possible. Nostr is pretty dead simple.

The reason to stick with Nostr is getting grants from Nostr enthusiasts... but if you need that more than flexibility to address your market, then you are doomed anyways in my opinion.

Garbage nsec 9mo ago

Let's see, if we start doing some good business off these implementations then there won't be much more to say. At that point it'd simply be one of a thousand proven B2B business models and you slowly expand with sales. There isn't anything out there that both covers that particular niche and is as dead simple, and so far we've got good interest and moving to POCs in April.

I'll give you an update come the summer.

I know zero about pubky. Melvin posted about it but I can't parse those. Is it B2B leaning?

nostr is the minimum viable decentralization. Anything less than this is not viable, or not decentralized

Decentralisation is a moving target.

You look at the web itself, it started with a protocol (HTTP) and a single client, a browser called "WorldWideWeb", which they renamed Nexus in 1994 to avoid confusion with the broader concept of the World Wide Web. So the first "WorldWideWeb" was basically Chrome. And that means the web at first was totally centralised. Other clients then appeared and evolved, making HTTP more robust (Line Mode, Erwise, Viola, Mosaic...)

This idea that HTTP appeared and then the web just sort of "happened" on top of it is widespread but totally false.

That's the path ATProtocol has said it wants to go. For that to work the protocol has to get more and more decentralised as time goes by, and that means more and more independent implementations have to appear to take away market share and mind share from the Nexus-like flagship demo.

That's how many decentralised protocols have developed. And the opposite is also true, many protocols that started off pretty decentralised have gradually become more centralised over time (which arguably is what's happening vis a vis Nostr relays if you go by nostr.band stats).

Time dimension is important.

fiatjaf 9mo ago 💬 3

Given that you have established that starting decentralized or not is irrelevant, what should we consider when assessing the decentralization status of a thing?

Incentives (and possibilities).

Any reasonable person can see that Bluesky will remain centralized forever because of identity centralization and data centralization, in fact it cannot be decentralized at all because the identity system is centralized by design (because they wanted to do a blockchain for key rotation but couldn't figure out how). All one can argue after that is that is that "it doesn't matter" because "login is easier".

While Nostr has much bigger chance of being decentralized, although it could also fall back into a "de facto Bluesky" mode and have its data all centralized in one place, but that would be a very unlikely hard failure edge case from which it could even recover later if developers wanted.

The web was never centralized because anyone was always able to run the client or set up a new server without asking anyone. Without integrated identity or DRM there were no centralizing forces. Bluesky wants to be able to protect communities via "the right" moderation and identity management. This is core to the value of the platform, and also prevents it from ever being an open system. Free as in beer, not free as in speech

That's factually incorrect on petty much every level.

🤷🏻‍♂️ Show me

Moderation is at the AppView level, not at the protocol level. If you create an AppView you can choose to use bsky.app's moderation, or use another app's moderation, or use no moderation at all, for the same base of user posts. Far as I know the relay does do sybil attack and CSAM mitigation, but that's about it, and there are other relays going up, each of which is free to choose how it tackles CSAM, etc.. Or an AppView can pull directly from a set of PDSs without a relay in between. Or a bespoke partial relay.

With a raspberry you could spin up an AppView in a few days that shows all the posts that the bsky.app moderation team has taken down, minus presumably the illegal stuff that by law they had to deal with on the lower-infra level.

Fiatjaf's argument would be that other Kind1 type clients are incentivised to just reuse bsky.app's moderation since it's way expensive to do one's own moderation, and that argument holds weight--but again the time dimension, we need to wait and see how this plays out over time.

First let's establish that bsky.app is not decentralized. They hold your keys and your data. If they disagree (morally or legally) with what you say, you have no recourse. Since they hold your keys, they can rewrite your history however they wish and it will be authoritative.

Your argument is really that ATproto is decentralized. First, I would argue that it's federated, as users have a "home" PDS. This is different than nostr, where you can spray events across every relay, or store them in a file, or send them to a friend over BLE, and they are *equally authoritative*.

Second, these ATproto apps aren't actually using ATproto: they're connecting to a Bluesky API. Perhaps they use a serialization format from ATproto, but they're simply asking nicely for AppView to take actions.

Third, it doesn't matter what ATproto is capable of, as people are there for bsky.app. Important features like account management, message deletion, and content filtering are done inside bsky and not using ATproto.

So, as fiatjaf points out, when bsky decides that doing everything in a truly decentralized manner is too difficult and sunsets ATproto, no one using the service will even be bothered.

Just like XMPP