[mrep]

> The big open question is: can we create an experience as compelling as Instagram or Twitter over the P2P web?

> It's a hard technical challenge, and today the answer is no.

This is why I completely dismiss almost every "distributed" solution. If you can show me a business model/design document for a distributed service that can scale to big tech levels, deliver a user experience that matches current solutions, while also incentivizing developers enough with money to get them to build it, I will be swayed. However, every solution I have seen makes massive tradeoffs that negatively affect all 3 criterias compared to current centralized solutions.

[erikb]

Huh? Email >>>>> Twitter over like 40 years or more? You don't work as an engineer, right? If you would, you would know how low the quality of most centralized technology is that is created by big corps. Most of the good stuff is decentralized. But the problem is that decentralization also means that the edge has more responsibility. And that responsibility is what people don't want to have. So they rather use a centralized bad system, because it's "easier" and then every few years they can blame all their own laziness on the centralized service provider and even read about it in the news.

If you need another example google a tool called "git". It is used by almost all software developers nowadays and even by quite a few authors. You don't need to setup anything to use it. If you have ssh you can just share your text based data with others by giving them access to your repository's directory. I bet it transfers more MB/day than Twitter. But nobody counts it because it's so distributed that it's hard to put an owner label on it. (Although the originators can be named quite clearly.)

[mrep]

Running your own email server is definitely not "easier" if you are actually trying to maintain any durability and availability SLA's with your average homeowners computer/storage/network.

And sure, you can use git by itself and send the diffs to each other over email. However, then you have to deal with coordinating where the head is which is a pain across every node since it is constantly changing. Thus, most people don't do it that way and instead use a centralized service like github.

[erikb]

> you can use git by itself and send the diffs to each other over email

Why not send it via ssh? It's much easier. And if the data is not too big you don't send diffs but complete file states. Git usually calculates the diffs on the fly by comparing two file states.

[mrep]

I was just giving an example because I think I remember hearing that linux exchanged a lot of their patches over email which is what partly inspired linus to make git the way it is. I'm not really sure of all the different ways you can use it because my teams have always used central repositories.