crdt-benchmarks
rust-libp2p
crdt-benchmarks | rust-libp2p | |
---|---|---|
8 | 31 | |
402 | 4,165 | |
- | 1.3% | |
0.0 | 9.8 | |
3 months ago | 2 days ago | |
JavaScript | Rust | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
crdt-benchmarks
-
JSON-joy CRDT benchmarks, 100x speed improvement over state-of-the-art
Author of Yjs here. I'm all for faster data structures. But only benchmarking one dimension looks quite fishy to me. A CRDT needs to be adequate at multiple dimensions. At least you should describe the tradeoffs in your article.
The time to insert characters is the least interesting property of a CRDT. It doesn't matter to the user whether a character is inserted within .1ms or .000000001ms. No human can type that fast.
It would be much more interesting to benchmark the time it takes to load a document containing X operations. Yjs & Yrs are pretty performant and conservative on memory here because they don't have to build an index (it's a tradeoff that we took consciously).
When benchmarking it is important to measure the right things and interpret the results somehow so that you can give recommendations when to use your algorithm / implementation. Some things can't be fast/low enough (e.g. time to load a document, time to apply updates, memory consumption, ..) other things only need to be adequate (e.g. time to insert a character into a document).
Unfortunately, a lot of academic papers set a bad trend of only measuring one dimension. Yeah, it's really easy to succeed in one dimension (e.g. memory or insertion-time) and it is very nice click-bait. But that doesn't make your CRDT a viable option in practice.
I maintain a set of benchmarks that tests multiple dimensions [1]. I'd love to receive a PR from you.
[1]: https://github.com/dmonad/crdt-benchmarks
-
CRDT-richtext: Rust implementation of Peritext and Fugue
Diamond types author here! Congratulations on getting your crdt working! It’s lovely to see a new generation of CRDTs which have decent performance.
And nice stuff implementing peritext! I’d love to do the same in diamond types at some point. You beat me to it!
Im building a little repository of real world collaborative editing traces to use when benchmarking, comparing and optimising text based CRDTs[1]. The automerge-perf editing trace isn’t enough on its own. And we’re increasingly converging on a format for multi user concurrent editing traces too[2]. It’d be great to add some rich text editing traces in the mix if you’re interested in recording something, so we can also compare how peritext performs in different systems.
Anyway, welcome to the community! Love to have more implementations around!
https://github.com/josephg/crdt-benchmarks
https://github.com/dmonad/crdt-benchmarks/issues/20
-
Cloudant/IBM back off from FoundationDB based CouchDB rewrite
So yes, a particularly large document is not the norm but it can happen.
JavaScript CRDTs can be quite performant, see the Yjs benchmarks: https://github.com/dmonad/crdt-benchmarks
- Automerge: A JSON-like data structure (a CRDT) that can be modified concurrently
- Automerge: a new foundation for collaboration software [video]
- Show HN: SyncedStore CRDT – build multiplayer collaborative apps for React / Vue
- 5000x Faster CRDTs: An Adventure in Optimization
rust-libp2p
-
On Implementation of Distributed Protocols
Substrate and Lighthouse use libp2p as a networking stack for communication between nodes. The libp2p framework is a versatile modular peer-to-peer networking stack. It provides a collections of abstractions, mechanisms, and protocols for facilitating communication in P2P systems. In particular, libp2p supports multiple transport mechanisms (TCP, QUIC, WebSocket, WebTransport, etc.), encryption schemes (TLS and Noise), and stream multiplexing. Higher-level protocols in libp2p are implemented on top of reliable, ordered, bidirectional binary streams, which are transparently encrypted and multiplexed by the framework.
-
Bifrost: A peer-to-peer communications engine with pluggable transports
It's a peer-to-peer "engine" with switchable components. Seems to run on different platforms (browsers, mobile, desktop, server).
At a glance, it looks pretty much like libp2p (https://libp2p.io/) but seems to integrate with libp2p as well (meaning you should be able to use Bifrost on one end, and libp2p on the other), so I'm guessing there is at least some fundamental difference, but I cannot spot it. Seems to use slightly different terminology compared to libp2p.
- Libp2p – A Modular Network Stack
- [AskJS] Any js browser based p2p libraries?
-
Decentralized Databases: ComposeDB
ComposeDB is a graph database created by 3BoxLabs, a company well-known in the Web3 ecosystem for their work on decentralized identifiers (DIDs) and their main product the Ceramic network. Ceramic is a network of nodes that store and share composable data streams on top of libp2p, the network stack that also powers IPFS.
-
What about a Zig implementation of lib2p2?
Yes, there is already a Rust version (https://github.com/libp2p/rust-libp2p) that behaves well at this level but I think we can reach a higher level of performance on this point with Zig. Also, if you look at the long term roadmap of libp2p (https://github.com/libp2p/specs/blob/master/ROADMAP.md), the mobile devices and IoT integrations for example are part of the considerations.
-
A Rust client library for interacting with Microsoft Airsim https://github.com/Sollimann/airsim-client
libp2p
-
Social Media on the Decentralized Web
At Filecoin Foundation, we see the technologies in the Filecoin ecosystem offering rock-steady stepping stones to this better future. Libp2p lets individual users find and talk to each other, without needing central servers. IPFS gives new services a way to find data, wherever it is stored — freeing them from dependence on one social media company over another and letting users move from one service to another. The Filecoin network itself, with incentivized storage, not only provides a provably stable basis for hosting content, but also shines a light on the kind of incentive systems that will enable independent social media to sustain and provide for itself for the long run, without relying on the largesse of the current tech giants.
-
Good sources to learn about IPFS?
Maybe https://libp2p.io
-
Fula: a new, innovative way to develop decentralized applications
So, after rolling my eyes and saying to myself 'not another web3 protocol', I began to understand the need for something new that not only takes advantage of the cutting edge in peer to peer networking but also acknowledges the fact that the client-server architecture is also not going away (which is incredibly important in a world full of low-powered, embedded devices).
What are some alternatives?
automerge - A JSON-like data structure (a CRDT) that can be modified concurrently by different users, and merged again automatically.
cosmos-sdk - :chains: A Framework for Building High Value Public Blockchains :sparkles:
diamond-types - The world's fastest CRDT. WIP.
go-livepeer - Official Go implementation of the Livepeer protocol
electric - Local-first sync layer for web and mobile apps. Build reactive, realtime, local-first apps directly on Postgres.
y-crdt - Rust port of Yjs
teletype-crdt - String-wise sequence CRDT powering peer-to-peer collaborative editing in Teletype for Atom.
freenet-core - Declare your digital independence
consensus-specs - Ethereum Proof-of-Stake Consensus Specifications
automerge-rs - Rust implementation of automerge [Moved to: https://github.com/automerge/automerge]
rust-crdt - a collection of well-tested, serializable CRDTs for Rust