I’m just now reading some of your other posts, eg where you say:

“My entire argument is that I'd like a clearer description of the thing that was implemented, so that I know if my own implementation counts as the same thing or a new thing.”

This is a reasonable and understandable thing to want. But it’s worth asking: who decides — especially if there’s a controversy? Who’s in charge? Fiatjaf, I suppose. But is that how we want it to be? Someone who makes decisions that we are all obliged to follow?

So this is where I’d point out some of the tradeoffs between a centralized vs a decentralized set of communication tools. Decentralized tools must necessarily be highly tolerant of ambiguity. We see this in human language. They must be flexible bc there’s no one in charge to enforce specs, definitions, etc on everyone else in case of controversy.

Why can a misplaced comma “break” an entire app? Bc centralized languages are not designed to tolerate deviation from The Rules. Human language, on the other hand, is designed to be robust: conversation doesn’t come to a screeching halt just bc conversants disagree on some minor (or even major) detail regarding definitions, grammatical rules, etc.

We need to learn how to make digital tools truly decentralized: flexible, robust, and tolerant of ambiguity, just like the spoken word. Nostr is the closest I’ve seen but we’re still VERY far from it.

Reply to this note

Please Login to reply.

Discussion

I think this is exactly what is interesting about nostr. Hashes and signatures buy you a LOT. In theory, all you have to do is validate them, and you know you're dealing with good data. In practice though, there's an entire meta layer on top of the data itself defining the schema. Even if this schema is well-defined, every possible malformation has to be interpreted. In many cases malformed events can just be ignored, but there has to be some ability to tolerate a slightly different version of events. In a negative light, this leads to undefined or broken behavior, but in another sense it leads to emergent behavior — i.e. the ability to use existing structures in new ways.

Maybe someday all the clients will use LLMs to interpret events 😂

great thread, in order to achieve this a mindset is needed which is going to be a mission on itself.

we have been conditioned to think centralised and to change this mindset it will take time and patience just my 2 cents even I am not a devloper per se

I (like so many) have been obsessed with tackling the decentralized web for many years. It was not until a few years ago that I began to consider that the decentralized curation of human language might have something to teach us.

I call it “social linguistic consensus” — our ability to agree on the methods of communication without the need for a designated centralized authority over any aspect of any of these methods.

In the human realm, the existence of social linguistic consensus is so familiar that it’s easy to overlook how remarkable that it exists at all. Pick a random word from the dictionary or a random rule of grammar and ask: who decided that? Assuming it’s a non controversial detail, the answer is everyone (we all agree) and no one (no one has the power to change or enforce this definition or rule).

But in the digital realm, it’s the reverse. Every repo has a maintainer. Every computer language, every ontology, every standard has someone — a company, a committee, someone — in charge. And the absence of social linguistic consensus in the digital realm is so stark that it’s easy to overlook that it could be any other way.

So I’m writing up a paper right now where I describe what I call the tapestry method, which is a way to represent knowledge (encoded topologically in a graph) and curate knowledge (using a web of trust) designed specifically for the purpose of building social linguistic consensus. I postulate two things: that the central nervous system already uses the tapestry method; and that if we want to build the decentralized web, we ought to build apps that employ the tapestry method.

I’ve already built an app using this method, but it’s too big a task for one person. (Well, maybe Pablo could do it lol … but it’s too big for me!) Needs a team. So I’m hoping my paper will motivate one or more teams to do it.