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¹. 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². 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.