nbAfter extensive research into decentralized social networks, it is now time for a state of the art 🧵 thread on the subject of #DataSovereignty and its relation to end-to-end encryption and decentralized identity management. For this, I will contrast the two currently most used decentralized social networks protocols: #ActivityPub and #Nostr. #Fediverse #Nomad #Identity #Privacy #E2EE #DPKI #DIDs #SSI 1/11
In terms of individual data sovereignty, the problem I currently see in the Fediverse is that the vast majority of users here only have limited access to their data. On the one hand, this is about the trivial need that I, as an average user, should be able to migrate to another instance entirely (in the sense of the entire content of my social graph, including the posts). On the other hand, it is about a way out of worst-case scenarios, e.g. the instance suddenly goes offline, the instance closes the migration option or defederates from the rest of the Fediverse. How can users migrate in such a case and in such a way that they take all their data with them and at the same time have the authenticity of their identity ensured? 2/11
Here in the Fediverse, a solution is being discussed called "Nomadic Identity", which Hubzilla has already implemented in its own Zot/Nomad protocol, and to what extent this can also be adopted in the ActivityPub protocol (i.e. for all ActivityPub applications). At the same time people work on the Nomad protocol under the name "Streams" as an independent ActivityPub based server application. Currently, however, the vast majority of people are on Mastodon instances, and neither offline migration nor full content migration is possible there (see open Mastodon issues on "Multihoming" 19924, "Support Post Migration" 12423, "Integrate Zot Protocol" 9666). So in fact, the instance administrators are currently the only ones in the Fediverse who can maintain a certain degree of sovereignty over their data (apart from a minimal percentage of Hubzilla/Zap users). 3/11
Nostr, on the other hand, encrypts all content with a public-private key scheme (unlike ActivityPub), shifts data sovereignty to the operators of relays, and gives the keys for decrypting the content into the hands of the users who communicate over those relays. Unfortunately, the lack of adoption of e-mail encryption among the general population shows how difficult it is to make people understand the public-private key paradigm. However, I do also think we should stick to the education efforts on it because decentralized public key infrastructures (DPKI) are still one of the most solid solutions for secure communications that we have right now. And I think Nostr as one of many examples shows quite well how intuitive DPKI interfaces can look like. 4/11
However, on Nostr, just like in the Fediverse, server administrators (relay operators) are de facto in a superior position because they are in possession of the relayed data and have a kind of gatekeeper function. Users who are not able to set up their own relay are ideally connected to several relays at the same time, but they hand over sovereignty over their data to the operators of the relays and have to trust them. This means that users face the same trust problem as with choosing an instance on the Fediverse, and speaking of Nostr the option for offline data export or local storage of data in the event of a relay shutdown is even less advanced than in the Fediverse. When it comes to gatekeeping, Nostr relay operators are currently facing the same challenge that we face in the Fediverse when it comes to moderating instances: useful mechanisms must be built to keep out spam, illegal content, and malicious actors (however these terms are defined). 5/11
steffenr42@nb thanks for the interesting comparison!
I think an interesting idea popular in the #nostr community is about micropayments. To prevent spam some relay operators require small amounts to use their relays. This might also incentivize people to run relays more professionally or add more costly functionality to them like file hosting as currently discussed in some nips.
Though I'm always a little unsure how inclusive/exclusive these payment based approaches are.
I think an interesting idea popular in the #nostr community is about micropayments. To prevent spam some relay operators require small amounts to use their relays. This might also incentivize people to run relays more professionally or add more costly functionality to them like file hosting as currently discussed in some nips.
Though I'm always a little unsure how inclusive/exclusive these payment based approaches are.
@steffenr42
I'm aware of that, thats why I stated in my thread that having no meta data E2EE for ordinary messages is bad for users privacy and to have that with payment data is even worse. So I'd rather prefer having a protocol that fully e2e encrypts all data, first. And there are protocols who have already managed to do this, see Secure Scuttlebutt (SSB). And no, neither hiding Zaps on the client side nor having a bunch of burner keys does help here.
And let's be precise here, the only thing what the Nostr community is interested in is Bitcoin as a form of micropayments, nothing more, nothing less. And apart from discussions on Bitcoin and how Bitcoiners prefer censorship-restistance over environmental impact, Dorsey and his followers, which is the most of the crowd over at Nostr, would also be perfectly fine with even having a "pay for each event" Nostr implementation.
I argued in my thread that there are parts of the world population who cant even afford a domain name. So now you can imagine how inclusive I think Nostr will be in the future if the Nostr community decides to head the way of more monetization/bitcoinization. And we know how such monetization schemes go if you take a look at the Birdsite right now.
I think the Fediverse with its mostly donation based and voluntarily run infrastructure has already debunked in real practise the notion that admins have to be "incentivized" by earning forced money (e.g. membership fees) on their users. SSB and Fediverse applications have also shown that you can combat spam without having to monetarize relays. But that's not part of my study here anyway, so I wont get into it any further.
I'm aware of that, thats why I stated in my thread that having no meta data E2EE for ordinary messages is bad for users privacy and to have that with payment data is even worse. So I'd rather prefer having a protocol that fully e2e encrypts all data, first. And there are protocols who have already managed to do this, see Secure Scuttlebutt (SSB). And no, neither hiding Zaps on the client side nor having a bunch of burner keys does help here.
And let's be precise here, the only thing what the Nostr community is interested in is Bitcoin as a form of micropayments, nothing more, nothing less. And apart from discussions on Bitcoin and how Bitcoiners prefer censorship-restistance over environmental impact, Dorsey and his followers, which is the most of the crowd over at Nostr, would also be perfectly fine with even having a "pay for each event" Nostr implementation.
I argued in my thread that there are parts of the world population who cant even afford a domain name. So now you can imagine how inclusive I think Nostr will be in the future if the Nostr community decides to head the way of more monetization/bitcoinization. And we know how such monetization schemes go if you take a look at the Birdsite right now.
I think the Fediverse with its mostly donation based and voluntarily run infrastructure has already debunked in real practise the notion that admins have to be "incentivized" by earning forced money (e.g. membership fees) on their users. SSB and Fediverse applications have also shown that you can combat spam without having to monetarize relays. But that's not part of my study here anyway, so I wont get into it any further.
The implementation of end-to-end encryption (E2EE) has been discussed in the Fediverse for a long time and there are several approaches, especially from the Mastodon community (see Mastodon E2EE proposal by soatok, Mastodon issues "Add end-to-end encryption API" 13820 and "support zero-knowledge encryption for toots/DMs" 19565), but none of them is production ready. Nostr has already made that step: In contrast to ActivityPub, the contents of DMs there are end-to-end encrypted. However, the problem with that is that the user's privacy is not protected. All user interactions (events) on Nostr, i.e. who communicates with whom and when (= the metadata), are publicly accessible, including DMs. In NIP-04, the Nostr developers themselves point out that the standard behind DMs "does not go anywhere near what is considered the state-of-the-art in encrypted communication between peers". 6/11
Anyone who has ever looked into the potency of metadata and data tracking knows how easy it is to extract people's behavior patterns and create intimate profiles of individuals from such data, and that without knowing the content. It even becomes more critical when payment transactions are added to the mix, which Nostr also has (Zaps aka Bitcoin Lightning payments). As every Nostr entity currently corresponds to one public key, all interactions can also be clearly assigned to an identity (= persons behind the PubKey). Accordingly, for a serious implementation of E2EE in a social network protocol, it is critically important to encrypt the metadata as well. 7/11
Furthermore, it is questionable whether it is a wise decision for a end-to-end encrypted social network to have the identity of each user attached to a public-private key pair alone, as it is the case with Nostr. Not only that your identity is gone when your key is lost or stolen, but this does not allow for any reasonable key management. By reasonable I mean the means to revoke and rotate keys, ideally also a included backup capability. Also, the cryptographic algorithm used should provide certain interoperability, performance and rehashing capabilities. Only with such given cryptographic portability and interoperability a DPKI system becomes integrable and scalable, and remains future-proof. 8/11
A common problem that both the Fediverse and Nostr currently have is that they rely on web/DNS based services to establish the authenticity of their users' identities. The entire Fediverse is based on instances that are exclusively accessible via DNS (web domain) and users often resort to linking their profile to their own DNS based TLD domain or centralised services such as GitHub, Twitter, Discord, etc. to establish authenticity of their identity. Nostr users also resort to either proof via DNS based web domain (NIP-05) or the same centralised identity providers to establish legitimacy of their identity. Web Key Directories (WKDs) are also operated for this purpose, where Nostr users can voluntarily deposit their identity links and proofs. 9/11
But for one thing, the starting assumption should be that not all of the 8 billion people in the world can afford their own web domain and are therefore dependent on a cheap method for their digital identity. Secondly, the past has shown us that web domains and WKDs can be compromised and also how vulnerable the centralized identity providers are to leaks, hacks, outages, and takeovers, precisely because they accumulate so much data. For this reason, people in the field of decentralized identity solutions have come together over the past years to think about a renewal of the Web of Trust (WoT), resulting in the emerge of Self-Souvereign Identity (SSI), Trust Over IP (ToIP) and the W3C standards Verifiable Credentials (VCs) and Decentralized Identifiers (DIDs), among others. 10/11
Therefore, I am confident that in the future with DIDs we will have a component for decentralized protocols that unites the various actors, e.g. with did:orb there is already a DID method that works with ActivityPub and with Chatter Net we have a ActivityPub application that works with an DID method (did:key). Currently, Bluesky with the AT protocol is the only network that uses DIDs in a way to solve the problems I described in this thread (see ATP Specs and did:plc). However, it doesn't have to stay that way. DID methods are already being discussed in the Nostr and ActivityPub community. Anyone who has read this far now has a few clues to further investigate that matter. 11/11
Adrian@nb This thread only works in my Mastodon clients but not in the browser when I go to https://social.biblioco.de/notice/AUoRRByEZrP9wZsw4W . Thus, I can not share it with anybody outside the Fediverse. Bug or feature?
BTW, thanks for the thread!
@acka47
Works as intended. So yeah, it's a feature 😁 I decided against having a centralized public profile were anybody can see my interactions and follows. This is an Fediverse exclusive article for now. If ppl want to read it, why not have them join the Fediverse? 😉
Works as intended. So yeah, it's a feature 😁 I decided against having a centralized public profile were anybody can see my interactions and follows. This is an Fediverse exclusive article for now. If ppl want to read it, why not have them join the Fediverse? 😉