Nostr Web Client

Someone tried to blackpill me today. But I coughed it up and spit it out.

The blackpill was that decentralized systems can't innovate because it is too hard or impossible to make breaking changes. Centralized systems like facebook can just innovate without permission or compatibility and so they will always innovate much faster, and so decentralized system can never keep up and will never compete with them.

I partially agree. Yes, centralized systems can innovate faster. Yes, it might always be that most people will be on the centralized systems.

But where I disagree is this: Centralized systems keep letting us down. And some of us are happy enough to use a decentralized system for a subset of our social media, to have at least some level of reliability and trust that we can depend on.

Moxie Marlinspike (fittingly named after a knot) poo-poo's decentralization here https://www.youtube.com/watch?v=DdM-XTRyC9c

but much of what he claims is wrong, adjacent to the truth but not quite correct or meaningful.

Let's look at breaking changes. Consider how breaking changes can occur:

1) You go around and get everybody to update their software (PITA and eventually impossible)

2) You just give up on the feature and decide we can live without it (a cop out)

3) You version the protocol.

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 valuing simplicity rejected (3) in his writings early on for nostr. Because versioning multiplies complexity. You have to keep all the old code and have case dependent code for the newer code.

But I still believe that (3) is the only way out, and growing complexity is inevitable. Yes of course any change that can be made non-breaking is definately the preferred approach, but not everything can do that.

There are real world examples of this that are working just fine. The Vulkan API is in a sense decentralized. It works on many different hardware devices and with many different OS vendors. It is versioned. How did it not ossify? It's a fucking mystery ain't it?!

Also, Moxie talks about IPv4 not being able to get to IPv6 and IPv4 ossifying. But fails to mention the obvious: IPv4 is the greatest success story ever. Damn near everybody uses it all the time. So who cares if some parts of it have ossifed? Not me. And to be honest, parts of it (like congestion control) were able to change very late in the game. So this is a piss-poor argument against decentralization.

Also, Moxie talks about how many people are programming stuff and you can't keep up with all of them. But he fails to mention that less than 10% of those people are useful. Or that the management interference almost necessarily breaks any useful thing they end up doing. Against the view of all the pundits (Bill Gates most notably) open source software supercedes commercial software in almost every domain. Because in open source, and with decentralized solutions, the entire world participtes, rather than just one or two buildings in Redmond. And generally only the most intellgent high-IQ people can pick it up and run with it, meaning you have a worldwide team of highly intelligent people versus a limited commercial team that is mostly deadweight and plagued by managers who want to make their mark.

I may not be a bright-eyed (red eyed?) bushy-tailed spring chicken bitcoiner who is upbeat about everything and believes everything is possible. I'd say I"m a bit more cautious than most about what I hope for or aim at. But I am still a "can do" person and I will never stop trying.

*spits out the black pill*

Daniel Wigton 5mo ago 💬 2

One note on versioning.. it can be a form of centralization. Someone has to assign the numbers. This works well for common software projects, but I am kind of a fan of just making everything a hash.

Define your interfaces then hash it. That hash is your version. If you have some common way of defining interfaces, then even if a particular protocol gets reinvented two star systems over, they will interoperate just fine.

The more likely case where the people two star systems over go a different direction also works. You won't both end up with conflicting version numbers when you iterate from the same base.

The main problem is that 32 bytes of version numbers is a lot. We need ways to help people know what they are using. (If they care)

Reply to this note

Please Login to reply.

Discussion

Mike Dilger ☑️ 5mo ago

That is a good point. But I'm not as concerned with specification centralization. If that is attacked, well, people fork it. And we have to rely on people converging on something anyways, which means it will be forked but somehow there will be the most popular fork which people will follow. Hmm, reminds me of blockchain.

But as to the details, I'm inspired by a number of different mechanisms none of which I'm committed to. TLS uses a list of available algorithms, and social media could use a list of feature extensions... at least for additive. Or it can be FEATUREA_V1 and also FEATUREA_V2 where a server might support both for a long time, until V1 died out.

Daniel Wigton 5mo ago 💬 2

Yup. I am a bit torn as well. I've toyed with a few ideas.

I have some code that defines how a file can be saved a zillion ways. It uses 4byte enums. Note not u32 because screw endianness. Every file is just a byte string. The first 4 bytes tell you the encryption method. Strip those of and use the corresponding algorithm to decrypt. The first 4 bytes of the decrypted file tell you the compression algorithm. Strip them off and decompress. The first 4 bytes of that tell you the serialization method (file type I guess)

Makes it easy to just add new algorithms.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago 💬 1

i'm a big fan of compact semi-human-readable sentinels in binary data formats where structure is flexible. i'm using 3 byte prefixes for a key-value store to indicate which table a record belongs to.

same reason i hate RFC numbers BIP numbes and kind numbers and nip numbers. they mean nothing without a decoder ring. they should be descriptive, or gtfo

in any case though, if you are going to need lexicographically sortable numbers, you want big-endian.

it's just nutty to use a number when the thing could be a mnemonic and is not going to be so numerous that you can't fit it into 4 letters.

btw, this is a long established convention, the Macintosh and Amiga system libraries both use this convention of 32 bit mnemonic keys, to indicate filetypes, as key/value structure keys, and so on.

humans are not fucking rolodexes. language is words, not numbers. it is irrelevant that words are numbers: numbers are not words.

Garbage nsec 5mo ago

> it is irrelevant that words are numbers: numbers are not words.

100%. Unless we want to remove the human brain from these systems altogether then we'll have to deal with its word-centric processing.

Daniel Wigton 5mo ago 💬 1

It depends on where you are in the tech stack. UTF-8 or even ASCII is not human readable, they are bytes that need to be interpreted as such and rendered as glyphs via a lookup table and a graphics engine.

If required, you can do the same for any enumerated type. The nice thing about text encodings is that they are widely accepted and have many implementations of renderers.

But if you are doing the tech right, most of your base protocol is not going to be human readable, not because legibility is undesirable, but because it is nigh impossible.

Think of the raw data on the line. You need source and destination IP addresses and port numbers. Then you need something like source and destination node IDs, an ephemeral pubkey or nonce (depending on your primitives)

The rest is just gibberish because it is encrypted. None of that can be easily made parsible by humans.

Next you have the task of turning that encrypted blob into something useful. You need more keys and signatures etc. Eventually you get some final decrypted unpackaged data that you hand off to the client application. The underlying protocol doesn't care what the bytes it encapsulates/decapsulates are. It can't, if it knew anything about it, you'd be leaking metadata for men in the middle to hoover up.

Once you get to the client application, I agree with you. You want your data to be human friendly.

Generally I am a fan of being careful of how complex data in social media etc gets interpreted because people tell lies. For instance, do you translate an npub into the name its owner chooses, the name the viewer chooses, or a name the community chooses? Same with profile picture.

The first sounds good, but you get impersonation or other lies. Numbers on the wire have to be interpreted the way the recipient wants, not the way the sender wants.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

the decoder ring for UTF-8 is always available. a decoder ring for the meaning of kind numbers or BIPs is not.

you don't even need type values if your structure is rigid, like nostr events, you just define an encoding order, and if the field is fixed length it's redundant to have a length prefix for it.

also mentioning network addresses, even those are handled in a human readable form, and not the native. native form of an IPv4 address is a 4 byte for address and 2 bytes for the port.

anyhow, yeah, of course, you use whatever fits the task best but one of the biggest reasons i favor mnemonic sentinels in binary data is that these are stable values. if you define a series of numbers and a whole bunch of them become deprecated, there's holes in the number space, you can't reuse them without a breaking change. a 2 or 3 character sentinel (or even 4) is never going to change, and has enough space so that you can just add more with such as an extra character signifying version or whatever.