6 ms·

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 w

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.

seibelj 4y ago
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 https://www.centre.io/verite
- pclmulqdq 4y ago
  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.
- nvrspyx 4y ago
  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.
ricopags 4y ago
I believe you're describing something quite similar to Tim Berners-Lee's work on Solid[0]. [0]https://solid.mit.edu/ https://solid.mit.edu/
shadowgovt 4y ago
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.
- Tangurena4 4y ago
  > 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.
christophilus 4y ago
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.
- theragra 4y ago
  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
- couchand 4y ago
  I don't trust Zoom, but that doesn't mean I wouldn't trust any video client. Zoom is uniquely untrustworthy in the wide world of software.
samsquire 4y ago
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. [1]: https://GitHub.com/samsquire/merkle-crdt https://GitHub.com/samsquire/merkle-crdt [2]: https://braid.org/algorithms/shelf https://braid.org/algorithms/shelf [3]: http://bloom-lang.net/ http://bloom-lang.net/ [4]: https://www.hyperhyperspace.org/ https://www.hyperhyperspace.org/ [5]: http://boom.cs.berkeley.edu/ http://boom.cs.berkeley.edu/
- nvrspyx 4y ago
  Thank you for all the helpful information!

seibelj 4y ago

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 https://www.centre.io/verite

pclmulqdq 4y ago
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.
nvrspyx 4y ago
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.

ricopags 4y ago

I believe you're describing something quite similar to Tim Berners-Lee's work on Solid[0]. [0]https://solid.mit.edu/ https://solid.mit.edu/

shadowgovt 4y ago

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.

Tangurena4 4y ago
> 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.

christophilus 4y ago

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.

theragra 4y ago
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
couchand 4y ago
I don't trust Zoom, but that doesn't mean I wouldn't trust any video client. Zoom is uniquely untrustworthy in the wide world of software.

samsquire 4y ago

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. [1]: https://GitHub.com/samsquire/merkle-crdt https://GitHub.com/samsquire/merkle-crdt [2]: https://braid.org/algorithms/shelf https://braid.org/algorithms/shelf [3]: http://bloom-lang.net/ http://bloom-lang.net/ [4]: https://www.hyperhyperspace.org/ https://www.hyperhyperspace.org/ [5]: http://boom.cs.berkeley.edu/ http://boom.cs.berkeley.edu/

nvrspyx 4y ago
Thank you for all the helpful information!