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!


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.


Lessons from Architecture School: Part 3

This is the third and final installment in the series on Lessons from Architecture School: Lessons for IoT Security. You can also read the first and second installments, or download the presentation. Thank you to the audience at Solid Conference for good questions and lively discussion. Homes Are More Than Houses Shop houses are a type of vernacular architecture built throughout Southeast Asia. Vernacular architecture is built using folk knowledge and local customs, typically without the use of an architect.

MozFest 2021 - Will we see you there?

Over the next 2 weeks, Simply Secure will be hosting five sessions at the first virtual Mozilla Festival. If you’ll be there, we’d love to see you, learn about your work, and collaborate. Come join us!

Compelling Color

Great user experiences are born through the hard work of professionals with a variety of skills. As illustrated by the UX unicorn we've seen before, there's a lot that goes into what we call "design" or "usability". The skills and responsibilities of an effective UX team. Originally published in Building an enterprise UX team by Rachel Daniel (also on LinkedIn), UX Director at MaxPoint. Used by permission. Looking at this unicorn illustration, it may be tempting to dismiss visual design as a "