One of the projects I'm working on is called Bramble. It's a protocol and a framework for building a new kind of decentralized application, one that's built for a mobile-first, offline-first world, and one that builds security in from the start. Bramble isn't just code, though, it's a way of seeing the world. We want Bramble to enable new kinds of relationships with the governance and function of infrastructure, of urban systems, and maybe even of societal institutions.
If you've heard of this project, it's probably because of our first app on the Bramble framework, Briar. Briar is a secure messaging application, and while it does a lot of novel things, it's just a start. If you've read my other pieces, you may remember me telling folks they shouldn't write new secure messaging tools. The caveat I mentioned then was for folks trying to do something exactly like this — pushing back the boundaries of how we can do messaging. In this essay, I'd like to tell you a bit about what makes Briar unique, and a bit more about the larger picture it's part of.
Briar is built on top of Bramble. Bramble handles all of the core functionality of sending blocks of data back and forth, managing contacts, keeping channels between users secure and metadata-free, synchronizing state between a user's devices, and handling dependencies between pieces of data or expiring them when they get too old. In addition to synchronizing data, Bramble lets applications use something like message queues to send each other queries or to invoke functions remotely. Briar uses this functionality to build a rich, easy-to-use messaging environment.
Bramble has been a long time coming. I started working on this idea in the winter of 2011-2012, and Michael Rogers, the lead developer, has been working on the messaging-specific parts of it for longer. Building systems that don't look like what folks are used to is hard, and funding them is harder. We've kept the project ticking over, though, and now we're finally off and running — possibly because the world is catching up a bit.
The biggest thing that makes a Bramble application different from any other app that you might run on your phone is that everything runs right on your phone, laptop, or both at once. Almost every traditional app that you use on a modern phone has some kind of server-side component keeping everyone in sync and providing an authoritative view of what's going on. If you can't talk to the server, you can't do anything at all — at best, you get access to some kind of “offline mode” for interacting with whatever data you have cached locally, likely read-only. This is better than nothing — the system doesn't treat being offline as an actual failure, but it's not enough to handle offline being “normal”.
Bramble apps let users work together offline. Because there's no server, there's nothing to be out of touch with. Bramble also understands how to use whatever connections your device has to find the folks you want to work with. If you're within Bluetooth or Wi-Fi range, Bramble will switch to talking directly to the other device, even if you don't have a connection to the Internet. Local network connections are the same — Bramble will talk directly to other devices whenever it can, and it only goes out to the outside world if it needs to. Bramble applications can even run over sneakernet if they need to — just tell the application that you want to send a USB stick worth of updates to a contact and then have someone run it over to them. We can handle latencies from a microsecond to a month while still maintaining the same security guarantees for levels of encryption and forward secrecy, even on one-way channels.
Bramble apps are also designed to work when they can't connect to other systems they're working with, letting you do everything you can normally and then synchronizing those changes to other devices when they become available. How complex synchronization is depends on the application. In Briar, it's easy — just sending and receiving messages that have queued up while you were offline. If you're old enough to remember using Usenet from a client running directly on an nntp server, it's kind of like that, and direct messages are like email used to be, back when we ran mail clients directly on mail servers. The difference, of course, is that you get all the modern conveniences and the machine is sitting in your pocket. In some applications, synchronization may be a bit more complicated, like if you've been editing a complex document at the same time as a friend has. Even in a situation like that, though, Bramble lets developers make the process no harder than the underlying problem is.
For something simple like editing we're already used to seeing the advantages of things like shared Google docs, and it's easy to see how that could be more useful if you didn't have to worry about having a fast Internet connection (or one at all) to collaborate. Likewise, one of the conveniences of the messaging use case Briar serves is that you can keep sending and receiving messages from friends, even as you, say, get on and off a subway train where there's no cell service. Other cases are even more interesting, though. If you're a team working together in the field with a decision support system that's helping you do something like allocate resources, you need it to work on the basis of all the current information you have, even when you can't be connected to the outside world. With a Bramble-based app, teams can make the best decisions on the basis of the information they have locally and don't need to wait to talk to central systems when they're in a hurry.
Trust is a critical issue with Bramble. The original use cases for Briar have always been as a communications tool for people at risk, whether they're journalists, political activists, folks trying to work together to organize a union, or sex workers or domestic violence victims who need to check in with friends to stay safe. When you work with a central server, you've also got a central point of control and surveillance. Better centralized communication systems use end-to-end encryption so the server can't see what you're saying, but the server can always still see who you're talking to and when. Metadata like this is often more dangerous to surveilled users than the actual message content. Worse, a centralized server can stop you from talking, either selectively or entirely. Briar lets groups work together without the risk or expense of a server.
One of the critical problems of many older secure messaging systems like PGP or S/MIME is how difficult they make it for users to understand who they're trusting with what. In Briar, users make trust decisions the same way people do in the real world — one person at a time. Again like in the real world, you can introduce one friend to another, but you can't construct the kinds of long chains of transitive trust that make understanding what's going on difficult. For an organization using Briar, it's easy to have an “introducer” whose job it is to ensure that everyone in the organization gets introduced to everyone else they should talk to. However, unlike with centralized systems, Briar doesn't require something like this to work.
Briar also takes anonymity seriously. In many situations, it's critical to be able to speak or organize without letting even the folks you're working with tie your work to your government-recognized identity. Briar works with Tor for a lot of reasons — it lets us make certain that we can get through firewalls, for instance — but we also support it for anonymity reasons, letting users ensure they only ever talk to the certain contacts (or anyone) through Tor. Even without using Tor, the only way you can tell who Briar traffic is intended for is if you see them receive it or if you're the intended recipient. Users can also have multiple identities in the system, complete with separate sets of contacts — say, one identity for talking to their friends and another one for the activism work. This can help people who need to compartmentalize their work for security reasons keep themselves, their peers, and their community safe. We're working hard to make sure that there are no information leaks between the identities that people use, but we're also working to make sure that all of this is as simple and easy to use as possible, because security systems that people can't understand don't help them at all.
Every Bramble app can provide this same set of security guarantees and tradeoffs to its users, and users can choose if they want to use any application with their usual identity and set of contacts, or corral it off and only use it with some of them. While in Briar each contact is normally another person, Bramble apps don't have to work like that — a node in the system can be all code, too.
Letting multiple applications all share the same framework is critical, and it harkens back to an earlier way of thinking about networked systems. We didn't always used to live in a centralized world, and the pendulum has swung back and forth between centralization and decentralization over the years. The core of the Internet itself is a shared decentralized framework for building systems, and that's why so many different systems and applications have been built on it over the years. If the Internet wasn't decentralized, this diversity wouldn't have been possible. While it would technically be possible to build something like Bramble on top of an existing intermediate protocol like HTTP, that's a system that inherently thinks of the world in terms of clients and servers. That mindset, compounded over years, has left us in a position where almost every web app depends on services from just a few different companies. If they decide they don't like your system or your users, you're in trouble. Stepping back from protocols that think in terms of servers lets us move back to a world where independence and interdependence are the norm.
With Bramble, we hope to make building a decentralized system as easy as building a centralized one. People build systems the way they do now because twenty years of work has made it easy. While simple cases of decentralization aren't too hard, filling in the details like security, trust relationships, or making applications work transparently when a user has multiple devices takes much more work. Bramble handles the details and provides developers with a uniform set of capabilities across platforms. While we don't expect to make up all the ground between building a decentralized system and quick and dirty web app in one leap, we've got the advantage of a much better perspective on where we want to go. There are a few things that are genuinely hard to decentralize — search at the scale of the Internet, for instance, or low-latency allocation of scarce resources among a very large number of users — but many use cases work just fine.
When you build an application that's serverless and offline-first, it means you get to ignore a lot of things other developers struggle with. We like to pretend that the Internet is always available and always fast, but even in the rich world, this isn't true, especially for mobile systems. Outages are a fact of life, even before you add in active attacks. The more critical a networked system, the more work must be done to ensure its connectivity. While systems built to serve critical needs may still need hard guarantees of how long they can be offline for, secure and reliable decentralization can make managing outages much simpler and enable resilient operation.
In most of the world, the Internet is neither fast nor reliable. Letting people collaborate locally means they can spend less money on bandwidth and keep working even in the face of frequent outages. Transport flexibility means that whatever set of communication systems are available locally can be adapted for use with decentralized applications, even if that means a USB stick and a motorcycle. In many cases, networks are even taken down intentionally to stop groups from organizing. We've seen this time and time again in different contexts, and not only do we want to ensure that people can continue to work under political repression, we believe that knowing that turning the Internet off will have little or no impact on targeted groups may discourage those in power from disrupting the lives of everyone else.
Bramble applications aren't just for people who have to put security first. While we believe they'll be more useful than the status quo for everyone, we think disaster relief use cases are another specific place where Bramble can have an unusual impact. Infrastructure can fail for a lot of different reasons. In a large-scale disaster, teams from large international NGOs deploy with heavy, expensive satellite systems to ensure each group in the field can maintain connectivity. Bandwidth on these systems is expensive and they take a while to set up. Often, teams working in the critical first 36 hours after a disaster have to do so with little or no connectivity. In many countries, local organizations will be working alongside international groups, and they rarely have the budget for ubiquitous satellite connectivity. Enabling direct synchronization for individual workers in the field gathering data or providing aid lets teams work with fresher data more quickly.
With Bramble, we don't just want to empower existing organizations to work in the same way more efficiently, we also want to let people work together in entirely new ways and build entirely different kinds of groups. We know that organizations build systems whose structure mirrors that of the organizations — centralized corporate development teams build monolithic applications, while decentralized, remote-heavy open source teams build sets of libraries held together by glue code. We believe that when you make it easy enough to develop and deploy loose, decentralized systems, you'll make it easier to build decentralized organizations.
One of the key properties of decentralized systems is that, when required, they can be composed back into centralized versions. You can only do this if you design for decentralization first, however. If the infrastructure you deploy requires you to have centralized control, at least part of your organization will have to be centralized, and maintaining decentralized structures around that core will take a significant amount of work. We've seen this cause real problems where decentralized political groups fight for control of that core, distracting from the work at hand.
In the disaster relief world, one of the ongoing issues is response efforts being constrained by organizational silos. This often means that critical data isn't shared as quickly as it's needed and decisions aren't made in coordination with other organizations. This is true even when folks on the ground are working side-by-side with each other. When IT systems makes it impossible to integrate relief infrastructure on the fly, there's less incentive to find a way around organizational or logistical divides. In some situations, you've got external teams deploying into communities that have on-the-ground qualified resources with local knowledge, like FEMA in the US deploying in rural areas that have volunteer fire departments and EMTs. Even when people are pre-qualified and easily-vetted, it's hard to integrate them into efforts. Decentralizing the tools teams use to work together can speed up this kind of integration.
The utility of changing the basic rules of how digital infrastructure works doesn't end with disasters and politics, either. One particular system I'm very interested in getting working with Bramble is Taarifa, a workflow system for verifying, triaging, and acting on crowd-sourced information. Taarifa has been deployed in, among other places, Dar es Salaam, where it's used to track the status of water points. When a water point there fails, the community near it often has no alternative source for healthy drinking water. Taarifa lets them report the damage, have someone check that it's really broken, have the city approve fixes, have an NGO partner fund the work, get it dispatched to a work party, have someone check it's really fixed, and then ensure that everyone in the chain is notified. Right now, all of this happens through a central server with all of the resilience issues and lack of flexibility this implies. Now, Taarifa is still a huge step forward, even in a centralized form. However, in combination with Bramble, the same basic experience for users can mean something different. The same system that provides a (critical and useful) bureaucratic structure for managing a piece of infrastructure could just as easily provide a market-based or mutual-aid-based, community-centric structure. When we decentralize not just a technical system but a social process at the core of managing collective infrastructure, we spread agency out through the community, give people a sense of ownership, and change their social relationship with the system. Technical shifts can't fix social problems, but theycan open up the space for change. While the cultural, social, and political transitions between different organization structures will always be the hard part, starting with decentralized technical systems for governance lets the infrastructure itself get out of the way of community self-determination.
Similar shifts may let disaster relief responses tie themselves into local markets instead of only bringing in supplies from outside a region, helping to reduce the impact of NGO aid response on regional markets. Right now, the influx of goods that comes when large NGOs respond to a crisis can destroy the economy of local business. Ensuring that everyone gets their needs met, that shipments are verified, and that small producers can still deliver goods on time is a huge coordination problem that must happen with little or no pre-built infrastructure. Currently this pushes NGOs toward central management and mass provision. However, the folks with the strongest understanding of what their needs are are those directly affected. As smartphones become more common, the idea of pushing resource coordination all the way out into the community becomes more possible. In many cases, it may be possible to pre-deploy a coordination application via a 311/city services type of app that can sprout additional functionality on the fly in a disaster. Alternately, instead of using a system like this only in a disaster, it might simply be an every-day part of local commerce, with an NGO able to simply cover the cost of supplies and monitor need without even necessarily intervening directly. Systems like these will be much easier to build on Bramble, where the architecture of the system can match the architecture of the problem.
Systems where all the points of control are distant from those using it are opaque. The user's model of such systems has little to do with how they actually work. When opaque systems are at the core of providing social services and managing civic infrastructure, the people who depend on those services are disempowered and detached from their society. When people have more control over their own infrastructure and more visibility into how it works, they have a better chance of making active decisions about those systems, and thus about their lives.
With Bramble, we want to let people build systems that work in a more human way. We don't want to provide fixed solutions, but rather kits-of-parts out of which folks can easily build systems that make sense for their lives. Building infrastructure that's secure, decentralized, and flexible is at the core of a different vision of how we can all live together. Bramble and Briar are both still under development. We'd love to have you come check them out, and maybe even pitch in: https://briarproject.org.
If you liked this essay, you can sponsor me writing more. I've started a Patreon where you can pledge to support each essay I write. I'm hoping to put out one or two a month, and if I can reach my goal of having a day of writing work funded for every essay, it will make it much easier for me to find the time. In my queue right now are a piece talking about what security strategy means, especially for new teams, more updates to my piece on real world use cases for high-risk users, and a multi-part series on deniability and security invariants that's been in the works for some time. I'd much rather do work that helps the community than concentrate on narrow commercial work that never sees the light of day, and you can help me do just that.
Thanks again! Eleanor Saitta 2016.2.29