A highly-configurable, distributed, realtime database that manages a state tree shared among many peers.
Redwood is a highly-configurable, distributed, realtime database that manages a state tree shared among many peers. Imagine something like a Redux store, but distributed across all users of an application, that offers offline editing and is resilient to poor connectivity.
Redwood is also an application server. Developers can store and update assets (HTML, Javascript, images) directly in the state tree. For many types of applications, you may not need a separate backend server at all.
Its flexibility allows developers to use a single, simple programming model to create many divergent classes of applications:
Redwood is part of the Braid project, and uses the Braid protocol to synchronize updates over regular HTTP. Braid is currently working through the IETF's RFC process to have its extensions to HTTP standardized (see IETF draft spec here: https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http)
Demos can be found in the demos folder. Each one has its own README with instructions.
Each demo comes with a debugging view that allows you to inspect the current state tree, the full list of transactions, and the swarm's current network topology.
Demos:
⚠️ Redwood is still pre-alpha software ⚠️ , but it already includes a number of compelling features. The quality of these features are being improved continually, and new features are added on a regular basis.
Keep an eye on our Github project board if you're interested in our roadmap.
git clone redwood://mysite.com/git
, and also push and pull, without actually setting up a Git server of any kind.(This section is in draft, although the information it contains is up to date)
Redwood has a goal of providing a multilayered, robust security model. It currently implements the following mechanisms to achieve this goal:
Users are identified by a public/private keypair (actually using Ethereum's implementation at the moment). All transactions must be signed by the sender, allowing recipients to verify the sender identities.
You can place "transaction validators" at any node in your state trees, and any transaction affecting the subtree under the validator will be checked by that validator. Currently, there's a "permissions" validator included that gives a simple way to control writes based on the Ethereum keypair I mentioned above. This part isn't very well fleshed out yet, but it provides what seems to be a solid model to iterate on.
You can also write custom transaction validators in Go/Lua/Javascript, which should make it trivial to implement just about any access control model you desire.
You can also create a "private" tree by explicitly specifying the set of users who are allowed to read from and write to that tree. The default Redwood node implementation does automatic peer discovery and keeps a list of peers whose identities/addresses have been verified. When it receives a transaction for a private tree, it only gossips that transaction to the tree's members (as opposed to its behavior with public trees, which is to gossip transactions to any peer who subscribes to that tree).
We also want secure persistent storage for transactions so that we can get high availability and redundancy without compromising the security model. To facilitate this, we allow you to configure the node to talk to what we're calling a "remote blind store" (essentially a key-value DB running on a separate piece of hardware, possibly off-site). The Redwood node encrypts transactions with a key the remote store doesn't possess and sends it over gRPC to the blind store.
Some applications will have a high volume of transaction data, and will want to be able to prune/merge/rebase that data to save space. To prevent bad actors from issuing malicious prune requests, the remote blind stores are going to implement their own p2p protocol involving threshold signatures. Prune requests will only be honored if a quorum of these blind stores sign off on them.