> All new XChat is rolling out with encryption [...] This is built on Rust with (Bitcoin style) encryption
What does "Bitcoin style encryption" mean? Isn't Bitcoin mostly relying on cryptographic signatures rather than "encryption" as we commonly know it?
It doesn't mean anything, just sounds cool to people who don't know the tech well enough. Same reason why your HDMI cable is "gold plated for 10x speed!"
Gold plating electrical contacts does at least do something useful though, it helps to prevent oxidization/corrosion. A better analogy would be gold plated TOSLINK cables, which unfortunately do exist.
A lot of quack tech is technically somewhat useful. Oxygen-free copper, occasionally used in "audiophile" cables - technically is a better electrical conductor (compared to regular copper), by a whooping low single-digit %.
Exact same effect could be achieved by making conductor that very same single-digit % thicker. Which is an order of magnitude cheaper. And ohmic resistance is not that important for audio-cables anyway.
Sure, but we were talking about high-speed digital cables, not audio cables. When you're pushing 48gbps over copper (as in HDMI 2.1) the cable construction and connection integrity absolutely does matter, older HDMI cables don't work reliably at those speeds (if at all) despite having exactly the same pinout as the newer ones.
Gold-plating of contact surface of electric connectors is indeed genuinely useful, on account of preventing contact oxidation.
Assuming good contact in connector(s) is achieved, gold-plating does not further help with high-speed signals. What matters here - is wire/cable itself, specifically, tight control over where conductors are relative to each other and insulation, so that impedance is well matched throughout, cross-talk is minimized, etc, etc...
True audiophiles hold out for Low-background steel enclosures.
I can tell you're no connoisseur. Gold-plating a digital connector like HDMI makes sure the zeros are really round and the ones are really pointy. If you have the right setup you can definitely tell the difference.
The source of that comment is provably not someone with deep technical expertise so take that with a grain of salt.
Its there because he knows it’s going to trigger people and will get more attention
e2e encryption is easy if everyone knows public keys for everyone else. This is how GPG works for example.
However, the challenge is distributing those keys in a trustworthy way - because if someone can tamper with the keys during distribution, they can MITM any connection.
I assume this "bitcoin style" encryption is a blockchain or blocktree of every users public key now and throughout history. Ship the tree root hash inside the client app, and then every user can verify that their own entry in the tree is correct, and any user can use the same verified tree to fetch a private key for any other user.
I’m not sure you appreciate how large that data structure would be if you had to ship it inside the app.
The idea is to only distribute the root of the tree to a client, query the server for the username you want to look up, which then returns the key and a short proof that this username maps to that key within the hash tree identified by the known root.
How is that substantially better than an API that returns a user’s key?
If the service provider (ie. the X.com servers) are evil, then the API can return false data and the client has no way to know.
However, with a merkle tree, the root hash is embedded into the app, and the servers return the data together with info chaining to the merkle root (typically a few kilobytes, even if the whole tree is hundreds of gigabytes).
With that info, the app can verify the chain to the root and be sure that the servers aren't returning false data.
To clarify the above. It protects against endpoint compromise but depends on the assumption that the service operator (the one computing the root hash) is trustworthy. In other words it significantly reduces attack surface.
It can be done with Merkel trees. You just ship the root hash.
Merkel trees are snapshot/read only though - so you then use a bitcoin style Blockchain to ship refreshed versions of the root tree hash (you can even ship it in the actual bitcoin Blockchain if you like, piggybacking on its proof of work to ensure different people don't see different root hashes)
I'm sure shipping a >150GB file to every user is perfectly fine and sound engineering.
Parent comment writes: "ship[ing] the tree root hash", for a merkle tree ("bitcoin style") this would just be a single (small) hash no matter the tree size, i.e. 32 bytes is enough.
We pretty much know this can't be practically done in a distributed way. Even the public federated stores for gpg keys have been flooded so much they stopped being usable.