Local-first architectures typically try to handle syncing logic in the protocol layer.

This is required because the various peers don't trust the application logic to run faithfully in another location.

That means that the syncing and reconciliation has to happen in the protocol layer.

But syncing is a complex problem with fractally intricate nuanced details that differ in different contexts.

Any generalized sync components inevitably are too coarse to capture the precise semantics you're trying to model.

This difference between what you actually want the software to do and what you can easily make happen with the prebaked semantics on hand gets more pronounced the more fidelity in your product vision you try to create.

The application logic, if it could be hyper-situated to its context and freeform, would often be relatively straightforward (if a bit verbose).

If all of the peers agree to trust one host, then it's relatively easy to create this logic.

The problem is traditionally to cut that architectural gordian knot that also requires everyone to yield their data and control over it to another party: the one who operates the server, and could take the data hostage, charging you rent to access your captured data.

But what if you could allow this kind of canonical central server while also trusting that it couldn't execute code different from what you had intended, and that every peer could validate it had that property?

That's what Private Cloud Enclaves give you.