All true, except you're really just hiding the problem behind an abstraction. If you want to have a reliable server instead of just a server, then you want more than one server. And now you're back to your massively complicated problem, if you insist that all servers are equal.
Of course, you don't have to make that assumption, neither on the server side nor in the peer model. Just say that the peer who created the document is the "server" (or use any other reasonable way to determine this), and when other peers have a copy that disagrees, then they update their copy. Now it's just like talking to a real server, except it happens to be another peer. Go ahead and use If-Match, 412, etc. (...or the equivalents in whatever protocol makes sense, of course)
Such an immediate jump to a massive-scale solution for a few to at most a dozen hosts talking amongst themselves is a classic YAGNI.
You are equating the reliability of a server machine with the reliability of a user's client machine, when in reality these are not remotely similar. Laptops are regularly suspended and move between networks, losing connectivity. Phones even more so. Consumer internet is unreliable, usually with poor outgoing bandwidth. Mobile networks even more so. Etc.
When I share a document with five coworkers then close my laptop, the others need to be able to keep working. Under your model, that means they'd need to choose a new server. Guess what? This means you now need a consensus protocol. One where partitions happen 1000x more often, it is regularly necessary to operate without a quorum, latency is high and totally unpredictable, and all kinds of other properties that make the problem exponentially harder.
-Nowhere was it insisted that all servers are equal.
-Most people would prefer a hosted solution to hosting one locally(not constantly using their local machines resources)
-For many apps the performance and uptime of a server is of enough importance that this simply wouldn't work.
-A hosted solution provides a stable controlled and relatively unchanging environment, depending on what else you use that box for.
-Unless there's guaranteed uptime(which there isn't in this case) you have even more merging headaches. (read 4 slave-peers(not really even 'peers' in this context) all have different diffs after a week of the master being offline)
-Putting an app on a box somewhere isn't a 'massive scale solution'.
>If you want to have a reliable server instead of just a server, then you want more than one server.
No. Not for a personal or small app you don't. You can have 'reliable hosting' (say one of the many VM providers backed by solid hardware and a RAID tolerant to multiple drive failures). Reliable doesn't mean completely immune to failure, and you're underestimating the reliability if you think this is a regular occurrence. Your average hosting provider offers orders of magnitude more reliability than any users local PC or mobile(even if we're talking a constantly online desktop with wired ethernet).
It's just a ridiculously complicated thing your asking for here while simultaneously dismissing the parent comment as 'hiding the problem behind an abstraction'.
Hahaha thanks everyone there's lots here for me to consider. The peer model is probably better suited to ephemeral stuff like gaming than to document collaboration.
What I'm wondering now is, where is sandstorm going to run? If it's on AWS like everything else, I guess I misunderstood the point...
Sandstorm runs wherever you want it to. You can run it on your own physical machine -- even your desktop, if it's always-on. A lot of people run Sandstorm on Digital Ocean. The company also provides Sandstorm Oasis (oasis.sandstorm.io) which is provided as a service.
Wherever you run Sandstorm (including Oasis), you as a user can upload and install any package, including ones you built yourself. Thus it accomplishes the goals in the blog post, even if physically the servers are "centralized".
Of course, you don't have to make that assumption, neither on the server side nor in the peer model. Just say that the peer who created the document is the "server" (or use any other reasonable way to determine this), and when other peers have a copy that disagrees, then they update their copy. Now it's just like talking to a real server, except it happens to be another peer. Go ahead and use If-Match, 412, etc. (...or the equivalents in whatever protocol makes sense, of course)
Such an immediate jump to a massive-scale solution for a few to at most a dozen hosts talking amongst themselves is a classic YAGNI.