Design Challenges in Decentralization

In working with decentralization projects funded by the Prototype Fund, I’ve been thinking more about overall design patterns for decentralized systems. By “decentralized systems”, I mean protocols, apps, and services that are non-centralized– including both federated networks, e.g. Mastodon, and peer to peer networks, e.g. Fritter.1 By “design patterns”, I mean recurring concepts we see in interfaces, workflows, and writing. For example, Projects by IF has a catalogue of patterns on Data Permissions that collects many design concepts related to privacy.

In looking at the decentralized space, the big question is what about our existing mental models as well as existing design patterns changes. For example, the pattern of account authentication (the trio of “login”/“signup”/“password reset”) is almost everywhere in centralized and decentralized tools. But in a decentralized system, authentication can work differently — it’s possible that the service you are connecting to doesn’t have your account information to complete the authentication. How do we communicate that difference consistently? Do users need to know that a system has decentralized technology under the hood? And when it comes to the interfaces we build: what new patterns can we develop to make decentralized systems easier to understand? Are there existing patterns that work well? With so many new decentralized tools emerging lately, the technology is (often) new, non-mainstream, and sometimes counterintuitive for experienced users of the centralized web.

In trying to tackle some of these challenges across the board, I’ve started compiling some emerging themes in decentralized systems design. I will give four areas as examples.

  1. Explanation and terminology
    How do you explain the difference between centralized and decentralized systems? What do users expect, what should be communicated without overwhelming people? What kinds of metaphors can we use to talk about this technology?

  2. Onboarding to Federation
    When onboarding new users to a federated system, what do they need to know about the federation? Does the system need them to choose which community to join? If so, what are the factors that should influence such a decision? What happens when they want to move from one community to another?

  3. Privacy/Discoverability
    There is a known trade-off between privacy and discoverability in p2p contexts.2 What choices does that present to the user experience? How do you communicate unusual privacy properties such as exposing people’s IPs? What settings should be allowed? On the other end of that spectrum: what UX options are there when there is no look-up table for privacy reasons?

  4. Identity Management
    Without a central authority in place, it can be hard to manage identities across different communities, or encryption keys across different devices. What are sensible UX flows that protect the user’s security without adding to their cognitive load? And how can our digital identity be framed differently to match the constraints and possibilities in decentralized contexts?

What’s next?

Many of these issues are sector-wide. Some of them require a joint effort from different decentralization projects to solve. And others present a huge and exciting playground for people interested in designing a totally different digital space. For now, I’m researching and compiling the patterns I see. Watch this space!


Acknowledgments

Thanks to everyone at #35C3 who pitched in, esp. Jan from Nextcloud, Ben from Matrix, Roel from XMPP, Elio from Ura Design, Ksenia from Delta Chat, Cade from Tactical Tech.

1 My definitions are largely based on this article, which also introduces the distinction between technical, political, and logical decentralization. I will mostly talk about technical decentralization, and specify when I mean political or logical decentralization.

2 See the dat whitepaper for an excellent description of the trade-off.

Related

Behind-the-Scenes: Emerging Conversations from Slack

Thank you to everyone contributing to the Simply Secure Slack channel. If you’re interested in joining, email slack@simplysecure.org for an invitation. I’m especially eager to get more UX people in privacy and security involved, so spread the world. Here are some highlights from our recent Slack conversations. Sharing the Rationale for UX Decisions Check out Gabriel Tomescu’s The Anatomy of a Credit Card Form sharing the Wave design team’s process for arriving at an elegant, easy-to-use form.

Design for Interoperability: Why Designers Should Pay Attention to the ACCESS Act

Interoperability can help people evade government repression, document human rights violations, and have agency over their data. We take a look at interoperability and a proposed US law that could help small projects be more successful and grow faster in a web controlled by a few large companies.

Your Software Can Help At-risk People, Too

Web browsers are utility software; they are designed to work for all people. Not only must their features meet the needs of average members of a population, they must also work for people with special needs. As Firefox says on its mobile accessibility features page, the browser has been "designed to meet the needs of the broadest population possible," but "sometimes that is not enough." In particular, software that is built for everyone can too often leave people with specific security or privacy needs at risk.