Playing devils advocate here, but I also kind of believe this... There is no such thing as privacy in the social network. It is foolhardy to assume it is even possible. Even a real life social network relies on trust, trust that can be broken very easily and totally outside of your control. Maybe the answer is to accept that privacy isn't a real thing and stop sharing things, even in what you assume is a protected environment, that you don't wish to be public. I don't think there is a technical solution to "people can't keep secrets"

Technical solutions can't stop people you intended to share your secrets with from breaking your trust, but they can help prevent uninvolved third parties from getting direct access that no one intended to give them.

Not really. I've been using Mastodon for the last four months and I feel pretty safe. My instance doesn't know much more than I already told it. And I don't get reminders, emails telling me to check in, or ads following me. I could also run my own instance, and still be connected to the people I know.

Mastodon is pretty cool.

Sure but the real-life equivalent of that would be God telling Nike what kind of shoes you and your friend were talking about in secret.

No; the real life equivalent would be the the kid in class sitting between you and your friend opening the note and telling class what you said.

You asked the kid in class to pass the note. He did so freely. You assumed he wouldn't open the note, but guess what... he totally opened that note. And now he wants to profit off the information.

That’s an interesting point and I’m stealing it for in real life conversations, to point out the human element of secrets - but we should understand people are bad at keeping them while also not allowing Facebook to monitor messages to find a better way / leverage to sell us things.

I fully agree. The problem is that it's even harder to design something that is fully p2p than something federated. (One thing that tries to be exactly what you want would be https://secushare.org/ But its in a very very early stage, right now. There exist others, though.) And you have to agree that (even if most people choose the biggest provider) simply having the choice of different providers or even being your own provider is a huge improvement.

Its not really about the design. At some point you have to recognize the physical impossibilities of p2p models - primarily availability. The reason why Matrix is more popular than Tox or why we haven't seen any remotely successful p2p social network while projects like Mastodon took off is because there is simply no way to make the UX of the scenario where you want to send a message to X, who is offline, and before they come online you go offline and the message is never sent.

The way Tox does it (and any network trying to work around this problem) is to locally cache messages en masse as close to the destitination as you can get. But as you can imagine that makes the bandwidth and power requirements of maintaining the network too streinuous to be competitive with a federated option that simply works when the always-on server is available or doesn't when its offline.

"Physical impossibilities of p2p models" - Although there might be structural limitations, I think they're not too strong. Just because we currently do not have a major p2p network doesn't mean that it's not possible. I think it's very possible to have something like this (even for availability). You just need to have a good design/mechanism.

But there's the problem (why we didn't see something like this yet): No one puts many resources into the design of p2p-stuff. The competing, central solutions get tons of resources from big companies that try to make money with it. There is no company that tries to build something p2p because with giving away the control, they give away the possibility to make money out of it.

A working example of offline storage would be bitmessage (although I think It won't scale). A much more interesting development would be lake: https://media.ccc.de/v/34c3-8974-practical_mix_network_desig...

When I see projects like https://webtorrent.io/ https://openpgpjs.org/ or things like https://github.com/cjb/serverless-webrtc I sometimes wonder if just a 2018 web browser is enough.

It's not, but for dumb reasons.

Peer to peer connections on web browsers are pretty good (assuming you have relays to get around router issues with shared IP addresses). And Javascript is generally fast enough for encryption (although I'm not sure what the random number generator situation is).

But we lack the ability to easily guarantee file contents, which makes delivering encryption software more suspect. Additionally, data storage is still very unreliable. It is difficult to share information seamlessly between multiple browsers without a server, storage limits vary between browsers, data can get deleted for weird reasons. I've advocated for a while that users probably should be able to grant pages separate read/write access to specific files and folders on disk, but that's obviously a tricky decision to make and implement.

The Same Origin Policy obviously comes with security benefits. But it also means that if you share a 3rd party link, there's no way to look up metadata about the link without a proxy server to bypass the policy. Building something like an RSS reader in purely clientside Javascript is impossible because you literally won't be able to request many of the RSS feeds.

It can be a little bit surprising when you dig into all of the theoretical stuff that's possible with clientside Javascript to discover exactly what the areas are where the web is behind native. They're usually not the parts that get the most attention.

Maybe. But then there's a question of where does the content live? Most people don't have a desktop they leave connected all the time, and don't want to be hosting videos and photos off their mobile device.

So you're stuck with replicating that data out to all the peers, which means you've just lost control of "your" data again.

The content could live at peers that are online all the time. This could be either your own node or not. If it's not your own node the network has to be designed in a way that the online node does not learn a bit about what it is storing. An example of this would be lake: https://media.ccc.de/v/34c3-8974-practical_mix_network_desig... It's also mentioned on those slides: https://grothoff.org/christian/snt2017.pdf

Sure but hosting content isn't free, so then you have the problem of paying for it. I could imagine a crypto-currency based solution but that is just sooo complicated.

Most of the reason for centralisation is simplification. Have you tried running your own email server lately?

I think people wouldn't object to minimal costs of hosting their friends' stuff on the scale of a few hundred friends.

Shoehorning in cryptocurrency just seems absurd.

Yes, cryptocurrencies was one way. (I don't think that it's really complicated.)

But on the other hand I don't think that it's really expensive. As in have a RasPi lying around at home that's keeping track of everything when you're not online. That should totally suffice for your own needs. If you have bigger needs or want to support the network (maybe even for a small compensation in whatever form) that's easily scaleable. Or think of bittorrent: It's incentivised that you run contribute back what you received. That works totally without compensation in cryptocurrencies.

About the simplification I'm not sure either. Have you tried running Gmail lately? (Not as client but as service ^^ I think that it's not quite straight-forward.) Once you have a proper working p2p network/algorithm/protocol I can imagine that it's easier to run for all parties.

Asking the average person to install a device in their home to properly utilize a social network might be a non-starter

Let it run on the router or NAS...

> But then there's a question of where does the content live? Most people don't have a desktop they leave connected all the time

I think most people know someone who does and we can start there. The first step is to make it really easy to host on a desktop (including addressing and NAT busting, both of which Tor provide).

Have you had a look at https://github.com/ssbc/patchwork ? I think it ticks all of the boxes you mentioned!

Another example - Git. It's decentralized in principle, but in reality, people either centralize around GitHub and alternatives, and even when self-hosted, there is usually a notion of master repo.

That's partly a tooling issue, though. If git had native requests and a decent UI around them baked in, and the UI client also had some way of discovering your peers across networks, then the need for gitlab/github would be diminished.

Yeah no, unless you work on a project with 100 other people. Even if peer discovery, nat traversal and whatnot would be solved, what am I supposed to do if both my project members are currently offline? Synchronizing progress would be a nightmare in a three people project where everybody is located somewhere else. You could pretty much consider git peer to peer already, but everybody is too lazy to open their firewall and instead talks to the always-on supernode that is github.

Diminished. It's extremely common for teams to be online throughout the same business day. If you have an entirely async team where you can't coordinate time to exchange work product, then sure, you need an async third party location. That's by far the exception rather than the rule though.

You might want to check out https://snake.li - It's a cryptography-based "social network" born out of a masters' degree thesis. AFAIR most of it works in the browser, while the server doesn't really know much about the data.

A nice idea that sadly didn't get enough funding, and their creators eventually moved on.

It's AGPL though.

Bittorrent is decentralized in theory, but I think nowadays it's not worth much without trackers. Trackers again enable centralized groups with self-serving interests to centralize the activities and track user activity.

Check out what gnutella or the dat-protocol have to offer for reasonable alternatives.