42 karma · joined January 1, 2019
They (we?) unfortunately never found product-market-fit. Actyx targeted the SME factory space with a p2p application platform. Turns out that developers in general don’t want to deal with the additional complexities of anything lesser than strong consistency, especially if they don’t fully drank the distribute-everything kool-aid. And SMEs don’t really bother either.
Philosophically decentralization is the right thing to do, but I’m thinking more and more that federation might actually be the compromise in the long run, at least for consumer apps. The only valid use cases for p2p edge devices with loose connectivity are in military applications.
Currently, your project seems to be an opinionated wrapper ontop of libp2p. For this to become a proper distributed toolkit you lack an abstraction to for apps to collaborate over shared state (incl. convergence after partition). Come up with a good abstraction for that, and make it work p2p (e.g. delta state based CRDTs, or op-based CRDTs based on a replicated log; event sourcing ..). Tangentially related, a consensus abstraction might also be handy for some applications.
Also check out [iroh](https://github.com/n0-computer/iroh) as a potential awesome replacement for p2p; as well as [Actyx](https://github.com/Actyx/Actyx) as an inspiration of similar (sadly failed) project using rust-libp2p.
Oh, and you might want to give your docs a grammar review.
Kudos for showing!
Totally! Only limiting factor are the teeth.
Somewhat related is a library I've been working on to generate an ffi between Rust and js code: https://github.com/cloudpeers/ffi-gen
Also I really like your universal_thread abstraction, hiding the whole web worker mess. I did a similar thing here: https://github.com/wngr/wasm-futures-executor