Buoy: A Web App That Builds Autonomy

From A World Without Police

AWWP sat down this month with Maymay, a developer working on the Buoy platform. Buoy is a mobile web app designed to help communities exercise collective power and build autonomy, outside state structures like the 911 call system. We urge others to test it out, give feedback, and help the project grow.  

Thanks so much for talking with us. Let’s start with an overview: what is Buoy?

Buoy is a tool designed to support communities in providing autonomy to individuals as they see fit, so we rely less and less over time on state structures, like the emergency response system or disaster relief efforts. The state does not provide on its promises even on the best of days. With something like Buoy, local communities can self-organize quicker, can make relationships with each other that are supportive, and ultimately eliminate the need to call 911 and specifically to call the police.

That’s the overall ambitious vision. But we can scale down a bit, because we’re not going to do that tomorrow. Let’s start with the emergency response system. Right now people call 911 because it’s the only option, for everything from “there’s a bomb on my street” to “I’m hearing noises that make me uncomfortable from the house next door.” And what happens when you call 911, because it’s a standard operating procedure of the response infrastructure the state provides, is that four men with guns show up to your house and make the situation a lot worse. Some people need more convincing that calling men with guns to your house is not the best solution, and some need less convincing. But everyone can agree that as the only option, it sucks. There should be some other options. So what would those be?

Buoy doesn’t dictate what those options should be. Instead, it provides a way for you to communicate with the people with whom you’ve had a discussion about what those options should be. It’s as easy as sending a text message. It’s broadcastable, so you can talk with many people at a time (which is actually something you can’t do as easily with a text or 911). And it provides a bunch of additional tactical tools, such as a map where you can see where the people responding to your crisis are, and the responders can see each other in relation to you and the crisis. With one-click directions, pinpoint geolocation, and livestream capabilities, and “take a picture and share it” capabilities. All in one interface.

None of those individually are new. We all know Google Hangouts and Google Maps. But putting those together with a messenger, which shows everyone the same view of where everyone else is, where you can all access the same livestream with one click, in one interface on your smartphone—that is new. The capabilities are knit together in a way that is helpful for telling people you trust where you are, what you need, and allowing them to talk with each other about that situation.

This allows what the military calls, ironically, a COP or “common operating picture”: everyone using this tool in this particular incident gets the same picture of what is happening. That’s useful because if you’re only talking to one person at a time, then you have to repeat yourself each time you bring someone else on board. But with Buoy it’s like a chatroom, one-to-many communication. Now Alice doesn’t have to text Bob, Joe and Carly individually that “I’m on the corner of Broadway and Bleecker,” because with this tactical tooling we all know Alice is twelve blocks away without having to say it. And that’s important if what you don’t want to be doing in an emergency is managing the logistics of your own crisis.

Can you give an example of how a group might implement Buoy?

A basic example we talked about early on was with this group called SMART Recovery. They’re an addiction recovery support group. In this case, the group has a text or phone tree to provide support outside of meeting times. One person moderates this support group and tends to get a lot of text messages from the other members who need help—I’m having a craving, I’m trying to stay away from this, this just happened and I’m feeling bad about it. And then this person has to look up who to delegate to because it’s Tuesday at 12pm. This means the people at the top of that tree have to be human switchboards, which can be really draining.

Buoy could be used in that scenario, because instead of having one dispatch number, you have a friends list that you’ve set up ahead of time, which we call a “team.” It’s just a list of the people in your group who you’ve opted-in to sending and receiving messages with.

Can you have multiple teams? 

Absolutely. And that’s not only useful for individuals, but it also speaks to the design philosophy that we don’t want to tell the end user how their community should support each other. Buoy is a tool that lets the end users construct their own structures to support one another in that community. So communities might develop their own conventions about who to send messages to in what scenarios. And you might have multiple teams for that. The ethic is about the autonomy and self-direction.

We’ve already started to write some guides about how and why you might set up multiple teams, there’s a page about it on our wiki. But it’s not going to be the same for everybody, and it shouldn’t be. It shouldn’t be the same for an addiction support group as for a street medic collective. If I’ve already told you how to construct your teams, I’ve cut out the possibility of making it most useful to both groups. Something we talk a lot about in the developer and contributor chatrooms is: here are the commonalities between use cases, now how do we optimize for those? Not simply because it’s good design, but also because it’s philosophically aligned with the notion of creating a tool where the end users define how it’s useful for them. This is a different model than Facebook, which says here’s what you can do, you have this range of things you can emote with. That’s it. They have made decisions about how you are going to use their tool. So have we, but we’ve optimized for end user decision-making, instead of fewer decisions.

Say more about the philosophy behind Buoy. 

Let’s zoom out a bit. Why is this the path we’re taking? Because this is, in part, a critique of the current way large-scale networks are organized. Right now, all systems in our society are organized in a top down way, with bureaucratic control from the top over smaller regions. But we know as anarchists and anti-statists that power flows from the bottom up. These two visions are in conflict, and–putting aside some philosophical musings about how they may or may not coexist–I don’t think anyone would disagree with the premise that currently we’re very much skewed toward top down. I want to at least balance that a bit.

What we see time and again is, when you need help, you are supposed to call an authority, someone at the top, instead of reaching out horizontally. Individually, that might mean texting multiple friends for help. But let’s take it an order of magnitude up: now I’m not just an individual who needs help, but a whole community needing help. The Social Center building was damaged in a fire. Now everyone in the Social Center needs support from other communities. How does a small community reach out for help from other small communities?

If you only have a top-down system, there’s literally no model under which that can happen. You have to call the top. But if you start from the bottom, now an individual can call out horizontally through the umbrella organization that they’re a part of. You go up a level of scale, but out to the people who are involved in that umbrella. And at the level of scale of “Social Center,” there are clear peers. Now, as the Social Center, you can easily envision the same process happening at that level of zoom, calling out to other social centers to assist. And if we extend this pattern as we zoom out, then we have more coverage, local action and awareness, but using the same paradigm from which to build an implementation. We don’t have to do something different per se at each successive level of scale, because we have something similar to model on. It’s fractal and emergent. And you only get that if you start from a bottom up approach. You cannot get that if you go from the top down. It’s not possible.

How is Buoy built? Say a bit about the technical details. 

Buoy exists right now as three separate components. The main one is a WordPress plugin. This is simply a capability that can be added to any self-hosted WordPress site. An overwhelming majority of small group sites run on WordPress, because it makes it easy to publish web pages. Now, with two clicks from the WordPress plugin directory, you’re done. You’ve added to your website a feature that allows logged in users—your membership, subscribers or readership who have accounts on your site—the ability to create Buoy Teams. They can navigate in the web browser just like any other website, create teams, search teams, draft crisis alert messages ahead of time, list themselves as being willing to offer support, and other things like use a GPG key if you’re security conscious. That’s all done through a web browser. So primarily Buoy is a mobile web app.

The other aspect of this is, you can bookmark Buoy as an icon on your phone, for when you use it in a rush. Now it behaves much like a native app. You have an icon called Buoy on your home screen, and when you tap that icon, a web interface pops up. It appears as “Buoy,” not as “Firefox” or “Chrome,” because it’s what we call “web app capable,” which means it has a tighter integration with the operating system on your phone, which makes it look and feel like its own app. There are a couple reasons for this. One is because we wanted Buoy to run more easily on more platforms. But also we wanted you to be able to use Buoy without installing anything! There are situations where people are put at risk by installing an app on their phone, like domestic violence scenarios or repressive regime scenarios. This way, Buoy has a much smaller footprint. You can “install” it by bookmarking it, and it functions like an installed app. But of course you don’t have to, and you’ll still get the exact same experience through a web browser.

Those are the only parts of Buoy that are released publicly right now, because they’re the only thing I feel comfortable offering to Beta testers. You can start using it tomorrow, and whether you’re five people or a hundred, it works.

The second component we’re building is installable from the app store, called Lifeboat. What that will do, once it’s ready, is provide an easier way for a single person to use more than one back-end Buoy website.

So if the Bronx Social Center has a Buoy-enabled website, and NYC Medics has a Buoy-enabled site, an individual could build teams in both groups?

Exactly. So with Lifeboat, in order to (a) be more familiar to people, and (b) add more client-side smarts, we want a native app. That’s in the works, and it will allow you to multiplex to multiple Buoys, and from there we can add more smarts to it. But the major feature is, if you are part of two different communities that both use Buoy, then this will make it easier to switch between them without having to have multiple Buoys on your home screen.

That’s good, because you can imagine a scaling scenario in which many organizations adopt Buoy in different ways, and now you’ll have a way for people to interact with all of that. It can become very complex, without being hamstrung by the complexity. 

Right! And there’s a third component that’s not actually done. We’re calling this Lighthouse. This component is also free software, and can be self-hosted. But now, the Buoys can begin to ask for help from each other.

These components are phases in a way. Phase 1 is to have a way to call my friends for help. Phase 2 is to be able to call multiple groups of people, who I know from different contexts, or who are working around different purposes. Then phase 3 would be: there are groups organized to resist ICE raids, build community gardens, and run volunteer health clinics. Now how does a health group call for support from an ICE defense group? If we can imagine a tapestry where groups are woven together, that would be Phase 3. That’s what Lighthouse is for.

Lighthouse is implemented as a Django application—it currently exists—and its first implementation is simply helping users answer the questions “what Buoy should I use? Is there a Buoy near me? How do I get access to a Buoy?” It shows people where they can go to receive the kind of help they need, both at the level of scale of an individual user, and as a community asking for help from another community. On a practical level, Buoy will send some telemetry, on an opt-in basis, to a Lighthouse. It will tell that Lighthouse, we have a bunch of people who are skilled in first aid. And now Lighthouse will know which Buoy to direct those kind of requests to.

This is a network topology called “hub and spoke,” and it’s got some established norms and best practices. Most people are familiar with Google Docs or Facebook, where everyone has to go to one service, use the database that service offers, and you store all your data with that service. But there are alternate models that are already very well implemented. For document sharing we have things like ownCloud and Nextcloud. With Nextcloud you have your own cloud and store your documents there. And if there’s someone else who has a different Nextcloud, you can still share documents with one another as if you were only using one Google Docs instance. But on the technical side, there are two separate IT admins.

This is implemented using a technique called “federation,” which is a technical term that simply means sharing data according to the user’s demands. It’s what I would like the Buoys and/or Lighthouses to do. I don’t know exactly at what level we’ll implement this, but the idea is that federation creates is a hub and spoke network, where you have one hub for one group of things (whether that be individual users or Buoys, and maybe both at different levels) and those hubs talk to each other, which then have their own hubs to different spokes, and so on. It’s not that every node is connected to every other node. There are larger pathways through which information flows.

So when we talk about this hub and spoke model, there’s a parallel between the technological implementation and the thing I would like to see happen politically, in terms of power distribution. I don’t want the United States of America to have a leader who decrees things from the top-down. But I do want there to be a way of pooling, organizing and collectivizing resources. That way we’re building not just tiny isolated pockets of autonomy, but rather a completely different world that has organization–without hierarchy.

Can you say a little bit about how Buoy is different than the other mutual aid apps out there?

Cell 411 and Vigilante are good examples, because they highlight different politics and implementations. One thing I find frustrating about Cell 411 is that they use all the language I just did, but their implementation looks nothing like it. Cell 411 is a tool that claims to be a decentralized emergency response network for individuals to not have to call the cops. But the obvious giveaway that their implementation is not ours is that, first of all, you download an app. That app talks to one and only one place, no matter who you are, and that is their server. So they have no notion of a self-hosted option. They are the only Buoy, there is no option for two Buoys in that system. They are a for-profit, Silicon Valley venture capital-backed company, whom everyone that uses Cell 411 is actually talking to, who then passes along your messages that are actually addressed to your friends. This is the same model as Google, Facebook and Twitter.

One thing that’s nice about the hub and spoke model is that if one Buoy goes down, you can still “use Buoy” by talking to other Buoy networks, because it’s not one monolithic service, and one Buoy doesn’t necessarily have to be attached to any other. But Cell 411 is different. Like Twitter, if Twitter goes down, no one can tweet. Now the downside to the federated model is that there are more IT admins, which means more human labor goes into getting that network up. But that’s not a problem for our political vision—that’s the good thing! If you want to have autonomous communities, it would be better to have more people maintaining their own technical services, and offering skills to the communities they care about instead of the employers they don’t. So this is actually a thing Cell 411 lacks both politically and technologically.

And Vigilante?

Vigilante is another centralized service. All the things I said about Cell 411 apply to Vigilante. But the difference is that Vigilante is effectively broadcasting the locations and information of people who self-report being in vulnerable situations to a larger public. I don’t know why the fuck they thought that was a good idea. Their pitch is: if we can share 911 information more quickly with the public, in an accessible way on a map, then people who are not just the cops can respond and help out. That maybe sounds good in theory, if you’re a white liberal who doesn’t mind random people showing up to help you when you call 911. But that is a terrible idea for anyone who has something to worry about their safety when they need help, such as people of color, undocumented immigrants, or people in mental health crises.

The problem here is political rather than technological. Who has time to be a vigilante in this context? Imagine just getting an alert from Vigilante. There’s a 911 call six blocks away from you, you’re at your coffee shop. What are you gonna do? You have no relationship with this person, you don’t know the details of what this call is. What this would tell most people is, “stay away from there.” But let’s imagine it from the other side. You have Vigilante because you have a lot of free time on your hands to respond to these alerts. What kind of person has that? Often someone (with a right-libertarian mindset?) that wants to protect their community from “crime”–which isn’t very well defined, and isn’t the main reason why people call 911 in the first place. A mom whose kid is causing a ruckus downstairs because he had a really shitty day might call 911 to get the kid to stop. But you don’t want right-libertarian-minded “I’m going to stop crime” vigilantes showing up in that scenario. Vigilante is the last thing that people calling for help, and not reporting crime, need. It’s the same reason we don’t want to call the cops.

Finally, there are other tools like Concrn or the Companion app. Some of these are better than others, but all of them are centralized technologically. And in some cases like Companion, what they do is forward a call to 911. That’s the design principle: they’re offering 911 a service, not you. Because as an app provider I have a lot more data about you than a direct 911 call. I know where you are, how fast you’re moving, where you’ve been, all this data about you that’s on your phone–and this is all data that they can, and sometimes do, feed to 911. The 911 system is actually very bad at geolocation, even the E911 system, the “enhanced 911” system, that we have in the States. That’s why when you call 911, they ask you where you are. There’s no technical reason for this anymore because if you have a smartphone it can pinpoint your location to a few meters, and that’s what Companion app sends to a dispatcher. That might be great if you think 911 is great, but if not, it might actually be a worse thing.

How can developers and organizers help Buoy to expand?

There’s much that needs doing, but it’s not all technical. Of course there are all the things that any technical project needs: people to fix bugs, test new versions, install the current version on your environment to see what’s different than on my environment. That’s one thing that’s harder in a decentralized model than a centralized one: not all computers are the same. You’re running Mac, I’m running Linux. Your server is runs PHP 5.5, mine runs PHP 7. We do need programmers to do all that, but we don’t need a hundred, we need maybe ten more.

In addition, if you are not a practiced programmer you can still help. There’s a user support forum that exists for Buoy, where you can post a question if you’re having a problem. There, it would be helpful if users who have gone through the process of creating a community support group and adding Buoy to it could help others do the same. We can write some documentation for questions, and link people to it on the forum, and develop this community knowledge and share it. Answering questions on the support forum, hanging out in the contributors’ chatroom so that when new people show up someone’s there to say “hi” to them—that’s useful too! Writing documentation if you’ve figured something out. We need people to learn this system, and help others learn what they learn. But most of all, to look around in their own communities, hook up with the politically and socially active folks around them, and begin or continue this conversation of “what does supporting each other mean for us, and how do we do this ourselves, without systems of authority?”

These are also the sorts of conversations we want to learn from, because those conversations help define Buoy’s direction, too: where do we go next? If a bunch of programmers get into a room and decide what to do, what they decide will not matter to anyone outside that room. That’s why, now that we’ve got a working prototype, I haven’t been coding a lot. Instead, I’ve been showing Buoy to different groups, and asking them how they currently handle support. For instance, I showed Buoy to someone and they said this looks great, but I don’t have a smartphone. And I was like oh shit, that’s a good point, there should be some way to interact with this through SMS on an old-school flip-phone. (That’s now possible, if still clunky.) Often these conversations lead to people asking questions: can I do X? If the answer is “no,” then we need to ask ourselves, would that be useful for more than one use case? Again, these discussions happen in our contributors’ chat room, a public space you’re more than welcome to join! This software comes from people asking those questions and telling us what they’re needing; I don’t have these ideas on my own. Other people have them, because they have techniques that already work for them. I’m trying to model those techniques, not impose new ones.

That’s how anti-police organizers can help. Think about how you would communicate your best practices. And then literally write those out and send them to us. I’ll probably write back and say tell me more about step 6 or 7, or what information do you have at step 2. If that happens in the chatroom, now we have multiple perspectives on the same problem. Then the conversation becomes about finding the commonalities, and that is the efficient way to direct limited developer resources, and provide the tooling that most people need most of the time.