Even as a relatively young person that has grown up with the internet, I'm not a fan of how much thin clients have eclipsed thick clients. I long for the days where offline, local-first was the norm. I long even more for when this (hopefully) loops back around while also including the advantages of (currently) online-only applications.
I often fantasize about a set of standardized CRDTs using a relationship-based identity management system to connect people via a P2P mesh network, where applications are just "frontends" that simply organize and augment that underlying data. I dream of how the reliance on centralized servers can be reduced or even eliminated, depending on the circumstance.
Perhaps I'm naïve in this fantasy's feasibility in being implemented and/or in winning the uphill battle with the tech giant powers that be. A millennial can dream though.
I am also a fan of CRDTs. Couchbase uses them. Yjs and automerge exist. You need to build your data storage on top of them and build a pub sub or a relay similar to IRC or echoserver. Or websockets. Now you have two problems. That's why I don't think they have adoption.
Merkle trees as in IPFS are useful too.
Decentralised apps exist but they're different to mainstream architecture.
I think the solution is to distribute the data storage and the app can rely on standard SQL.
I wrote a merkle CRDT[1] and I point everyone to braid's shelf implementation[2] for a simple implementation of a CRDT. Hyperhyperspace[4] is an interesting project.
I also recommend taking a look at bloom Lang[3] and CALM/BOOM papers[5].
The problem with distributed technology is that it is more complicated than centralised technology. Until it can be abstracted out and exposed as a simple design, I think it shall remain a niche interest.
I'm torn on it, but I think I'm mostly in the thin-client camp. I don't have Slack or Zoom or just about anything other than my dev tools installed locally. I kind of view Zoom (and most opaque software blobs) as a bit sketchy / a virus waiting to happen if I install it. But I can use all of these just fine in my browser which has a much better (though not bulletproof) sandbox than my native apps get. Also, I can use them on Linux, which isn't always the case with native apps.
So. In all, SPAs and thin clients for the win, in my book.
They win, but they are so slow in comparison to the native apps, it is a pity. Android-like sandbox + native apps is the best approach. Too bad Windows store failed. Also, Linux packages (Ubuntu) or even Snaps did not work too well for me when I tried last time
What you seek certainly isn't impossible (it exists!), but given the ecosystem we find ourselves in it ramps up the challenge by orders of magnitude.
Where you see an architecture like the one you're describing is multiplayer videogames. Take Minecraft as example. Every client has a relatively full copy of the state of the universe, but they also synchronize that state against a server image. Problem is, to do that, you need to (naively) write the program twice: once as a server with rules (and protocol for prioritizing message passing), and again as a client with rules (and rendering and I/O). And you need a method for dealing with desync where the clients and servers don't agree on history, and you have also jacked up the price-point on your client hardware.
Let's compare this to the web ecosystem. Here, the goal is to get as many users as possible, regardless of where they're coming from. How do we achieve? Well, if we use a thick client, we'll need to write a server, write a client that can act like a local server, and do that over again per device that will act as a client. And the platforms are heterogeneous and some of them (the mobile devices) are dirt-potato-power level (even the expensive ones, relative to the performance of a mid-tier desktop or laptop machine).
The tools to wrangle the complexity of writing the program repeatedly have grown (if you use Node, for instance, your client and server can share library code... that seems like such a nice-to-have until you find yourself wanting to run a regex client-side and discover your server and client libraries have different regex dialects!). But the cost of maintaining a service structured like what you want is still exorbitant; each change requires an update to the server and a parallel update to the client application, all the client applications, testing on all of them. And you either embrace the complexity and maintain different clients for different platforms or you lowest-common-denominator it and the client running on the beefy PC has the same feature-set as the phone client.
So instead, the model that has won out so far is one where the server is thick and the client just handles sending commands to mutate server state as it can. Beefy clients might have access to more features, but the stronger you make the client the harder you make it to get everyone on-board.
> And you need a method for dealing with desync where the clients and servers don't agree on history
In MMORPGs, the desync frequently occurred from hackers. The end result was that all of the processing ended up on the server, with the client only rendering what was delivered from the server and sending movement/keystrokes to the server for processing.
> the model that has won out so far is one where the server is thick and the client just handles sending commands to mutate server state as it can
This is the natural result of having to deal with hackers and cheaters. Everybody running online games (re)discovers this.
You are describing blockchain applications. “Dapps” (decentralized apps) provide frontends to data which is stored on-chain. The blockchains themselves are (ideally) run by neutral nodes that validate state transformations (transactions) and assemble them into blocks. The blockchain is a never ending series of state transitions.
Many firms and projects are trying to build a new internet based on such principles. For example Verite is a protocol for decentralized identity which has very significant backers https://www.centre.io/verite
The problem is that these firms are trying to do inherently networked tasks with a framework that allows a lot of local-first computation. A local-first CRDT framework makes sense for document editing, and not really for social networking (mastodon), loans, or money transfers. Those really need to be networked.
I'm a little late replying to this, sorry. To preface, I'm not super familiar with the underpinnings of blockchains or CRDTs, so the below is just my current understanding. I wish I had more time to dig into them further.
Blockchains require consensus to propagate to all nodes before a change is solidified into the chain. This is useful for transactional data, but it also means one transaction can be completely dropped if there's a conflict and the other wins.
For something like document editing, for example, we don't necessarily need consensus and don't want to have to require another node to be online or reachable for a change to stick. Instead, we just need the merging of changes to be deterministic and consistent. With CRDTs, in theory, if two people go offline and edit the same document, each will merge the other's changes when they come online to resynchronize and they will ultimately end up with the same document. It doesn't matter who made the change first or what version of the document they have. It's like an automatic git merge.
While they're similar in some aspects, I think both blockchains and CRDTs have their place in specific scenarios where one makes more sense than the other.
I don't think thin vs thick is really the right metaphor here. The core of the platform services are moving to hosted infrastructure that is true, but this is orthogonal to whether the client using those services is thick or thin. The main reason we see thin clients using them is just that in the short amount of time for adoption you can't really do much more than build thin wrappers around these things yet.
But then, I have a more cynical take on the whole exercise. There isn't much more here than big tech trying to cannibalise / sabotage open protocols with proprietary ones, so that they can rent seek off the people who get trapped using them.
Telnet and X Windows being open did not change the "everyone logs into the development server, uses what IT installed and has a noexec $HOME" workflows.
To the extent that centralized (thin) systems can move faster, they also come with potential lockin and potentially higher switching costs. Some high enough level of lockin/costs can be an antitrust concern.
With Apple, Google, and Microsoft, it all just seems par for the course. They don't have a monopoly on security, privacy or innovation, like they sometimes think they do.
The problem is that everything has gone to SaaS application. Salesforce is not any better than goldmine is. It is just better marketing spin. We need to get back to thick apps, and use decentralized methods of collaboration.
I often fantasize about a set of standardized CRDTs using a relationship-based identity management system to connect people via a P2P mesh network, where applications are just "frontends" that simply organize and augment that underlying data. I dream of how the reliance on centralized servers can be reduced or even eliminated, depending on the circumstance.
Perhaps I'm naïve in this fantasy's feasibility in being implemented and/or in winning the uphill battle with the tech giant powers that be. A millennial can dream though.