I've spoken before about some of the challenges I see regarding true decentralization for #Bluesky.

reverse colexicographic Nora

For reference:

- Bluesky supports only did:plc and a subset of did:web. "In the future, a small number of additional methods may be supported. It is not the intention to support all or even many DID methods, even with the existence of universal resolver software." [1]

- did:web requires that users manage their own key material. [2]

1: https://web.archive.org/web/20241126020149/https://atproto.com/specs/did
2: https://w3c-ccg.github.io/did-method-web/#key-material-and-document-handling

reverse colexicographic Nora

This post is deleted!

reverse colexicographic Nora

I bring this up mostly because I find this problem to be a particularly frustrating stumbling block. If there was a proven way for users to handle their own key material without either consigning it to a third party, thus compromising it, or being at risk of permanently and irrevocably losing access to their identity and data, it would be almost trivial to build large, robust peer-to-peer networks. We have the technology for NAT traversal, for peerfinding (via rendezvous hashing and DHTs), and for routing messages through such a network. But even if a feature-complete P2P Discord equivalent was built, few would use it, because managing keys sucks.

So it frustrates me when Bluesky, claiming to be totally committed to decentralization and "credible exit", simply does not address this issue. They pretend it does not exist.

reverse colexicographic Nora

For example, let's imagine building a born-P2P chat system supporting inline images, custom emoji reactions, and username changes.

For identity, we'd use DNS. By placing a signed attestation and unique ID in a TXT record, a user would prove association of a domain name with their network identity. Then, others could look them up by that name.

For data storage, we'd use IPFS. IPFS has a lot of issues, but it's uniquely suited to a chat system, because we can feel pretty sure that *someone* is interested in the posted material as soon as it's available, and material posted to a large group would get spread quickly and served from a wide client base. Altruists could host pinning servers, but it would also be pretty easy for third parties to provide a cheap, paid service that pins every file a user sends, with basic webhook support in the client. This would make per-user custom emojis and custom emoji reacts very easy.

Communities (guilds, Discord "servers") would also be set up via DNS TXT records which would set their owners. Those owners would then be able to set permissions for other users in those communities. If community owners were willing to host or pay to host chat history, we'd get that via IPFS too.

For actually connecting clients, we'd use Kademlia, either via libp2p or the I2C anti-identity-spam implementation. Or some fancy new DHT that I don't know about Nodes would store all the ways they know of to connect to themselves, indexable via the unique ID used in their DNS attestations. New nodes from the same user would coordinate updating their associated records to include all online nodes for that users. Heck, if we really want, we could build this atop IPFS/IPNS too!

Chat history between individuals could be handled via IPFS, with the same pinning-for-hire setup to handle the case where all of the user's devices which have the history are down. It would be a personal, encrypted record, so it would be free of tampering and there would be no fear of hosting it somewhere untrusted.

Voice and video have all the normal complexity of WebRTC, but no more than that; it's totally doable.

All sounds great, right? Mostly proven tech, just glued together in a way that supports ephemeral communication for free and allows users to get chat history, persistent images/files, and personal emojis in a decentralized, commodified way.

But it all relies on the user managing their own key material. And that will not work, which is why nothing like this is widely adopted. If you're interested in what software like this actually looks like, https://retroshare.cc/ does a lot of this (though not all.)

ルビーちゃん

@noracodes [demonic thought] let the USPS (and other mail services in other countries) handle user credentials. They already handle my mail key being lost!

Semitones

@noracodes I thought I saw that Destin @ smarter every day was backing a startup that purported to facilitate user-managed keys, but I can't find the video now

reverse colexicographic Nora

@semitones ah good, military contractor key management

James Brown

@noracodes Idolizing self-managed cryptographic keys is basically the idea behind nostr, right? Which is exclusively used by cryptobros...

reverse colexicographic Nora

@roguelazer Right, that's exactly my point. Most people aren't willing to deal with it.

Idolizing is a weird word to use here, imo. It's a technical solution to a technical problem.

James Brown

@noracodes I originally wrote "fetishizing", actually, because I feel like nostr really loves to talk about cryptographic keys a lot and put them in the front of everything.

Raymond Neilson

@noracodes And for every p2p chat setup - especially the ones heavily reliant on IPFS - there's also the entire mechanism of moderation missing.

In Bluesky-land that's not only entirely performed by Bluesky PBC, architecturally that's all done in the appview and feed layers. I have absolutely no idea how to even approximate that with user-managed PKI

reverse colexicographic Nora

@delta_vee True! I actually think Bluesky is doing super interesting stuff in that vein, really similar to some early Fedi moderation proposals that never went anywhere because people are irrationally scared of blocklist sharing

I think opt-in, transparent blocklist sharing is the only way to go.

Raymond Neilson

@noracodes The blocklist stuff is definitely interesting, modulo the normal maintenance/reputation/collateral-damage problems

I'm actually thinking more along the lines of e.g. CSAM reporting (well, really anything traditionally requiring some level of content removal), esp as that interacts with what you mentioned WRT paid IPFS hosting (and, as a corollary, the kind of people willing to risk hosting CSAM for a fee)

reverse colexicographic Nora

@delta_vee I mean, this is just the same argument as govts asking for encryption backdoors, right?

If we can never risk hosting even part of even an encrypted illegal file, we can't do IPFS at all. If we are only interested in complete, unencrypted files, it's just the same as any other hosting provider; if something is detected to be illegal in your jurisdiction, you unpin and delete it and report the client, whose credit card number you have

reverse colexicographic Nora

@delta_vee It's certainly possible that the US government decides that hosting providers are culpable for unknowingly hosting encrypted parts of illegal content. It would have huge consequences across the entire Internet economy, and would absolutely sink this idea too. I don't think that would be a good policy decision, but nobody cares what I think.

reverse colexicographic Nora

@roguelazer I have spent exactly zero time around Nostr, so you may be right about that community. I do think that, as of the current state of the art, the options we have for identity are "trusted central party" (which may or may not delegate power, like DNS) or "user controlled keys", and that's it.

James Brown

@noracodes oh, I emphatically agree — I signed up for nostr because it seems like a super-technically cool idea, but I think there's 0% chance anyone ever uses it

I do think a potential in-between model is something like a "jurisdictionally federated" model where your local government issues you a smart card (see Belgium's eID), but especially in the current US political climate that seems terrifying

reverse colexicographic Nora

@roguelazer yeah I would absolutely not use that lol

and anyway that's "trusted central party"

Raymond Neilson

@noracodes I'm actually halfway expecting one of the govs trying to subvert encryption to try exactly that - threaten liability for unknowingly hosting

reverse colexicographic Nora

@delta_vee horrifying, but it's definitely a possibility