It’s a rare thing at a tech conference to hear cheers when someone says the internet is down. But then, DWeb Camp is a rare sort of tech conference.
To be fair, we knew that our access to the internet was going to get turned off, and we knew it was only for a day. And it was supposed to be a fun experiment, an opportunity to test all the local-friendly technologies that participants had brought with them. But for most people in the world, this is not a game; it’s a hard reality that they face daily. Almost half of us don’t have any access at all, and for many of those of us who do, access to high-speed internet is not easy, cheap, or reliable.
Some might argue that isn’t such a bad thing. I imagine those cheers came from a bittersweet awareness that the internet’s effect on society hasn’t all been rosy, a sentiment that’s echoed by most generation Xers and millennials in the connected world. But I think it’s also true that networked digital information technologies can be a potent force for empowerment and justice. Economic and political powers are already wielding these tools to their advantage, and those whose security is threatened by those same powers can (and sometimes must) use the same tools if they want to survive.
An urgent call to step up
Last year I learned about the success of Digital Democracy and Āhau, two groups building tools for indigenous people around the world to map the wealth in their ecosystems and cultures and use the collected data to preserve their sovereignty — even to the point of winning cases in federal courts.
This year, however, I heard fewer new success stories and more passionate calls for working tools. The message from activists and change-makers was clear and very loud: They need what we’re building, they need it to work, and they need it yesterday. We were confronted with stories from people working to support the survival of their people, stories from people striving to preserve bodily autonomy and gender-affirming care, stories from people trying to keep the lights on when infrastructure failed. The traditional web can’t serve these needs — you can’t deliver a cloud-based solution to people who have no internet, or whose access is policed by oppressive states.
The call was both encouraging and sobering. It showed that those of us building tools for decentralisation are on the right track, but it also revealed how much work we have ahead of us.
There’s a gap between creators and practitioners. Many of us are building tools that we hope the world needs. We start out ‘scratching our own itch’, reasoning that if we need something, then others must too. And that’s where our genius comes from; our creativity gives birth to new possibilities. But our technology is still young, and we haven’t had a lot of experience testing it to see if it is, in fact, what the rest of the world needs.
In many sessions, like a workshop that my colleague Collin and I hosted on questioning and testing our design choices, and a discussion circle hosted by DWeb Labs, we bridged the creator/practitioner divide to face one question together: how do we make our tech solve real problems?
Where to go next
The main theme I heard was that the specific tools don’t matter. What matters is that they work. The appropriate solution for a given context might be as simple as a web service running on a ten-year-old laptop, or even pen and paper, or it might be complex enough to warrant a blockchain.
In uncovering what this means, I heard a few other themes:
It’s time for developers and designers to unseat themselves as authorities, presenting themselves instead as servants who honour the wisdom and abilities of the people they’re designing for. Users are the best experts on what they need, yet the ‘culture of the expert’ undermines that and leaves them feeling disempowered.
One-size-fits-all tools are not necessarily going to work, especially if they embed assumptions that come from a western, educated, industrialised, rich, and democratised perspective. The key to transforming our design process is relationship — meeting the real people we intend to serve, not abstract personas, and learning to listen to them. Co-design, especially using an agile approach, is a well-established set of practices for sharing the design process.
This will result in culturally appropriate software, tailored to the needs of a specific group. But in our effort to make empowering software accessible to more people (that is, making it affordable to create and access these tools), we may also want to create ‘generic tools’ for ‘specific cultures’ — tools that, while one-size-fits-all, embed as few assumptions as possible. If we want to do this well, we’ll need to analyze our designs rigorously for cultural blind spots, make our tools as adaptable as possible, and most importantly, partner with real people to test them.
Solve for needs that are regular rather than rare. Rather than building with an eye toward a once-every-twenty-years type natural disaster, we can focus on creating tools and processes that help address everyday needs. From communication and coordination, to commerce or even play, people have to find a tool useful in their daily lives or they won’t adopt it. By serving everyday needs, we can ensure that these tools are already in use when one of those rare events inevitably comes along.
Build for surprise and delight. Similarly, if we build something that is all function, but isn't simple, easy, and effective in addressing the issue at hand, then people aren't going to use it. Like much of the open source software space, those of us developing distributed solutions need to get more disciplined about designing for ease of use.
I think there’s something unique in local-first tech that could actually surpass the user experience of cloud software. It makes apps ‘just work’ in ways that are challenging for the cloud to match — most DWeb stacks already give users offline mode and inbuilt privacy while making automatic scaling easy and low-cost for developers. Our next step is to close gaps that make the experience unfamiliar, complicated, and buggy. Adoption happens when the first experience is rewarding.
Better solutions are discovered when tool-makers cooperate with each other. We need a humility that’s courageous enough to step back when someone else’s tool is more appropriate for the job — even (or especially) if that tool is not digital. Rather than fix-alls, let’s see our projects (and distributed tech as a whole) as layers in a stack which shifts from use case to use case. By building greater interoperability between our tools, we can occupy ecological niches that are mutually supportive of each other. Protocol-agnostic approaches like those used by ADAM — which allow users to enjoy a unified experience bridging between spaces and tools — can help us leverage the richness of our ecosystem.
I was encouraged to see creators and practitioners forming coalitions; DWeb Labs was the most prominent of these. It consists of people who have separately been applying DWeb tech to big problems for years, so it’s wonderful to see them combining their experience and demonstrating the mutual respect that allows them to find the best solutions rather than compete for primacy.
There are new territories to explore. The DWeb community has long been about simply building alternative systems in the shadow of the dominant systems. There’s a subtly anarchic do-it-ourselves streak here; we prefer to “build a new model that makes the existing model obsolete”, in R Buckminster Fuller’s famous words, rather than fighting against big, top-heavy structures.
This DWeb Camp, I heard more people talking about dancing strategically with those structures. On a mere pragmatic level, governments and large corporations are the world’s biggest buyers of software, and sages like Mei Lin Fung encouraged us to consider how we could impact people’s lives if we got these institutions to adopt our tech.
There’s also room for us to start influencing public policy, educating lawmakers about the fact that the DWeb is not just a place where nasty characters hang out but can actually empower citizens in ways that align with the values these officials claim to uphold. And when the DWeb community cooperates on this, our unified voice will carry more weight.
We can never fully anticipate the consequences of our design choices, but we can speculate intelligently about them, uncover our assumptions, identify the gaps in our knowledge, and become curious enough to explore and close those gaps. And as we build up a community of practice with its own ‘pattern languages’ — libraries of interconnected design solutions that are proven through experience to work (or not work) for given contexts — the unknown will give way to a body of best practices, and our design interventions will become progressively more life-giving and less damaging to the people we serve.
A number of us are creating pattern languages together for various aspects of DWeb design, ranging from online communities to cryptographic protocols. Join us on the DWeb Discord server if that sort of thing gets you excited!
Celebrating how far we’ve come
In enumerating the challenges and opportunities ahead of us, I run the risk of making it sound like the decentralised web hasn’t made any progress. That is, thankfully, not true. As I mentioned before, organisations like Digital Democracy are pioneering the use of peer-to-peer tech in support of marginalised peoples around the world, and technologies like Braid, GUNdb, Holochain, Hypercore, IPFS, Secure Scuttlebutt, Solid, Spritely, and even humble HTTP are quietly being incorporated into tools that people are using in their daily lives.
When the internet was disconnected on the last full day of DWeb Camp, many of these technologies had moments of brilliance. Here are a few:
- DWeb of Community, a simple web app made available on the local mesh network, did one thing and did it well: it allowed us to quickly exchange contact information with each other using our smartphones. It demonstrated that sometimes a simple off-the-shelf protocol like HTTP is all that’s needed.
- Emergence, a scheduling app built by the Holochain team, was able to onboard a number of participants before the whole valley lost electricity, taking down the camp’s mesh network. You can read about our experiences building, testing, debugging, and deploying this app in Eric’s blog post.
- Even after the power went out, one team was able to continue using vossbol, a voicemail messaging app built with a peer-to-peer protocol that uses smartphones, Bluetooth, LoRa, and a cheap $20 microcontroller as a relay server.
- After electricity was restored, people got the chance to play with a few Holochain apps (including Acorn). The camp’s mesh network wasn’t completely restored yet, so we were able to connect computers using someone’s mobile phone as a hotspot simply acting as a router, without connecting to cell service!
- One participant was able to prototype and demo a local-first collaborative playlist app using GUNdb and Braid.
- The Guardian Project demoed their Butterbox device, a hub that deploys a local network and Android app store full of privacy-preserving, local-first apps.
- Hyper Hyper Space demoed Hyper, a web-hosted browser for their peer-to-peer asset-sharing network.
The challenges we face are real, but the need is also real, the opportunities are great, and we’re beginning to show the world what’s possible. As we work to improve the user experience, local-first, peer-to-peer, and agent-centric technologies will become better, more attractive solutions than cloud technologies. At that point, developers and their users may not care that they’re using something that’s more resilient, privacy-friendly, capture-resistant, and respectful of their dignity. But if we remain diligent about meeting real needs, everyone will become empowered by default as these tools are adopted.
