We've been hard at work developing the Threads database and networking protocol. If you aren't familiar with Threads, please take a look at our whitepaper release post from December. TLDR; Threads are databases that run on IPFS with built-in support for decentralized applications, meaning multi-user, standardized encryption, and multi-protocol data exchange. Today, we wanted to give an update on our progress in developing Threads, showcase a couple of existing use-cases built on Threads, and invite you to try them out.
Background Links 📘
- A protocol & event-sourced database for decentralized user-siloed data
- Textile Buckets – dynamic folders over IPFS built on Threads
- Getting Started with Threads – an EthDenver primer
Progress in Threads development is variable depending on the platform you wish to use them in. We can break Threads libraries up into three categories: Clients, Lite Peers, and Full Peers.
|encryption, log, networking all handled on remote Peers.
Clients allow remote peers to manage log addresses and keys.
Great for cases where
- A device with limited resources can use a trusted remote Peer.
- A client is ephemeral and can’t store or maintain data.
|Encryption, log managed on client;
networking handled on remote Peers.
Peers have own log IDs; networking is handled remotely.
Great for cases where
- a device doesn’t have continuous access to the network.
- a peer has limited ability to do p2p networking
|Encryption, log addresses, and networking handled on Peer
Great for cases where
- Peer is running on a server or is embedded in a Go application
- Peer has access to static address
- Peer is going to provide networking or log services to remote client or lite peer
Above, you can get a quick overview of the status of each Threads implementation. These are changing quickly as new Peer implementations come online or enable new features. For example, the lite-peer implementation of js-threads is nearing completion, and we are moving quickly to enable the features of a full-peer as well.
Threads in Action 📐
The primary implementation of Threads is written in Go. You can follow the progress of that library here: https://github.com/textileio/go-threads/. The go-threads library contains the latest and greatest features of Threads, today. At Textile, we have started using go-threads in our own projects extensively.
If you caught our release of Buckets last week, you might have noticed they are built on Threads. Buckets allow users and teams to manage dynamic folders stored locally and on remote IFPS peers. They are a powerful tool for any IPFS user who wants a more natural way to manage and publish dynamic content, such as websites or blogs. Additionally, Buckets come with support for continuous integration, meaning a Thread containing your Bucket changes can be updated every time you push changes to GitHub.
Next Steps 🍿
- CRDT Codecs. Threads v0.2 were designed from the start with support for collaborating peers, using flexible Codecs to handle the messy work of conflict resolution. Our initial implementation focused on stability over flexibility, so our current reference Codec is a simple OT-style resolver based on JSON Patches. The next priority for Threads is to provide a full JSON CRDT Codec for maximum flexibility.
- Static ACLs and Dynamic ACLs. The first implementation of Threads enables permissionless data sharing in the Threads DB, so long as all parties have access to a Log in the DB, we allow them to write. This only solves a small number of use-cases, so currently, we are working on a flexible ACL implementation.
- Identity & Ownership. Threads don't have an explicit rule for how user-identity or ownership of Thread keys are maintained. For this, we are going to provide an exciting example of how Threads can be combined with a rock-solid identity tool later this month.
Discussion & Planning Changes 🤔
- The store in Threads will be renamed to Database – ThreadsDB!
- The new APIs developed for interaction with Textile Cloud (see EthDenver Guide) will be named the Service API.
- The existing Service APIs, which provide networking for Threads Peers and Clients, will be renamed the Network API.
- Models in the current store will be renamed Collections.
- Follower Keys (Replicator Keys in whitepaper) will be renamed to Service Keys.