Building the Firebase for CRDTs
The first thing I read this morning was an excellent write-up on building the next generation of software, Local-first software: You own your data, in spite of the cloud. I recommend reading the whole thing, but the Call for Startups section got me thinking it was worth throwing our hat in the ring.
If you are an entrepreneur interested in building developer infrastructure, all of the above suggests an interesting market opportunity: “Firebase for CRDTs.”Such a startup would need to offer a great developer experience and a local persistence library (something like SQLite or Realm). It would need to be available for mobile platforms (iOS, Android), native desktop (Windows, Mac, Linux), and web technologies (Electron, Progressive Web Apps).
User control, privacy, multi-device support, and collaboration would all be baked in. Application developers could focus on building their app, knowing that the easiest implementation path would also given them top marks on the local-first scorecard. As litmus test to see if you have succeeded, we suggest: do all your customers’ apps continue working in perpetuity, even if all servers are shut down?
We believe the “Firebase for CRDTs” opportunity will be huge as CRDTs come of age. We’d like to hear from you if you’re working on this.
🙋 🙋♂ 🙋 🙋♂ 🙋 🙋♂ 🙋
It’s very refreshing to see “Firebase for CRDTs” as one of the outcomes of their thinking as those are the exact terms we often use to help scope some of our developer tools at Textile. I wanted to spend a little time now to share the Textile solution and how it relates to the “Firebase for CRDTs” concept.
What does Textile have off the list above?
- A great developer experience. Check. Join our developer Slack channel to see.
- Persistence library. Check. Baked into every Textile peer.
- Mobile platforms. Check. See our React Native, iOS, and Android libs.
- Native Desktop, Web, and Electron. Check. Forthcoming tutorial on building a desktop & React notes app (to pair with our mobile notes app). Our JS client library is getting closer to full-web support every day, but our desktop node already allows apps to run easily in the browser.
Okay, but now let’s get into the Firebase and Textile solutions.
What does Firebase do?
Above all else, Firebase is a platform that makes it easier for developers to build real-time apps quickly. It does so by offering a few dozen building blocks that all work well together, but each solves common challenges developers face when building their apps. Let’s look through some of the building blocks and how Textile makes easy to use IPFS-based replacements.
Real-time Database
Textile offers a concept called threads. Each thread can be a local or shared database. An app can create any number of threads on their user’s behalf. They are encrypted and private by default, but can then be shared with other user’s to orchestrate real-time data transfer. Threads have a schema, just like any database table, making the reading and writing of that data predictable. Just like Firebase, threads can also be backed up and restored via Textile’s cafes*, but in the Textile world, all that data is encrypted directly on the device, meaning cafes can never see what they are storing.
* Cafes are peers on the network that offer services to help make the network run better. They are trustless (all data in and out is encrypted) and run by any party on the network.
We use threads all over the place in Textile Photos to allow users to do real-time sharing of their photo data. Users create Groups in the UI, and behind the scenes, the app creates a new thread with a new set of encryption keys shared only by that group. Whenever a member of the group shares a photo, that photo is available to all other members in real-time.
The Epona app uses threads slightly differently, allowing a single user to store and publish (by creating unencrypted threads) content such as notes, blog posts and more.
Messaging
Baked into the thread protocol is a dedicated messaging channel called, chat. With chat, it doesn’t matter what schema your thread uses; your app can send and receive peer to peer messages to and from all members of the thread. Since Textile runs an IPFS peer on every device, we expose the P2P power of IPFS in an easy to use way for developers that is resilient to the challenges of say, mobile networks.
Again, in Textile Photos we use this to mix messaging right into the photo sharing UI! See the mixed photos + chat UI in the image above. The app doesn’t need to worry about anything complicated, listen to new messages or new photo shares using different API endpoints.
Authentication
We’ve remained very authentication agnostic in the Textile code. We believe app developers should be able to use whatever authentication tools they prefer. What Textile does do is provides simple, recoverable, private digital keys that can be joined with external authentication tools so your users can find and recover their app data whenever they log in or out.
Off-device storage & recovery
Developers and end users can opt into recovery services through Textile’s cafes. Cafes offer trustless network services. Every cafe runs an IPFS and can speak to apps over P2P protocols, helping to shuttle app messages over the network. They also can provide functions such as data storage and recovery. A developer can try out one of our hosted development instances or easily run their own (open source builds and docker images available).
Analytics & more
We are excited to expand the cafe based services far beyond what they do today. Analytics, serverless functions, webhooks and more are on our roadmap. We are a small team that moves fast, so stay tuned here.
Give Textile a try
If you are interested in jumping in, our developer Slack channel is a busy place with lots of people learning and offering support. A great place to continue your learning is the Tour of Textile, which will expand upon all the concepts I touched upon above.
Don’t hesitate to get in touch if you have any questions! Ping us on Twitter or shoot me an email at any time!