This suffers from the same problem that so so so many alternative social, federated, self-hosted ideas suffer from. Matrix, keybase, pgp, etc.
It’s too dependant on encryption. Yes, it’s a cool technical feat that stuff can be in the open but also private - but:
1. I want to be able to follow my freinds if my phone dies and i have to get a new one.
2. I am very technical, and idk exactly what a X25519 keypair is.
I would like for people to come up with more stuff like this that is designed for small communities but not for very secure communication. Like I want something where it’s secured by a username and password, that i give to a server i am registered with - and that server handles the encryption business. If the server rotates keys, that’s for the admin to figure out and exchange keys with sibling servers.
Idk I’m just making up specifics but this is the kind of ethos i think is needed to make things that can be successful with non-technical people in a way that can unseat big tech.
In case i sound too critical - this is cool. It just isn’t something i can use with family and friends to replace facebook or even email.
1. Right after initialization you'll be prompted to export the private key and store it somewhere safe, e.g. your password manager
2. You don't need to know unless you want to implement the protocol! To use (the very barebones) implementation all you need to do is fork the repo & give access, which I admit can be too much for family/friends so you might have to set it up for them (and I bet they'd be stoked to have a website of their own!)
Glad to see more of these efforts. But here's what it will really take to decentralize social media and E2EE messengers:
We need something like Discord, except each server is an actual self-hosted server like a Minecraft server. DMs between two users should be handled by a mutual server. Account credentials should be handled by a Nostr-like protocol, which also gives you global tweeting capabilities as a bonus.
Run the whole thing on Yggdrasil Network or something similar so that it's not tied down to IPv4v6 and DNS and all existing hardware infra, but can still take advantage of them. And add reciprocal inter-server onion routing to make it difficult to geolocate servers. Also take a page from SoftEther VPN's book and wrap all traffic in HTTPS and perform automatic NAT traversal, so that people can host servers from behind ISP firewalls.
Anything short of that and we lose to big tech and govs in the long run. But once we've achieved the above, the decentralized web can truly take off: we will get WiFi routers running open-source firmware to make a mesh network to act as alternative physical layer infra for the new web. We can still take advantage of the existing Internet's bandwidth as long as there's an unblockable path to send a little bit of data to discover and coordinate nodes.
I guess I’d rather have something approaching bittorrent, edonkey/kad, ipfs, blockchain, webarchives.
You have named networks that are federated together, and people can publish to the networks they are invited to or sign up for. The networks survive even with individual servers go down. Data is cached all over at the edges.
Your version is just way too susceptible to rot, unless you see that as a feature. I see it as most of the good content falling into the ether sooner rather than later.
> The private key is stored in the browser’s localStorage.
Woah.. when will those people learn? _Any_ browser storage is unreliable. Anything goes wrong with your web experience? Clear browser settings. Make new profile. Re-install browser. The browser's localStorage is not a replacement for filesystem. It cannot be backed up, it is super volatile, and it should _never_ be used for anything important. It's one of those "worst of both world" cases, where malware can access it with no problem, while legitimate backup programs are locked out.
(And yes, the post mentions "new device" flow, but how many people would (1) remember to export their private key and (2) won't lose it with their device? I bet in practice people will use the network until the first time localStorage is lost, and then they will get annoyed that their feeds are lost forever, and will likely leave the network for good)
> By convention, the client looks under /satellite/ by default. If that path is already taken, place a satproto_root.json file at the domain root containing { "sat_root": "my-custom-repo" } — the client checks this first.
(The IndieWeb wiki is probably the best resource for exploring the personal website-based social networking tech nowadays. I recommend the author check it out and maybe iterate on that instead :)
I wish I could share a graph of my eyebrow height over time as I read through this part:
> sAT Protocol (s@) is a decentralized social networking protocol based on static sites. Each user owns a static website storing all their data in encrypted JSON stores.
But in all fairness it seems like a reasonable system, given the narrow scope of its goals. It does not scale, but that's on purpose. Although I could still see "Feed Aggregation" becoming impractical even with a small number of friends with a modest number of posts.
Cryptographically, a problem is that it makes ciphertexts publicly enumerable, protected by a X25519-derived key. This makes it very vulnerable to harvest-now-decrypt-later attacks, if you believe quantum computing will ever happen.
Your app picks up a bunch of feeds and composes them into a nice page for you, much like an RSS feed reader. The twist is that each feed is encrypted in a way that only you can decrypt, so the cryptography also gives strong identity guarantees, and allows for private messaging.
It's basically PGP + RSS, only mapped to a bunch of files of specific structure. Those could be RSS/ATOM feeds instead of JSON, to reuse an existing format. The reuse of the ideas is good, these ideas are time-proven.
As any PGP-lookalike, this thing has the key distribution problem, and won't scale to billions of users due to that. Key rotation and revocation is another problem. But for a small-scale network it should be fine, and can run on very tiny, very low-power devices, maybe even with intermittent connectivity.
> The twist is that each feed is encrypted in a way that only you can decrypt
Not true, the "content key" is common to all viewers of all posts, from a particular author. (hence the need to re-encrypt the world when you unfollow someone...)
The content key is common, like the PGP session key is common. But to obtain the content key, you need to first decrypt it by your private key. The content key is encrypted by the public keys of every intended reader, so each can have a secure copy of the content key. Again, exactly like PGP works.
Interesting approach. The static-site constraint is clever for self-sovereignty but I wonder how feed aggregation scales once you follow more than a handful of people - you're polling N sites with no push mechanism.
Nostr solved the discovery/aggregation problem with relays but introduced its own tradeoffs (relay trust, spam). This sits at the opposite end - zero infrastructure dependencies but O(N) polling. Feels like there's a middle ground waiting to be found.
That should scale pretty well. The HTTP fetch of posts/index.json could use conditional get requests to avoid downloading the body when there are no changes. Static files are dirt cheap to serve.
Does the polling need to be fast? I think back to mailing lists and the huge delays involved in those conversations. Yet they were/are often very productive. Somewhere between Twitter/X speed and mailing list speed might be acceptable.
Maybe this would be better with a LiveJournal style interface. Medium length posts with threaded comments/replies are an underrated format.
This obviously needs some iteration on the protocol design as other commenters have mentioned, but I'd still be up for partnering up over here at https://anproto.com/
This seems like a thin wrapper around libsodium, maybe I lack imagination but it's hard to see it as a protocol. On wiredove I see people posting with handles and profile pictures, where is that defined?
The client fetches the pub key off the server which is decentralized? There's no part in the protocol that authenticates whether or not a pub key is legit. If its replaced by an attacker and someone subsequently goes to fetch a key they can read those messages. I mean, pub key infrastructure is meant to solve that. With SSL and such... that's why you its a federated chain of certificates with providers vouching that names = pub keys.
This is a very common problem. There is potential to possibly make this more decentralized with smart card technology. Like imagine a smart phone with access to pub keys in the hardware tied to an account cryptographically. Then you can say something like phone number = subscriber = pub key. Encrypted messaging apps seem to bootstrap off of ownership for numbers in the mobile system (mobile system security is very bad so there are dragons here.) The other apps like pidgin with OTR plugins they have unique phrases that help with the issue.
When you start looking at decentralized pub key infrastructure tied to human-meaningful names you start to run into zookos triangle:
PFS is valuable largely in stable, small groups that rarely change shape or association.
PFS in an open, freely-associable environment is far more complicated when you move beyond even the smallest of group sizes. Realistically, once the group size is beyond Dunbar's number you can reasonably assume that PFS is moot, because you no longer can depend on maybe four or five people's personal security, but 150+. Statistically, someone's opsec failure will be guaranteed.
satproto's implementation involves complex cryptographic signing and that makes it very not static. One needs to run a program of some sort to use satproto. The only static part is that the json that's operated upon.
It just uses HTTP POST (like pingback/trackback/etc, except it has a second step verifying the page sending the webmention actually has a link to a URL on the website). You can them them with a browser or cURL or some complex backend script. Receiving them is as easy as logging POSTs to a specific URL endpoint or even using someone else's community backend your site interfaces with via javascript (ie, https://webmention.io/ - not static since it uses JS). Or anything in between.
Totally decentralized and very simple. I implemented a simple nginx POST logging format in the config to receive on my static site. And HTML forms on my static site can send. http://superkuh.com/blog/2019-12-11-3.html
This suffers from the same problem that so so so many alternative social, federated, self-hosted ideas suffer from. Matrix, keybase, pgp, etc.
It’s too dependant on encryption. Yes, it’s a cool technical feat that stuff can be in the open but also private - but:
1. I want to be able to follow my freinds if my phone dies and i have to get a new one.
2. I am very technical, and idk exactly what a X25519 keypair is.
I would like for people to come up with more stuff like this that is designed for small communities but not for very secure communication. Like I want something where it’s secured by a username and password, that i give to a server i am registered with - and that server handles the encryption business. If the server rotates keys, that’s for the admin to figure out and exchange keys with sibling servers.
Idk I’m just making up specifics but this is the kind of ethos i think is needed to make things that can be successful with non-technical people in a way that can unseat big tech.
In case i sound too critical - this is cool. It just isn’t something i can use with family and friends to replace facebook or even email.
1. Right after initialization you'll be prompted to export the private key and store it somewhere safe, e.g. your password manager
2. You don't need to know unless you want to implement the protocol! To use (the very barebones) implementation all you need to do is fork the repo & give access, which I admit can be too much for family/friends so you might have to set it up for them (and I bet they'd be stoked to have a website of their own!)
Glad to see more of these efforts. But here's what it will really take to decentralize social media and E2EE messengers:
We need something like Discord, except each server is an actual self-hosted server like a Minecraft server. DMs between two users should be handled by a mutual server. Account credentials should be handled by a Nostr-like protocol, which also gives you global tweeting capabilities as a bonus.
Run the whole thing on Yggdrasil Network or something similar so that it's not tied down to IPv4v6 and DNS and all existing hardware infra, but can still take advantage of them. And add reciprocal inter-server onion routing to make it difficult to geolocate servers. Also take a page from SoftEther VPN's book and wrap all traffic in HTTPS and perform automatic NAT traversal, so that people can host servers from behind ISP firewalls.
Anything short of that and we lose to big tech and govs in the long run. But once we've achieved the above, the decentralized web can truly take off: we will get WiFi routers running open-source firmware to make a mesh network to act as alternative physical layer infra for the new web. We can still take advantage of the existing Internet's bandwidth as long as there's an unblockable path to send a little bit of data to discover and coordinate nodes.
I guess I’d rather have something approaching bittorrent, edonkey/kad, ipfs, blockchain, webarchives.
You have named networks that are federated together, and people can publish to the networks they are invited to or sign up for. The networks survive even with individual servers go down. Data is cached all over at the edges.
Your version is just way too susceptible to rot, unless you see that as a feature. I see it as most of the good content falling into the ether sooner rather than later.
> The private key is stored in the browser’s localStorage.
Woah.. when will those people learn? _Any_ browser storage is unreliable. Anything goes wrong with your web experience? Clear browser settings. Make new profile. Re-install browser. The browser's localStorage is not a replacement for filesystem. It cannot be backed up, it is super volatile, and it should _never_ be used for anything important. It's one of those "worst of both world" cases, where malware can access it with no problem, while legitimate backup programs are locked out.
(And yes, the post mentions "new device" flow, but how many people would (1) remember to export their private key and (2) won't lose it with their device? I bet in practice people will use the network until the first time localStorage is lost, and then they will get annoyed that their feeds are lost forever, and will likely leave the network for good)
> By convention, the client looks under /satellite/ by default. If that path is already taken, place a satproto_root.json file at the domain root containing { "sat_root": "my-custom-repo" } — the client checks this first.
Would a `/.well-known/` be helpful here?
https://en.wikipedia.org/wiki/Well-known_URI
.poorly-known
Long ago there was this thing called foaf https://en.wikipedia.org/wiki/FOAF and also https://en.wikipedia.org/wiki/Pingback ... it was the closest I've seen to completely decentralised social media.
Webmention is the modern counterpart: https://indieweb.org/Webmention
(The IndieWeb wiki is probably the best resource for exploring the personal website-based social networking tech nowadays. I recommend the author check it out and maybe iterate on that instead :)
I wish I could share a graph of my eyebrow height over time as I read through this part:
> sAT Protocol (s@) is a decentralized social networking protocol based on static sites. Each user owns a static website storing all their data in encrypted JSON stores.
But in all fairness it seems like a reasonable system, given the narrow scope of its goals. It does not scale, but that's on purpose. Although I could still see "Feed Aggregation" becoming impractical even with a small number of friends with a modest number of posts.
Cryptographically, a problem is that it makes ciphertexts publicly enumerable, protected by a X25519-derived key. This makes it very vulnerable to harvest-now-decrypt-later attacks, if you believe quantum computing will ever happen.
Your app picks up a bunch of feeds and composes them into a nice page for you, much like an RSS feed reader. The twist is that each feed is encrypted in a way that only you can decrypt, so the cryptography also gives strong identity guarantees, and allows for private messaging.
It's basically PGP + RSS, only mapped to a bunch of files of specific structure. Those could be RSS/ATOM feeds instead of JSON, to reuse an existing format. The reuse of the ideas is good, these ideas are time-proven.
As any PGP-lookalike, this thing has the key distribution problem, and won't scale to billions of users due to that. Key rotation and revocation is another problem. But for a small-scale network it should be fine, and can run on very tiny, very low-power devices, maybe even with intermittent connectivity.
> The twist is that each feed is encrypted in a way that only you can decrypt
Not true, the "content key" is common to all viewers of all posts, from a particular author. (hence the need to re-encrypt the world when you unfollow someone...)
The content key is common, like the PGP session key is common. But to obtain the content key, you need to first decrypt it by your private key. The content key is encrypted by the public keys of every intended reader, so each can have a secure copy of the content key. Again, exactly like PGP works.
A PGP session key does not span multiple messages, however
So a database, that you can send a network response or request with that data, that when received by a client, builds a static website.
I see.
I see...
> Key Rotation (Unfollow)
Very interesting idea, love the simplicity.
Question about this:
“Threads are positioned in the timeline by the original post’s created_at; replies within a thread are sorted by their own created_at ascending.”
Does this mean, I, as the person replying to the post can manipulate my reply time to say, 3 minutes before person X’s reply?
If so, I can imagine a few adversarial ways of (ab)using this.
I understand this is more for friend groups, just curious if my understanding is correct.
Funny to see people mention nostr
https://satellite.earth/ (Satellite nostr client)
https://nsite.run/ (literally static sites on nostr)
OctoTown: https://octotown.github.io/
Interesting approach. The static-site constraint is clever for self-sovereignty but I wonder how feed aggregation scales once you follow more than a handful of people - you're polling N sites with no push mechanism.
Nostr solved the discovery/aggregation problem with relays but introduced its own tradeoffs (relay trust, spam). This sits at the opposite end - zero infrastructure dependencies but O(N) polling. Feels like there's a middle ground waiting to be found.
That should scale pretty well. The HTTP fetch of posts/index.json could use conditional get requests to avoid downloading the body when there are no changes. Static files are dirt cheap to serve.
Does the polling need to be fast? I think back to mailing lists and the huge delays involved in those conversations. Yet they were/are often very productive. Somewhere between Twitter/X speed and mailing list speed might be acceptable.
Maybe this would be better with a LiveJournal style interface. Medium length posts with threaded comments/replies are an underrated format.
Maybe that's a feature rather than a bug
This obviously needs some iteration on the protocol design as other commenters have mentioned, but I'd still be up for partnering up over here at https://anproto.com/
This seems like a thin wrapper around libsodium, maybe I lack imagination but it's hard to see it as a protocol. On wiredove I see people posting with handles and profile pictures, where is that defined?
and thx for being the first person to notice the thin wrapper
userspace
Seems a bit complicated.
Why not use git for social networking ;)
https://github.com/est/gitweets
Amazing. I'm building almost the exact same thing. I'll share mine when it's mature enough. :D
have you considered Replace X25519 with a post quantum cryptography key encapsulation mechanism like kyber or saber?
Signed JSON reminds me of Nostr. I wish Nostr was somehow more mainstream.
I laughed when I saw this because two years ago I built a nostr client called Satellite! https://satellite.earth/
Just use RSS at that point. I don't see the value of encrypting everything, like people are gonna be spying on your random static blog entries.
Seems like a missed opportunity to not put a /satellite/satproto.json file on that site.
The client fetches the pub key off the server which is decentralized? There's no part in the protocol that authenticates whether or not a pub key is legit. If its replaced by an attacker and someone subsequently goes to fetch a key they can read those messages. I mean, pub key infrastructure is meant to solve that. With SSL and such... that's why you its a federated chain of certificates with providers vouching that names = pub keys.
This is a very common problem. There is potential to possibly make this more decentralized with smart card technology. Like imagine a smart phone with access to pub keys in the hardware tied to an account cryptographically. Then you can say something like phone number = subscriber = pub key. Encrypted messaging apps seem to bootstrap off of ownership for numbers in the mobile system (mobile system security is very bad so there are dragons here.) The other apps like pidgin with OTR plugins they have unique phrases that help with the issue.
When you start looking at decentralized pub key infrastructure tied to human-meaningful names you start to run into zookos triangle:
https://en.wikipedia.org/wiki/Zooko%27s_triangle
human-meaningful, decentralized, secure -- pick two
This needs a YouTube demo video.
See also org social:
https://github.com/tanrax/org-social
Thanks for this, nice concept. This would be good on a Tor onion service.
Nostr https://nostr.com/
Real question for people who know what they’re talking about:
is perfect forward secrecy no longer considered valuable?
PFS is valuable largely in stable, small groups that rarely change shape or association.
PFS in an open, freely-associable environment is far more complicated when you move beyond even the smallest of group sizes. Realistically, once the group size is beyond Dunbar's number you can reasonably assume that PFS is moot, because you no longer can depend on maybe four or five people's personal security, but 150+. Statistically, someone's opsec failure will be guaranteed.
satproto's implementation involves complex cryptographic signing and that makes it very not static. One needs to run a program of some sort to use satproto. The only static part is that the json that's operated upon.
This is not true of indieweb's web mention: https://indieweb.org/Webmention
It just uses HTTP POST (like pingback/trackback/etc, except it has a second step verifying the page sending the webmention actually has a link to a URL on the website). You can them them with a browser or cURL or some complex backend script. Receiving them is as easy as logging POSTs to a specific URL endpoint or even using someone else's community backend your site interfaces with via javascript (ie, https://webmention.io/ - not static since it uses JS). Or anything in between.
Totally decentralized and very simple. I implemented a simple nginx POST logging format in the config to receive on my static site. And HTML forms on my static site can send. http://superkuh.com/blog/2019-12-11-3.html
I wonder what the signing is for if you already have a domain name to verify your authorship.
It doesn't use signing, aside from the signing that exists within TLS
I think they mean in s@.
...which doesn’t do signing, but does do E2E encryption? So it’s more like DMs-over-HTTPS.
Webmention is cool indeed. Also one of few techniques that’s currently free of some corp’s greedy roadmap