Uber is mentioned here as an interesting case of treating the edge device as the source of truth, which was interesting to read about a little while ago. However, Uber has a certain amount of guaranteed control over driver phones, and even then I imagine that it represents a pretty promising attack vector into their systems.

How would this system work when treating untrusted clients executing arbitrary code as the definite source of truth for a fact? Further, it doesn't seem like this addresses (unless I'm missing something) the problem raised in the airline ticket example where split-brain systems may hand out resource reservations that they aren't actually allowed to give out. If both passengers' devices (or the plane? or some other edge device?) are sources of truth, I don't see any easier way to negotiate the resource contention than current distributed databases already have.

Split brain systems can easily deal with being disconnected: They don't give out new tickets, they don't modify system state, and they treat the data they do have as what it is: Out of date. An airline reservation system shouldn't be able to give out multiple conflicting tickets, because it doesn't have a lock on them; RAFT and PAXOS are designed to combat precisely this.

However, in the real world, waiting for consensus before making decisions is hard, so airline systems, designed in the era before realtime communication back to the mothership was possible, faked it. They made a reservation, issued a ticket, and then the airline developed protocols to deal with the resulting overbooking. In fact, since airlines already had incentive to overbook and deal with overbooking because of no-shows, they simply built the failures of their locking system into their cost-models.

There is a 'correct' solution to this: When you believe you're going to be split-brained some of the time, pre-allocate tickets to entities. Those entities can use their local tickets, but cannot make use of remote tickets without approving them with the systems that own them. Sharding the state of the plane down to individual seats has system complexity cost, but allows perfect booking.

In this model, the results of the executions of programs are also mergeable.

Not all updates are commutative.

The ordering of events in (add 1, add 2, add 3) does not affect the outcome.

The order of events in (add 1, multiply 2, divide 3) does matter.

The problem of linearity exists as soon as you have a commutative operation in a relativistic universe where information cannot be simultaneously updated in two coordinates simultaneously.

Until now there have been heroic engineering efforts to hide this from software developers. Hardware has conspired to conceal that even in a space a few centimetres wide, values can become inconsistent.

Once you have independent memory spaces, all bets are off and you are forced to pay a high price for losing the abstraction.

Not all updates are commutative, but there exists an entire class of algorithms that solve for each of these scenarios - see CRDTs, DAGs, even linked lists.

I'm skimming, so I am probably getting it wrong.

But on my reading, CRDTs just kick the can down the road to the implementer of the operation or merge function. The way they solve for commutativity is to ... require commutativity.

That's a win if your changes are commutative. Lots of things aren't.

From my research the only thing you truly can't handle is The Double Spending problem, blockchain ledgers help against this but are not immune to it.

Any and all arithmetic operations can be fully solved with CRDTs without further can kicking. The trivial solution is to give every number you are adding/subtracting a unique identifier, then as the values come in you do a sum across them, deduplicating in the process. This means you can resend the math operations as many times as you want and you still get an idempotent result.

This isn't theoretical, I've implemented this system already in code: https://github.com/amark/gun . Just spoke on it in London, Germany, and the USA.

I think people need to know that this discussion is no longer happening only in the hands of academics, this is now available to developers - with or without the academic side.

I've implemented this system already in code

It doesn't look like you have. I watched the demo video "GUN Survives a Primary Fault" and the conflicting updates were resolved with a LWW semantic, which is non-deterministic.

(EDIT: I read some docs, and it looks conflicts are resolved by choosing the highest lexical order of the value. So, apologies for the assumption. I assumed LWW because the BBBBBB update was seen last after the fault was resolved. Nonetheless, I think it is interesting you're treating the browser as a peer in the system, and not simply a client)

this is now available to developers - with or without the academic side.

I don't understand this attitude. Working closely with academics ought to be what industry strives for. They take the time to research, formalize theorems and write proofs to advance the current state of the art in Computer Science. This research helps move industry forward. A tight relationship between industry and academia is mutually beneficial, for what should be obvious reasons.