3 ms·

It's super unhelpful to write a post like this while showing very little evidence that you Googled the thing you want to see if it exists already. What about ht

It's super unhelpful to write a post like this while showing very little evidence that you Googled the thing you want to see if it exists already. What about https://docs.dat.foundation/ https://docs.dat.foundation/ or everything else in these comments?

cxr 7y ago
I like Dat, but right now it fails on the author's reliability criterion. And it's not clear[1] whether multi-writer is still a work in progress, which would mean a failure on "collaborative", too. 1. Looks like it's still not finalized, but it might be—and the uncertainty about the answer is a failure in and of itself.
- anchpop 7y ago
  Dat multi-writer already exists, here's a demo of it: https://dat-shopping-list.glitch.me/ https://dat-shopping-list.glitch.me/
  - pfraze 7y ago
    Unfortunately that demo was built on a protocol prototype which was deprecated. Multiwriter is still being worked on, but it's not in the current release schedule. The upcoming release focuses on performance, scaling, reliability, and "mounts" (effectively symlinks across drives). Mounts can be used to create a kind of multiwriter, as the mounts stay in the control of the author, but we don't yet have "multiple authors of a shared folder." In user-space, I've been able to create unioned folders like Plan9 did which is a _serviceable_ multiwriter scheme. A more sophisticated EC approach would use a vector clock in file metadata to track revisions but would need some approach to tombstones, which I don't have solution for yet. It's solvable, it'll just take time and performance tuning.
    - anchpop 7y ago
      I see, thank you
- substack 7y ago
  Many projects[1][2][3][4] in the dat ecosystem use kappa-core[5] for multi-user applications on top of hypercores (the low-level append-only log used by dat). kappa-core is designed around the kappa architecture where the logs serve as the historical record and primary source of truth (so you get version control) and materialized views ingest the logs to answer application-specific queries. Some nice properties of the kappa-core implementation of this architecture are that: * works fully offline by default and many of the apps (especially mapeo) are designed for very offline use * device to device replication is first-class * you can completely rebuild the materialized views from the log data whenever your schema changes (very nice way of handling database migrations) * there's a lot of flexibility in how you design the materialized views and an ecosystem of views on npm you can use instead of writing your own crdts * works in the browser There is also some progress in the ecosystem for sparse mode where content downloads from other feeds are driven by application-specific queries. There is a kappa-core workshop[6] that covers some of the introductory topics. [1]: https://cabal.chat/ https://cabal.chat/ [2]: https://mapeo.world/ https://mapeo.world/ [3]: https://cobox.cloud/ https://cobox.cloud/ [4]: https://arso.xyz/ https://arso.xyz/ [5]: https://github.com/kappa-db/kappa-core https://github.com/kappa-db/kappa-core [6]: https://kappa-db.github.io/workshop/build/01.html https://kappa-db.github.io/workshop/build/01.html

cxr 7y ago

I like Dat, but right now it fails on the author's reliability criterion. And it's not clear[1] whether multi-writer is still a work in progress, which would mean a failure on "collaborative", too. 1. Looks like it's still not finalized, but it might be—and the uncertainty about the answer is a failure in and of itself.

anchpop 7y ago
Dat multi-writer already exists, here's a demo of it: https://dat-shopping-list.glitch.me/ https://dat-shopping-list.glitch.me/
- pfraze 7y ago
  Unfortunately that demo was built on a protocol prototype which was deprecated. Multiwriter is still being worked on, but it's not in the current release schedule. The upcoming release focuses on performance, scaling, reliability, and "mounts" (effectively symlinks across drives). Mounts can be used to create a kind of multiwriter, as the mounts stay in the control of the author, but we don't yet have "multiple authors of a shared folder." In user-space, I've been able to create unioned folders like Plan9 did which is a _serviceable_ multiwriter scheme. A more sophisticated EC approach would use a vector clock in file metadata to track revisions but would need some approach to tombstones, which I don't have solution for yet. It's solvable, it'll just take time and performance tuning.
  - anchpop 7y ago
    I see, thank you
substack 7y ago
Many projects[1][2][3][4] in the dat ecosystem use kappa-core[5] for multi-user applications on top of hypercores (the low-level append-only log used by dat). kappa-core is designed around the kappa architecture where the logs serve as the historical record and primary source of truth (so you get version control) and materialized views ingest the logs to answer application-specific queries. Some nice properties of the kappa-core implementation of this architecture are that: * works fully offline by default and many of the apps (especially mapeo) are designed for very offline use * device to device replication is first-class * you can completely rebuild the materialized views from the log data whenever your schema changes (very nice way of handling database migrations) * there's a lot of flexibility in how you design the materialized views and an ecosystem of views on npm you can use instead of writing your own crdts * works in the browser There is also some progress in the ecosystem for sparse mode where content downloads from other feeds are driven by application-specific queries. There is a kappa-core workshop[6] that covers some of the introductory topics. [1]: https://cabal.chat/ https://cabal.chat/ [2]: https://mapeo.world/ https://mapeo.world/ [3]: https://cobox.cloud/ https://cobox.cloud/ [4]: https://arso.xyz/ https://arso.xyz/ [5]: https://github.com/kappa-db/kappa-core https://github.com/kappa-db/kappa-core [6]: https://kappa-db.github.io/workshop/build/01.html https://kappa-db.github.io/workshop/build/01.html