Give me one recent example of BlueSky making a breaking change to:

app.bsky.feed.post

app.bsky.actor.profile

or any other core lexicon (before the very early days way back).

If you can post the before and after, and it's not two different lexicons, then I'll owe a nice dinner next time you come to Vietnam.

The reason they can't is the domain is just used for publishing at first and for publishing non-breaking changes, after that it propagates. I think maybe you're mixing up the API and the lexicon system.

You can't make breaking changes to an ATproto lexicon, that requires a new lexicon. The point about it being a lexicon is that it's not actually a javascript embed (ok calling it an embed type before is the wrong word). You're writing the comment to the PDS in a way that means the comment will be picked up in the additional site(s) where you want it to be picked up, and there's benefit there (versus something like Facebook comments)

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.

I'm for anything that weeds out this "why not?" type of interop that just dials up the cognitive load for end users. The kind where the end user has to open a post in12 clients and then assemble a serial killer hunting pin-board with strings and polaroid photos to figure out what the original poster's intent might have been.

But I do think there is incentive.

In an embed context (my lexicon represents something non-core in your app) there are incentives both ways, you get your stuff embedded, I get that added info for my users, win win.

In a piggyback context (one app clearly just riffing of another) there's incentive to piggy back, and there's incentive to be piggy-backed off of, so also win win.

In most other contexts, probably no. So very context dependent.

Potentially unpopular opinion: Nostr should adopt ATProtocol-style lexicons.

ATProtocol lexicons are good because they encourage more detailed Kind schemas.

Let's take the example of NIP-29 chat groups and how the same group can look very different when viewed in 0xchat versus when viewed in Chachi. Want one thing to look right? Open the group in 0xchat. Want another thing to look right? Open the group in Chachi.

In ATProtocol it would be like this. Chachi comes into existence. When it does, 0xchat already has a hyper-detailed lexicon schema (com.0xchat.message) and this lexicon leaves little grey area—maybe some cosmetic grey area and that's about it.

On day one Chachi has to make a choice. Follow this hyper-detailed existing 0xchat lexicon or create a new Chachi lexicon. If going the first route, Chachi declares the 0xchat lexicon in each event that Chachi sends ("$type": "com.0xchat.message”) and by doing so Chachi is saying “I agree with everything in this very detailed schema of theirs and if something isn’t right then I’m the one that’s out of line, it’s me.”

If going the second route, Chachi will not be interoperable with 0xchat.

That's just the choice Chachi has to make. Is it worth it to forge a new path? Or is it better to piggy-back off 0xchat's success? Maybe there are other clients also using 0xchat's lexicon; does Chachi want to be on that bigger team? Or maybe Chachi has a super feature idea and it’s totally fine to go it alone, the users will come for that feature. Either way, Chachi has to make a choice, and it has to make that choice on day one.

You could say that the Nostr way is pretty much the same as the flow I just described above, with only minor semantic differences. Chachi has to choose to follow a NIP (and a Kind) on day one, or to go it alone. Like Flotilla went it alone at the start. But no. It’s not the same in substance. Of course Chachi does have to choose a NIP and a Kind on day one—but Nostr Kinds are like laws in countries where the authorities have left themselves a *lot* of room for interpretation. Singapore this is not. Rather this is more like [insert name of murky country here]. Did you break the law? Maybe you did, maybe you didn’t, depends on who’s asking who and why.

The current Nostr way allows devs to procrastinate, put off the “tidying up” until some undetermined point in the future. And the one who pays for that procrastination is always the user.

In short ATProtocol lexicons both allow for and encourage a significantly higher level of detail and expressiveness—and in doing so they tend to force tidiness from the start. If you take Nostr’s Kind1 schema and compare it to app.bsky.feed.post (their Kind1), and not only that but all the lexicons that app.bsky.feed.post references (such as app.bsky.richtext.facet and app.bsky.embed.images and app.bsky.embed.record ...) it's quite clear we’re looking at an order of magnitude difference in detail. And at the end of the day this is all about detail. That’s where the devil is. And the devil is having a lot of fun on Nostr these days.

If you're an ATProtocol developer and you've got a cool idea for, say, a VR client, and you decide you're going to re-use the app.bsky.feed.post lexicon and all its mandatory entourage—well there's very little wiggle room for you. Either you state outright that this is your lexicon in each event and you stick with the program—or you don't and you make a new lexicon and you declare that new lexicon explicitly in each event. And that’s good. Because over there devs can't just say to users "you know what guys, you figure it out". The devs have to figure it out themselves. And beforehand.

So why the lower level of detail for Nostr?

One reason Nostr Kinds are less opinionated is to increase the chance of being merged on Github. Meaning much of this is psychological (as opposed to technical, given that in theory there is no limit to how detailed a Nostr Kind can be, though there are also technical differences that give ATProtocol lexicons more expressive power). Nostr kinds are discussed—and discussed, and discussed some more. This has a watering down effect.

ATProtocol lexicons are discussed too, but in fewer situations, and the discussions end sooner. Part of this is because there is no two-tier system of “merged” and “un-merged”. (On Nostr an un-merged spec is a little like a second-class citizen, and devs feel a lot of pressure to get their specs merged and first-class-ified). ATProtocol lexicons also start off with devs and their unique ideas—but they aren’t ever merged. You can have a much-copied lexicon, one that say five or six other clients make use of. And you can have a solo lexicon, one used by your client alone. That’s where the difference is. This means that on ATProtocol it’s all about traction. Not traction in order to make the case that your PR should be merged. Just good old traction.

Of course the downside to lexicons is that devs with clients that have good traction gain a lot of lexicon power. If I make an ATProtocol client for publishing serialised fiction called CheeseRead, and my chapter publishing lexicon is com.cheeseread.chapter, and I get a lot of users, and a few other serialised fiction clients emerge (maybe for other operating systems), and they use my com.cheeseread.chapter lexicon too—then I’m in a pretty strong position. And bonus: I get to feel proud of myself because all these other clients have my brand showing up in their event json.

This doesn’t mean I can screw with the lexicon and break things on their end. Under the rules all old data must still be valid under an updated lexicon, and new data must be valid under the old lexicon, so new fields must be optional, non-optional fields cannot be removed, etc. (or a fresh lexicon is needed). But it does mean that it’s harder for other clients to pull users from me because my client is going to be very optimised for this lexicon. (Mind you this can also be a good thing because it means others in the space have to think beyond copy-paste.)

All in all though, there’s something to be learned here. ATProtocol lexicons are more decentralised—due to there being no “PR & merge” concept—and more practical—due to how much grey area they usually remove.

The lesson for Nostr: there is no point in getting everyone on the same page if that page doesn’t have enough words on it.

The ATProtocol lexicon concept is a smart concept that can be borrowed. It encourages what I call “fearless detail”. At any rate Nostr has to move off Github sooner or later, so why not dump both the platform and the flow at the same time? And jump on the lexicon train.

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.

I refuse to learn what a PassKey is

What does this say?

I think DHTs are neat too, and maybe cool for relay discovery, someone needs to write a nip for that 😛

I do love Rostra (and other P2P social things), but you will always run into this issue of compute.

People want a feeling of security and safety. They want Access Control Lists, friend requests, permissions. You need compute for that.

It’s why I still believe in Urbit. It’s the closest thing to a digital home we have. P2P social + safety and security. Users actually have their own compute. And it’s understandable where data lives (at my house, at your house, etc)

WTF dude yes

Sorry sir, but you lost me here.

What's mlkut? What's Peergos?

And how could Pkarr be a better solution for Communities/Groups?

"jobs" meaning what

Let's start ove, and start small, from the minimum viable digital sovereignty and grow from there, worst case scenario we achieve something really good but not popular... Social media is an all or nothing, when it fails to take off, it crashes and burns, with absolutely nothing left standing.

Let's ratchet progress on digital sovereignty, we already have miraculous foundations (Bitcoin, Mainline, and Cryptrees) all of which was invented around the same time for some reason!

It is our turn to make the new wave of tech and products, and we should build them with soundness and care, that they can germinate and survive to be passed on to the next generation, even if this one simply never gave a fuck.