I’m excited to announce the alpha release of OneDB, an open source backend-as-a-service. OneDB lets developers connect any frontend to the cloud, so users can log in, save, and share their data. You can think of it as Dropbox for structured application data, or if you’re a developer, you can think of it as Firebase without the downside of locking yourself (and your users) into a closed ecosystem.
With OneDB, we have two core goals:
- Give end-users ownership and control over their data
- Eliminate the burden of backend development
We achieve this by doing something radical: letting users keep their data wherever they want. It can be stored on their local hard drive, inside their company’s intranet, or on a public OneDB instance. Users can export, modify, or delete their data at any time.
And because the user is responsible for hosting the data, the developer no longer needs to pay for or manage backend infrastructure. This means frontend engineers can now deploy fully-featured, cloud-enabled apps, without paying a dime. The network of OneDB instances will handle all user authentication, data validation, and storage. Even if your app reaches millions of users, OneDB developers will never have to worry about scaling or funding.
But before getting into the specifics of how OneDB works, let’s take a step back and talk about federated applications.
Federated Apps: Make the Internet Democratic Again
Federated apps are apps that aren’t owned by any single entity. Anyone can come along and host their own server for the app, with its own rules and configuration. But users on different servers can still interact with one another, since they’re all using the same underlying software! A great example here is Mastodon, a democratic alternative to Twitter.
There’s no hiding the fact that Twitter, in spite of its overall success, has been struggling as of late. What began as a fun place to share links, have engaging discussions, and post cute pictures of your pets, quickly turned into a hate-fueled place filled with harassment and abuse. The problem is simple: Twitter is trying to force the entire world to live as a single community, with a single set of rules and norms.
Mastodon solves this problem by breaking its platform into many different communities, each with its own rules, moderators, and infrastructure. You get to choose which community you want to be a part of, and because every community runs the same software, you can still interact with people in other communities.
This means there is no centralized authority that decides who can and cannot use Mastodon’s technology to communicate — even the most odious hate groups can start up their own instance — but each community gets to decide which other communities it wants to interact with. This leads to a decentralized, self-regulating network, where no one is excluded, and everyone has control over what they see and who they interact with.
OneDB: Federated Apps Made Easy
If you wanted to create your own federated microblogging service today, you’d have a lot of work ahead of you. You’d need to:
- Choose a database and backend stack
- Write a REST API on top of your database
- Create an authentication mechanism, with e-mail verification, etc
- Get a few volunteers to host an instance of the backend (and pay for the necessary infrastructure)
- And finally: build a frontend where users can sign up and start writing
OneDB takes care of the first four points. All you have to do is build a beautiful frontend that your users will enjoy. Data storage, validation, access control, and authentication are taken care of by the existing network of OneDB instances.
The best part is, you can deploy your frontend for free (e.g. on GitHub pages), and you don’t have to worry about hosting a backend. This means that, for the first time ever, you can build scalable, cloud-enabled applications without paying a dime.
A Better User Experience
The OneDB login experience is very similar to OAuth, which will be familiar to any user who has logged into a website with their Facebook, Twitter, or Google account.
Say you’ve just come across a great new federated microblogging app, Tooter. You’ll probably see a login form like this:
When you click “Log In”, you’ll be taken to the OneDB instance of your choice, where you’ll enter your credentials:
Similar to OAuth 2.0, you’ll see the list of permissions the app has requested:
Once you click “Allow”, the app receives an access token which allows it to interact with your
microblog data. You can also log into the Data Explorer at data.one-db.org later on to see exactly what is being stored, as well as modify and delete data that you own.
If you want to get a better feel for the OneDB experience check out a few sample apps:
A Better Developer Experience
With OneDB, our aim is to provide all the ease-of-use that comes with Firebase, but without the lock-in or monetary costs. We’ll refrain from diving too deeply into all the features of OneDB, but here’s a taste:
You can check out the documentation to learn more about the OneDB developer experience.
Unleashing the Data
As we pointed out above, Twitter has been facing some difficulties lately. So why haven’t Twitter users abandoned ship for Mastodon or another microblogging service? The answer is simple: they’ve built their following on Twitter, and they can’t take it with them. Even though the users are the ones who created all the content on Twitter, Twitter owns that content, and they won’t just give it over to their competitors. That content gives them a legal monopoly.
But when applications are built on OneDB, the users own the data, and there’s nothing that forces them into a particular app or user interface. Anyone can come along and build a new app that interacts with
microblog data — all the user has to do is give the new app permission to access their data on the OneDB instance they’ve been using.
This means that we can have users interacting with one another across a wide variety of apps and platforms. Users can pick the interface that suits them best, rather than relying on a one-size-fits-all UI. Supplementary utilities can come along to help users manage and analyze their data, without having to get permission from an API provider (and Twitter in particular is notorious for cutting off API access to apps that built on top of their “platform”). A whole ecosystem of software can grow around user-owned data, without the original application’s creator serving as kingmaker.
Even better, new apps that interact with
microblog data will have a built-in audience. No more worrying about the chicken-and-egg problem when trying to build a social network or marketplace — just build your app on top of an existing OneDB namespace and your app will be full of content on day one!
Unleashing Free Software
Most software is economically unique in that it has zero marginal cost of production. That is, with each new user, your cost of providing the software doesn’t go up at all. Having one user costs the same as one million. This is mainly true of offline mobile/desktop apps and static web pages — once this type of software is written, it can be shared with the world for free.
However, for cloud-enabled software, this is no longer true. If you want your users to be able to log in from anywhere and see their data, or to be able to interact with other users, you need to provide database and backend infrastructure. And with each new user, your infrastructure grows more costly and more complex.
For small businesses and enterprises, this pain of dealing with cloud infrastructure has been mitigated by services like AWS. But for open source, free, and hobby projects, it can be a death blow. Unless the creator is willing to pay the cost of cloud infrastructure out-of-pocket, or has a plan to monetize the app, there’s no way to connect to the cloud. This means that there’s a ton of great, free software that’s not being written, simply because the creator doesn’t want to be stuck with the bill.
With OneDB, all this changes. Now you can deploy cloud-enabled software without having to pay for or manage backend infrastructure — the network of OneDB instances takes care of the backend. So if you’ve got an idea for a better social network, word processor, or productivity app, you can deploy it on OneDB with zero risk and zero cost, no matter how popular it gets.
So I don’t have to pay for backend infrastructure…who does?
Each OneDB instance gets to decide this individually. The instance at one-db.datafire.io will let end-users store up to 10MB of data for free, and will charge them a subscription fee after that. Other instances may offer free storage by selling anonymized data to third-parties (with user permission of course!). Still others might rely on donations, or only offer accounts to their employees or family members.
You keep saying decentralized, but you haven’t mentioned blockchain
While we have no current plans to use blockchain-based infrastructure or release a cryptocurrency, there are aspects of OneDB that would benefit from a blockchain. In particular, an immutable public ledger would be a better, fairer way of storing schemas (rather than keeping them in a single trusted OneDB instance). If you’re a blockchain pro and you think this sounds like a good idea, get in touch!
How does OneDB compare to similar projects?
I’ve written a bit about other projects with similar goals. There are three I’d position ourselves against:
- Firebase — this is probably the best proprietary BaaS out there. They’ve got a ton of momentum (they’re owned by Google after all) and have some slick interfaces for analytics and user management. But ultimately they’re a closed ecosystem, and if you build your app on top of Firebase, you’re stuck paying Firebase. And Google owns your user data.
- Blockstack — Blockstack is a highly ambitious attempt to rebuild the internet using blockchain technology. They’ve reinvented everything from user identities to the web browser. But the result is that end-user experience is quite foreign to the uninitiated (how many of your users want to manage their own private keys?)
- Solid — Solid is the closest thing out there to OneDB. They’ve got a great team (including inventor-of-the-internet Tim Berners Lee), and some stellar media coverage, but their focus seems to be on appealing to end-users rather than developers.
Here’s a Venn Diagram:
How does this fit into DataFire?
To date, DataFire has focused on serverless backend logic and third-party integrations. OneDB will add a database layer to DataFire projects, giving our developers the ability to add state to their applications.
Over the coming months we’ll create a OneDB integration for DataFire, and begin to incorporate OneDB into the UI at DataFire.io. Stay tuned for updates!
We need your help!
Hopefully we’ve convinced you that OneDB has the potential to save the Internet. But we’re a long way away from that goal, and we need your help getting there. Here are a few ways you can help out:
We’ll need a large ecosystem of apps out there before end-users see the upside of owning their data. If you’ve got an open source application that could use a cloud component, or if you’ve got a great idea for an app but don’t want to deal with backend infrastructure, consider using OneDB.
The best way to help is by submitting pull requests on GitHub. If you’re working on a large feature, let us know ahead of time and we can work together. Here are the big TODOs:
- Flagging/moderator APIs
- Group ACLs
- Websocket support
- Native-friendly authentication mechanism
- Identity linking across instances
- Desktop application for local storage
Host a OneDB Instance
Spread the word
Share this article with your friends and colleagues, especially anyone who can write a bit of code.
To sum up, OneDB has two enormous goals:
- Allow users to own and control their data
- Allow developers to deploy cloud-enabled software with zero cost
With your help, we’re confident that OneDB will make the Internet a fairer, safer, and more democratic place.
Thanks for reading! Join the discussion below if you have thoughts, questions, or concerns, or reach out to us if you’d like to help.