3 ms·

Further down on the README, it explains how it uses libp2p for network autodiscovery, IPFS for distributed storage, and how it can distribute and share routes a

by hosh 2y ago

Further down on the README, it explains how it uses libp2p for network autodiscovery, IPFS for distributed storage, and how it can distribute and share routes and assets and automating load-balancing. It is Webassembly-native, so you don't have to mess with compiling dependencies or execution environments. If it works as well as described, then the underlying technology (and the constraints they have) allows it to be self-hosted while having some of the benefits for a managed platform.

sqeaky 2y ago
Thanks for digging in. Would be nice if READMEs opened up with what the thing was and maybe a one or two sentence problem and solution description.
- hosh 2y ago
  Sometimes, it's hard to tell how significant something is, and the creators may not even know until hindsight, let alone articulate it in a concise, accessible way. The initial marketing word usage such as "amazing" put me off at first ("Show me, don't tell me"), as well as how the author(s) poo-poo'ed on Kubernetes. (I've worked on both good and bad usage of K8S, so it isn't always a fairy tale, nor with a bad ending). However, it also read like someone who seemed to have a deeper understanding of infra writing about this, not just a vapid reinvention by someone who works mostly on the front-end, so I kept going with the README. Having said that, while I am a big fan of IPFS, I know there are performance issues with it. (Maybe Tau set up a private IPFS that is only used within the cluster, which may help it work faster). It also sounds like they are working on general container support, not just Webassembly. Overall, if they keep iterating and improving things based on how things work in production, then they'll end up with a fairly robust system.
threecheese 2y ago
I don’t know if the author intended to be “local first- adjacent” with this project, but I am seeing a lot of wasm-target projects lately, including replicated databases, and I wonder if this project isn’t a peek at what a truly distributed (browser-to-browser) workload might look like. This project persists the system config in GitHub, but if the components are wasm then there’s at a chance that they can use that provision themselves in every browser. Imagine a workload where a client does their own compute, by provisioning worker components locally and retrieving only shared data from your systems - how much cheaper would your hosting costs be?!
- hosh 2y ago
  Thanks for articulating that. I was groping around for something along those lines — going beyond easy self-hosted to local-first deployment. Considering the web3 origins, I wonder if the project founders had that in mind as well. There was a different, recent HN post about scoped propogators, which I find to have a lot of good potential for people to write and apply local customizations for their own apps. I don’t know if those are the killer use case for this, but I think ideas along these lines takes it further out of alignment with incentives for business models.
stavros 2y ago
If it works as well as described (ie as well as can be expected with IPFS as a storage layer), it doesn't work.
hinkley 2y ago
We used to call those “turn-key solutions”.

by hosh 2y ago

sqeaky 2y ago

Thanks for digging in. Would be nice if READMEs opened up with what the thing was and maybe a one or two sentence problem and solution description.

hosh 2y ago
Sometimes, it's hard to tell how significant something is, and the creators may not even know until hindsight, let alone articulate it in a concise, accessible way. The initial marketing word usage such as "amazing" put me off at first ("Show me, don't tell me"), as well as how the author(s) poo-poo'ed on Kubernetes. (I've worked on both good and bad usage of K8S, so it isn't always a fairy tale, nor with a bad ending). However, it also read like someone who seemed to have a deeper understanding of infra writing about this, not just a vapid reinvention by someone who works mostly on the front-end, so I kept going with the README. Having said that, while I am a big fan of IPFS, I know there are performance issues with it. (Maybe Tau set up a private IPFS that is only used within the cluster, which may help it work faster). It also sounds like they are working on general container support, not just Webassembly. Overall, if they keep iterating and improving things based on how things work in production, then they'll end up with a fairly robust system.

threecheese 2y ago

I don’t know if the author intended to be “local first- adjacent” with this project, but I am seeing a lot of wasm-target projects lately, including replicated databases, and I wonder if this project isn’t a peek at what a truly distributed (browser-to-browser) workload might look like. This project persists the system config in GitHub, but if the components are wasm then there’s at a chance that they can use that provision themselves in every browser. Imagine a workload where a client does their own compute, by provisioning worker components locally and retrieving only shared data from your systems - how much cheaper would your hosting costs be?!

hosh 2y ago
Thanks for articulating that. I was groping around for something along those lines — going beyond easy self-hosted to local-first deployment. Considering the web3 origins, I wonder if the project founders had that in mind as well. There was a different, recent HN post about scoped propogators, which I find to have a lot of good potential for people to write and apply local customizations for their own apps. I don’t know if those are the killer use case for this, but I think ideas along these lines takes it further out of alignment with incentives for business models.

stavros 2y ago

If it works as well as described (ie as well as can be expected with IPFS as a storage layer), it doesn't work.

hinkley 2y ago

We used to call those “turn-key solutions”.