├── .github ├── FUNDING.yml ├── ISSUE_TEMPLATE │ ├── pattern-proposal-template.md │ ├── pattern-request-template.md │ └── suggestion-template.md └── workflows │ ├── update-format.yml │ └── update-website.yml ├── .prettierrc ├── README.md ├── glossary └── list.yml ├── patterns ├── .DS_Store ├── QR-code-verification │ ├── illustration.svg │ ├── index.md │ ├── qr-code-deltachat.png │ ├── qr-code-signal.png │ ├── qr-code-ssb.png │ ├── qr-code-threema.png │ └── thumbnail.svg ├── address │ ├── address-adium.png │ ├── address-matrix.png │ ├── address-thunderbird.png │ ├── illustration.svg │ ├── index.md │ └── thumbnail.svg ├── age-indicator │ ├── age-indicator-trello.png │ ├── illustration.svg │ ├── index.md │ └── thumbnail.svg ├── cautious-optimism │ ├── illustration.svg │ ├── index.md │ └── thumbnail.svg ├── conditional-file-sharing │ ├── Wire.png │ ├── illustration.svg │ ├── index.md │ ├── nextcloud.png │ └── thumbnail.svg ├── content-curators │ ├── Mastodon.jpeg │ ├── Twitter_lists.jpeg │ ├── illustration.svg │ ├── index.md │ └── thumbnail.svg ├── discovery-server │ ├── discovery-pub-radicle.png │ ├── discovery-pub-ssb.jpeg │ ├── illustration.svg │ ├── index.md │ └── thumbnail.svg ├── disposable-identity │ ├── disposable-identity-cabal.png │ ├── disposable-identity-deltachat.png │ ├── disposable-identity-discord.png │ ├── illustration.svg │ ├── index.md │ └── thumbnail.svg ├── host-roulette │ ├── Nextcloud.png │ ├── illustration.svg │ ├── index.md │ └── thumbnail.svg ├── library.11tydata.js ├── network-health-indicator │ ├── illustration.svg │ ├── index.md │ ├── network-health-indicator-ipfs.png │ ├── network-health-indicator-syncthing.png │ ├── network-health-indicator-utorrent.png │ └── thumbnail.svg ├── paper-keys │ ├── illustration.svg │ ├── index.md │ ├── paper-keys-1password.png │ ├── paper-keys-filevault.png │ ├── paper-keys-keybase.png │ └── thumbnail.svg ├── persistent-identity │ ├── gpg.png │ ├── illustration.svg │ ├── index.md │ ├── persistent-identity-keybase.png │ └── thumbnail.svg ├── physical-beacon │ ├── illustration.svg │ ├── index.md │ ├── physical-beacon-holo.png │ ├── physical-beacon-syncthing.png │ └── thumbnail.svg ├── prioritize-backup │ ├── illustration.svg │ ├── index.md │ ├── prioritize-backup-status.png │ └── thumbnail.svg ├── protocol-agnosticism │ ├── illustration.svg │ ├── index.md │ ├── protocol-agnosticism-adium.png │ ├── protocol-agnosticism-brave.png │ ├── protocol-agnosticism-email.png │ └── thumbnail.svg ├── secret-sharing │ ├── illustration.svg │ ├── index.md │ ├── secret-history-screenshot.png │ └── thumbnail.svg ├── social-radius-slider │ ├── illustration.svg │ ├── index.md │ ├── patchbay.png │ ├── social-radius-slider-gathertown.png │ └── thumbnail.svg ├── standards-marker │ ├── deltachat.png │ ├── illustration.svg │ ├── index.md │ ├── mapeo.jpeg │ └── thumbnail.svg ├── tombstones │ ├── illustration.svg │ ├── index.md │ ├── mapeo.png │ └── thumbnail.svg ├── trackers │ ├── illustration.svg │ ├── index.md │ ├── thumbnail.svg │ ├── trackers-bittorrent.png │ ├── trackers-ipfs.png │ └── trackers-tor.png ├── village-or-city │ ├── aether.png │ ├── illustration.svg │ ├── index.md │ ├── mastodon.png │ └── thumbnail.svg ├── visual-hash │ ├── illustration.svg │ ├── index.md │ ├── thumbnail.svg │ ├── visual-hash-cabal.png │ ├── visual-hash-github.png │ └── visual-hash-radicle.png └── whisper-links │ ├── illustration.svg │ ├── index.md │ ├── thumbnail.svg │ ├── whisper-links-briar.png │ ├── whisper-links-jitsi.png │ └── whisper-links-magicwormhole.png └── topics ├── identity-agency.md ├── moderation-curation.md ├── sharing-permissions.md ├── sync-status.md └── topics.11tydata.js /.github/FUNDING.yml: -------------------------------------------------------------------------------- 1 | github: [simplysecure] 2 | open_collective: dots 3 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/pattern-proposal-template.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Pattern proposal template 3 | about: Propose a new pattern to be added to the library. 4 | title: "[submission]" 5 | labels: pattern-submission 6 | assignees: '' 7 | --- 8 | 9 | ## The Design Problem 10 | 11 | ## The Design Solution 12 | 13 | ## Examples 14 | 15 | ## Why Choose ... ? 16 | 17 | ## Best Practice: How to Implement ... 18 | 19 | ## Potential Problems with ... 20 | 21 | ## The Take Away 22 | 23 | ## References & Where to Learn More 24 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/pattern-request-template.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Pattern request template 3 | about: Request a new pattern to be worked on for the library. 4 | title: "[request]" 5 | labels: pattern-request 6 | assignees: '' 7 | --- 8 | 9 | **Is your pattern request related to a problem? Please describe.** 10 | A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] 11 | 12 | **Describe one possible solution** 13 | A clear and concise description of what you want to happen. Is there a real-world example of this? 14 | 15 | **Describe alternatives you've considered** 16 | A clear and concise description of any alternative solutions you've considered. 17 | 18 | **Additional context** 19 | Add any other context or screenshots about the feature request here. 20 | 21 | **What are particular protocols, tools, platforms, or communities that share this problem?** 22 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/suggestion-template.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Suggestion or question 3 | about: Thanks for contributing! 4 | title: 5 | labels: 6 | assignees: '' 7 | --- 8 | -------------------------------------------------------------------------------- /.github/workflows/update-format.yml: -------------------------------------------------------------------------------- 1 | name: Prettify markdown 2 | 3 | on: 4 | pull_request: 5 | 6 | jobs: 7 | dispatch: 8 | name: commit fixes 9 | runs-on: ubuntu-latest 10 | steps: 11 | - name: Checkout 12 | uses: actions/checkout@v2 13 | with: 14 | # Make sure the actual branch is checked out when running on pull requests 15 | ref: ${{ github.head_ref }} 16 | 17 | - name: Prettify markdown files 18 | uses: creyD/prettier_action@v3.2 19 | with: 20 | prettier_options: "--write **/*.md" 21 | commit_message: "Prettify markdown formatting" 22 | env: 23 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 24 | -------------------------------------------------------------------------------- /.github/workflows/update-website.yml: -------------------------------------------------------------------------------- 1 | name: Update dots-website 2 | 3 | on: 4 | push: 5 | branches: 6 | - master 7 | 8 | jobs: 9 | dispatch: 10 | name: Dispatch update 11 | runs-on: ubuntu-latest 12 | steps: 13 | - name: Call update script on dots-website repo 14 | env: 15 | user: ${{ secrets.PAT_DOTS_WEBSITE_USER }} 16 | pass: ${{ secrets.PAT_DOTS_WEBSITE }} 17 | run: | 18 | curl -XPOST \ 19 | -u "$user:$pass" \ 20 | -H "Accept: application/vnd.github.everest-preview+json" \ 21 | -H "Content-Type: application/json" \ 22 | https://api.github.com/repos/simplysecure/dots-website/actions/workflows/3742993/dispatches \ 23 | --data '{"ref": "master"}' 24 | -------------------------------------------------------------------------------- /.prettierrc: -------------------------------------------------------------------------------- 1 | { 2 | "tabWidth": 2, 3 | "useTabs": false 4 | } 5 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Decentralization Off The Shelf 2 | 3 | Decentralized technologies enable alternative applications that challenge the traditional models: where government and corporate control are causing harm, decentralized technologies have the potential to bring about autonomy, resilience, and equity. 4 | 5 | However, adoption is slow. Developers and designers need resources that help them understand how to build decentralized applications. Designers need new patterns and approaches for driving the development of decentralized protocols and applications. 6 | 7 | This is the work-in-progress library of patterns to support the design and development of better user-facing applications that are backed by decentralized architecture. 8 | 9 | You can see these patterns in ther published state, on the [pattern library section of the Decentralization, off the shelf website](https://decentpatterns.xyz/library). 10 | 11 | ## Contributing 12 | 13 | This pattern library would not exist without YOUR contributions. Please feel free to open an issue or pull request to start a discussion or suggest changes to any of these patterns -- or add a new one! We are actively seeking more input and expertise to advance existing patterns we've already released in this repository. 14 | 15 | If you'd like to contribute to an existing pattern or propose a new pattern, please feel free to open a pull request or [open an issue](https://github.com/simplysecure/dots-patterns/issues/new/choose). 16 | 17 | Stay up to date by watching this repository. Maintainers will be prompt in responding to inquiries! 18 | 19 | ## Governance 20 | 21 | Decentralization Off The Shelf is an initiative hosted by Simply Secure, a US-based nonprofit supporting the usability of safety and privacy tools. 22 | 23 | The initiative is currently maintained by Eileen Wagner and Karissa McKelvey, and has a group of volunteer contributors and advisors. 24 | 25 | [Read more about governance structures and our Code of Conduct.](https://decentpatterns.xyz/governance/) 26 | 27 | ## Support Us 28 | 29 | You can support us by [donating to DOTS](https://decentpatterns.xyz/support-us/) or through direct contribution to this repository. 30 | 31 | ### Backers 32 | 33 | Backers support this project by contributing $2 to $99 a month. [Become a backer](https://opencollective.com/dots#backer) 34 | 35 | ### Sponsors 36 | 37 | Sponsors support this project by contributing \$100 a month or more. [Become a sponsor](https://opencollective.com/dots#sponsor) 38 | 39 | 40 | 41 | ## License 42 | 43 | All design patterns are licensed CC-BY 44 | -------------------------------------------------------------------------------- /glossary/list.yml: -------------------------------------------------------------------------------- 1 | - word: Information 2 | definition: '' 3 | aka: '' 4 | - word: Computer 5 | definition: >- 6 | Anything with computing power (e.g., mobile phone, laptop, raspberry pi, 7 | router). Anything that can store, read, or write zeros and ones. 8 | aka: device 9 | - word: Data 10 | definition: >- 11 | Zeros and ones stored in a computer, often combining to represent 12 | information. 13 | aka: '' 14 | - word: Software 15 | definition: A defined process that reads or writes data. 16 | aka: program 17 | - word: Database 18 | definition: 'Software that organizes, manages, and queries data.' 19 | aka: '' 20 | - word: Access 21 | definition: The ability to read or write data on a computer. 22 | aka: '' 23 | - word: Protocol 24 | definition: A set of well-defined rules for how data is sent between computers. 25 | aka: '' 26 | - word: Network 27 | definition: Many computers connected by a shared protocol. 28 | aka: '' 29 | - word: Server 30 | definition: A computer that manages access to data in a network. 31 | aka: '' 32 | - word: Cloud 33 | definition: Many connected servers. 34 | aka: '' 35 | - word: System 36 | definition: >- 37 | A set of computers and software working together as parts of an 38 | interconnecting network. 39 | aka: '' 40 | - word: Federation 41 | definition: Many connected servers where each server has autonomy over access rules. 42 | aka: '' 43 | - word: Replication 44 | definition: When a computer downloads the same data as another computer. 45 | aka: '' 46 | - word: Sync 47 | definition: When multiple computers see the same data. 48 | aka: '' 49 | - word: Peer to Peer 50 | definition: >- 51 | Each computer can act as a server for others, without needing a single 52 | (central) server. 53 | aka: '' 54 | - word: Seed 55 | definition: A computer in a peer to peer network that uploads data to other computers. 56 | aka: 'host, pin' 57 | - word: Leech 58 | definition: >- 59 | A computer in a peer to peer network that downloads data from a seed without 60 | uploading. 61 | aka: '' 62 | - word: Peer 63 | definition: A computer in a peer to peer network that both uploads and downloads data. 64 | aka: node 65 | - word: Discovery 66 | definition: >- 67 | The process by which one peer is able to make a connection with another 68 | peer. 69 | aka: search 70 | - word: Third party 71 | definition: 'A person or group besides the two coimputers primarily involved.' 72 | aka: '' 73 | - word: Data structure 74 | definition: '' 75 | aka: '' 76 | - word: Distributed Hash Table 77 | definition: >- 78 | A common data structure used across servers so that peers can discover each 79 | other. 80 | aka: '' 81 | - word: Gossip 82 | definition: >- 83 | When one computer (A) tells another computer (B) about data it received from 84 | a 3rd computer (C) without B and C talking directly. 85 | aka: '' 86 | - word: Group 87 | definition: A set of users who share some common data. Anyone can edit. 88 | aka: '' 89 | - word: Swarms 90 | definition: A set of peers on a peer to peer network that are all serving the same data. 91 | aka: 'backups, peers, hosts' 92 | - word: Fork 93 | definition: An editable copy. 94 | aka: remixing 95 | - word: Keypair 96 | definition: >- 97 | A two-part key used in cryptography to provide end-to-end encryption and 98 | signature verification. 99 | aka: '' 100 | - word: Public key 101 | definition: The part of a keypair that can be used by others to verify a signature. 102 | aka: '' 103 | - word: Private key 104 | definition: >- 105 | The part of a keypair that is used to create signatures and should be kept 106 | secret. 107 | aka: '' 108 | - word: Signed Data 109 | definition: >- 110 | Data with associated cryptographic payload that confirms the creator of the 111 | data also possessed the associated private key at the time the data was 112 | created. 113 | aka: '' 114 | - word: Interoperable 115 | definition: >- 116 | When two systems are able to exchange and make use of information from each 117 | other. 118 | aka: '' 119 | - word: Identifier 120 | definition: >- 121 | A number or string of characters that does not change and can be used to 122 | reference a piece of data or user at any point in time. 123 | aka: '' 124 | - word: Content Addressible 125 | definition: A piece of data that can be queried or referenced by what it contains. 126 | aka: '' 127 | - word: Hash 128 | definition: >- 129 | A list of characters that uniquely represents a piece of data as long as the 130 | same hash function is used. 131 | aka: '' 132 | - word: Tree 133 | definition: A data structure. 134 | aka: '' 135 | - word: Merkle Tree 136 | definition: >- 137 | A data structure common in peer-to-peer applications that protects and 138 | verifies data from tampering. 139 | aka: '' 140 | - word: Block 141 | definition: >- 142 | A small piece of data amongst many other small pieces of data with a 143 | specified maximum length. A block on its own may not be useful or 144 | interesting, but many blocks combined may represent more meaningful 145 | information. 146 | aka: '' 147 | -------------------------------------------------------------------------------- /patterns/.DS_Store: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/.DS_Store -------------------------------------------------------------------------------- /patterns/QR-code-verification/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: QR Code Verification 3 | tags: 4 | - ui 5 | topic: sharing-permissions 6 | description: "Securely verify or transfer information between two peers." 7 | --- 8 | 9 | ### The Design Problem 10 | 11 | Use QR codes to quickly scan and verify that a device or some information is secure. In a typical centralized application, we trust the person or company operating the website to verify content. A particular profile or piece of content is mediated by this central server. 12 | 13 | However, decentralized applications often rely upon very long strings of characters and/or numbers to identify people or a piece of information, especially for secure communication or secret groups. These very long URLS can be difficult to share in some cases. 14 | 15 | ### The Design Solution 16 | 17 | In a decentralized world, QR codes no longer have to link to a centralized shared item. Instead, you can embed information directly in the QR code to share with peers. QR codes can also be exported or printed as an image and sent over a third-party service such as WhatsApp. 18 | 19 | ### Examples 20 | 21 | ::: examples 22 | 23 | - [![QR Codes in Delta.Chat](qr-code-deltachat.png) delta.chat for verified groups](qr-code-deltachat.png) 24 | 25 | - [![QR Codes in Signal](qr-code-signal.png) Signal for verified devices](qr-code-signal.png) 26 | 27 | - [![QR Codes in SSB](qr-code-ssb.png) Secure Scuttlebutt for invitations](qr-code-ssb.png) 28 | 29 | - [![QR Codes in Threema](qr-code-threema.png) Threema makes QR Code prominent as part of the user id](qr-code-threema.png) 30 | 31 | ::: 32 | 33 | ### Why Choose QR Code Verification? 34 | 35 | When you want to securely verify or transfer information between two peers. 36 | 37 | ### Best Practice: How to Implement QR Code Verification 38 | 39 | Tell users when the QR code is safe to share publicly or should only be shared with trusted peers. 40 | Allow users to load the QR code as an image in case their camera is broken or unusable. 41 | 42 | ### Potential Problems with QR Code Verification 43 | 44 | Long pass phrases (such as a [mnemonic code](https://en.wikipedia.org/wiki/Mnemonic)) is more complex than showing and scanning a QR code or importing a backup file. However, these long phrases may be useful instead of QR codes in low-bandwidth scenarios where image uploading is costly or time consuming. If used instead of a QR Code, mnemonic phrases should be translated into the user's native language. 45 | 46 | ### The Take Away 47 | 48 | QR Code Verification is a user-friendly approach to transfer and verify information in decentralized systems. 49 | 50 | ### References & Where to Learn More 51 | 52 | https://www.usenix.org/system/files/conference/soups2018/soups2018-vaziripour.pdf 53 | -------------------------------------------------------------------------------- /patterns/QR-code-verification/qr-code-deltachat.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/QR-code-verification/qr-code-deltachat.png -------------------------------------------------------------------------------- /patterns/QR-code-verification/qr-code-signal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/QR-code-verification/qr-code-signal.png -------------------------------------------------------------------------------- /patterns/QR-code-verification/qr-code-ssb.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/QR-code-verification/qr-code-ssb.png -------------------------------------------------------------------------------- /patterns/QR-code-verification/qr-code-threema.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/QR-code-verification/qr-code-threema.png -------------------------------------------------------------------------------- /patterns/QR-code-verification/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | -------------------------------------------------------------------------------- /patterns/address/address-adium.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/address/address-adium.png -------------------------------------------------------------------------------- /patterns/address/address-matrix.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/address/address-matrix.png -------------------------------------------------------------------------------- /patterns/address/address-thunderbird.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/address/address-thunderbird.png -------------------------------------------------------------------------------- /patterns/address/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | -------------------------------------------------------------------------------- /patterns/address/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Address 3 | topic: identity-agency 4 | tags: 5 | - ui 6 | - protocol 7 | description: "Users are uniquely identified by their handle and a server name." 8 | --- 9 | 10 | ### The Design Problem 11 | 12 | In a centralized world, it's assumed that other users are mediated through the 13 | same service. For example, a handle on Twitter is 14 | displayed the same to everyone else on Twitter. There is a global Twitter 15 | database of these handles, and each is unique -- no one can use the same handle as someone else. 16 | 17 | In a decentralized application, users may not be connecting to each other from the exact 18 | same service that you are. Data can be hosted by different 19 | services, and handles could be displayed differently depending on the 20 | application each person is using to connect. Because of this, a handle alone is 21 | often not sufficient to understand who you're talking to. 22 | 23 | ### The Design Solution 24 | 25 | Users are uniquely identified by their handle and a server name. 26 | 27 | ### Examples 28 | 29 | ::: examples 30 | 31 | - [![Address in Email](address-thunderbird.png) Email is the classic example of addresses (shown: Thunderbird app)](address-thunderbird.png) 32 | 33 | - [![Address in Adium](address-adium.png) XMPP has addresses similar to Email (shown: Adium app)](address-adium.png) 34 | 35 | - [![Address in Matrix](address-matrix.png) Matrix gives more visual guidance for address choice](address-matrix.png) 36 | 37 | ::: 38 | 39 | ### Why Choose Address ? 40 | 41 | - When users have a server that receives messages from other users. 42 | 43 | ### Best Practice: How to Implement Address 44 | 45 | Make sure that handles are unique on the same instance. Two users on the same device should be able to have two different handles. 46 | 47 | ### Potential Problems with Address 48 | 49 | It is often complex for a user to convert their address, account, contact list, and data to a new server. In practice, most users then do not transfer to a new server even if they become unhappy with their current one. 50 | 51 | If the user does decide to move to a new server, the user then needs to take on 52 | the cumbersome task of notifying all contacts of their new address. Recipients 53 | would need to trust your new address, without strong proof if it is the same 54 | person or even the same device. See [[Persistent 55 | Identity]] for making portability more secure. 56 | 57 | ### The Take Away 58 | 59 | Address can help give users trust in who they're talking to. 60 | -------------------------------------------------------------------------------- /patterns/address/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | -------------------------------------------------------------------------------- /patterns/age-indicator/age-indicator-trello.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/age-indicator/age-indicator-trello.png -------------------------------------------------------------------------------- /patterns/age-indicator/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | -------------------------------------------------------------------------------- /patterns/age-indicator/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Age Indicator 3 | topic: sync-status 4 | tags: 5 | - ui 6 | description: "Quickly distinguish if information is viral or stale" 7 | --- 8 | 9 | ### The Design Problem 10 | 11 | In a local-first world, peers may or may not be connected at all 12 | times, and information left by the users could be out-of-date. 13 | 14 | ### The Design Solution 15 | 16 | Give a visual indication for the age of a piece of information, for example 17 | when a peer was last seen. Fading a tag or a card usually works. 18 | 19 | ### Examples 20 | 21 | 22 | ::: examples 23 | 24 | - [![Age indicator in Trello](age-indicator-trello.png) Trello's Card Aging](age-indicator-trello.png) 25 | 26 | ::: 27 | 28 | 29 | ### Why Choose Age Indicator? 30 | 31 | Age indicator shows you information about participants without taking up too much space. It comes in handy to distinguish if information is viral or stale. 32 | 33 | ### Best Practice: How to Implement Age Indicator 34 | 35 | - Age Indicator is most effective when it comes to time sensitive information, 36 | like a 'best-before-date' feature. It highlights when something needs to be 37 | checked for validity. As such, it enables an assertion of truth as 38 | information gets referenced over time. 39 | - Make sure context is always clear. 40 | - Use Age Indicator in combination with a [[network health 41 | indicator]] to give advanced users more fine-grained detail. 42 | 43 | ### Potential Problems with Age Indicator 44 | 45 | - **Dimensions**. When there are multiple dimensions of ways information could 46 | age, it can be difficult to know what is being displayed. Is it when a peer 47 | was last seen? The last time this file was updated? Use age indicator coupled 48 | with clear visual cues about what about that information has aged. 49 | - **Contrast**. Ensure you pick a color contrast that allows for fading. 50 | - **Action**. A single visual indication is not enough to accommodate both spectrums of the 51 | 'aging' quality: Is it becoming irrelevant and out-of-date? Or has it become 52 | more valuable with the increased engagement over the course of time? Consider 53 | recommending an action (if any) that could be taken based upon the age of the content. 54 | 55 | ### The Take-Away 56 | 57 | Age indicator helps guide users when the age of content affects how a user 58 | should interact with it. 59 | -------------------------------------------------------------------------------- /patterns/age-indicator/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | -------------------------------------------------------------------------------- /patterns/cautious-optimism/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | -------------------------------------------------------------------------------- /patterns/cautious-optimism/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Cautious Optimism 3 | topic: moderation-curation 4 | tags: 5 | - protocol 6 | description: "Build opportunities for detecting and reacting to bad behavior" 7 | --- 8 | 9 | ### The Design Problem 10 | 11 | In a centralized world, trust is simple: all participants have to 12 | trust a single entity with their data. On a more fundamental level, 13 | participants have to trust that the server will connect participants to who 14 | they think they're being connected to. In other words, all participants have to 15 | put trust in one place, which can introduce a point of failure or attack. 16 | 17 | In a decentralized world, trust can and has to be placed in many different 18 | places. In a federated network, participants have to trust many authorities; in 19 | a distributed (p2p) network, all participants are equal, and have to be trusted 20 | on an individual basis. But deciding the level of trust for all connections to 21 | the network individually can sometimes be too taxing for users. 22 | 23 | ### The Design Solution 24 | 25 | Trust can be governed by a protocol. For example, the protocol can be generous 26 | (trust all by default) or guarded (trust none by default). But these approaches 27 | can sometimes be too rigid. 28 | 29 | Consider modeling game-theoretic insights on cautious optimism, e.g. trust 30 | each node until they violate a rule. This means the level of 31 | trust to another network participant is based on their past behavior. Depending 32 | on the context, this could be: sharing (or not sharing) your data for some 33 | period of time, or on a more social level, sharing with your friends of 34 | friends. 35 | 36 | ### Examples 37 | 38 | - ["Optimistic Unchoking" in BitTorrent](https://www.cs.helsinki.fi/webfm_send/1330) to mitigate free-riders, and promote peers who are willing to share 39 | files back. 40 | - ["Transitive interest gossip" in Secure 41 | Scuttlebutt](https://dicg2020.github.io/papers/kermarrec.pdf) promotes peers 42 | to share information with those who share the same interests or social networks. 43 | 44 | ### Why Choose Cautious Optimism? 45 | 46 | Trust is more fine-grained than a rigid protocol presumes sometimes; it can be 47 | revoked at any moment, and is usually tied to actual behavior. 48 | 49 | ### Best Practice: How to Implement Cautious Optimism 50 | 51 | - Make sure that the terms and conditions of network participation are made 52 | clear to all users, so that bad actors know they will be blocked or removed 53 | from the network for bad actions. 54 | - Allow people to override automatic decisions. 55 | - Consider embedding this idea in your technical and social code (e.g. Code of Conduct). 56 | 57 | ### Potential Problems with Cautious Optimism 58 | 59 | - Cautious optimism is still optimism. Plenty of bad actors could already benefit 60 | from being trusted once — especially if it's easy to create new disposable identities 61 | on the network. This strategy is only going to be useful if bad actors can be permanently removed. 62 | - Any policy that punishes users for breaking the rules risks punishing those that are new and 63 | unfamiliar with the platform. Make sure rules are transparently communicated up-front. 64 | - Justice may not always come in the form of punishment (e.g. blocking users), 65 | also consider what transformative justice might look like for your community. 66 | 67 | ### The Take Away 68 | 69 | When designing a protocol, build in opportunities for detecting and reacting to 70 | bad behavior. 71 | 72 | ### References & Where to Learn More 73 | 74 | - The "[tit for tat](https://en.wikipedia.org/wiki/Tit_for_tat)" strategy in game theory. 75 | 76 | - Rodrigues, Carlo Kleber da Silva. ["Analyzing peer selection policies for BitTorrent multimedia on-demand streaming systems in internet."](https://arxiv.org/abs/1402.2187) International Journal of Computer Networks & Communications (IJCNC) Vol.6, No.1, January 2014. 77 | 78 | - See [[network health indicator|network health indicators]] for one implementation strategy, tracking how long peers share data to determine whether to share with them in the future. 79 | 80 | -------------------------------------------------------------------------------- /patterns/cautious-optimism/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | -------------------------------------------------------------------------------- /patterns/conditional-file-sharing/Wire.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/conditional-file-sharing/Wire.png -------------------------------------------------------------------------------- /patterns/conditional-file-sharing/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | -------------------------------------------------------------------------------- /patterns/conditional-file-sharing/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Conditional File Sharing 3 | topic: moderation-curation 4 | tags: 5 | - ui 6 | description: "Help users collectively keep data online" 7 | --- 8 | 9 | ### The Design Problem 10 | 11 | In a centralized world, all content is managed by a single provider. It controls 12 | when and where data is stored. 13 | 14 | However, peer-to-peer applications like BitTorrent flip this concept on its 15 | head. There is no single provider who decides when and where data is stored; instead, 16 | anyone with access to the data can choose to re-host it to others at their 17 | discretion. Similarly, in federated applications, it's hard to know when and 18 | how your data is being shared between instances. 19 | 20 | ### The Design Solution 21 | 22 | - Allow users to set **parameters** for what to host. For example, "host until 23 | next week" or "share only users with property X". This can also be useful when 24 | trying to improve application or protocol performance if there are many 25 | users on the network. 26 | - **Create incentives** that encourage hosting less popular content. For example, 27 | "Users who share datasets with less than 5 peers get a free gold account." See [[Cautious Optimism]] for more details. 28 | 29 | #### Examples 30 | 31 | ::: examples 32 | 33 | - [![Timed messages in Wire](Wire.png) Wire offers timed messages](Wire.png) 34 | 35 | - [![Nextcloud retention](nextcloud.png) Nextcloud' retention can be filtered by tag](nextcloud.png) 36 | 37 | ::: 38 | 39 | ### Why Choose Conditional Sharing? 40 | 41 | When there is a large amount of information on the network with varied relevance and popularity. 42 | 43 | ### Best Practices: How to Implement Conditional Sharing? 44 | 45 | - Ensure you can control with whom data is shared and when, including 46 | individual blocks of data. 47 | - Create smart defaults based on the type of information and group dynamics of 48 | your application, but allow users to modify this easily using sliders and 49 | toggles. 50 | 51 | ### Potential Problems with Conditional Sharing 52 | 53 | - There are maybe still copies of data after the conditions are no longer met. 54 | 55 | ### The Take-Away 56 | 57 | Conditional sharing helps users collectively keep data online when it needs to be without a central coordinator. 58 | 59 | ### References and Where to Learn More 60 | 61 | Integrating the data availability layer (p2p redundant hosting) with tracking where data is being shared can provide insight into how data is being used by peers. See [[network health indicator|network health indicators]] for more. 62 | -------------------------------------------------------------------------------- /patterns/conditional-file-sharing/nextcloud.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/conditional-file-sharing/nextcloud.png -------------------------------------------------------------------------------- /patterns/conditional-file-sharing/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | -------------------------------------------------------------------------------- /patterns/content-curators/Mastodon.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/content-curators/Mastodon.jpeg -------------------------------------------------------------------------------- /patterns/content-curators/Twitter_lists.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/content-curators/Twitter_lists.jpeg -------------------------------------------------------------------------------- /patterns/content-curators/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Content Curators 3 | topic: moderation-curation 4 | tags: 5 | - ui 6 | description: "Choice, flexibility, and control over feeds." 7 | --- 8 | 9 | ### The Design Problem 10 | 11 | Decentralized social network providers struggle to decide between displaying 12 | everything and allowing users to choose certain filter options. This requires a lot of overhead in managing user feeds, and 13 | restricts user choice in what they are able to see. 14 | 15 | ### The Design Solution 16 | 17 | Users can pick third-party organizations, applications, or services to curate 18 | their content feed. Make it easy for developers to write programs that provide 19 | curation for social network feeds. Allow users to choose what algorithm(s) they want to use. 20 | 21 | ### Examples 22 | 23 | ::: examples 24 | 25 | - [![Mastodon](Mastodon.jpeg) Mastodon gives you the option to filter out "awful servers"](Mastodon.jpeg) 26 | 27 | - [![Twitter lists](Twitter_lists.jpeg) Twitter lists allow you to select content from a specific group](Twitter_lists.jpeg) 28 | 29 | ::: 30 | 31 | ### Why Choose Content Curators? 32 | 33 | - When you want to give users choice, flexibility, and control over feeds. 34 | - When you want to enable an ecosystem or marketplace of filters & algorithms. 35 | 36 | ### Best Practices: How to Implement Content Curators? 37 | 38 | - Only place trusted and verified third parties in the role of content curators. 39 | - Allow users to access more interesting and relevant content and therefore 40 | fosters a stronger and meaningful relationship with their network. 41 | 42 | ### Potential Problems with Content Curators? 43 | 44 | - Keep in mind that not all algorithms are necessarily good 45 | at curating content. In addition, they will each have their own biases. This can be made clear to users by including descriptions about each algorithm and what they do. 46 | - The added value of this pattern will depend on if content curators are vetted properly or if it is easy to use. 47 | 48 | ### The Take-Away 49 | 50 | This is more of an opt-in option rather than a catch-all solution for curating feeds. 51 | -------------------------------------------------------------------------------- /patterns/content-curators/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | -------------------------------------------------------------------------------- /patterns/discovery-server/discovery-pub-radicle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/discovery-server/discovery-pub-radicle.png -------------------------------------------------------------------------------- /patterns/discovery-server/discovery-pub-ssb.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/discovery-server/discovery-pub-ssb.jpeg -------------------------------------------------------------------------------- /patterns/discovery-server/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | -------------------------------------------------------------------------------- /patterns/discovery-server/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Discovery Server 3 | topic: sync-status 4 | tags: 5 | - protocol 6 | description: "A centralized server to discover new content and backup user data." 7 | --- 8 | 9 | ### The Design Problem 10 | 11 | In a centralized world, searching doesn't involve too many difficult decisions on the part of the user. When typing into a search box, the user trusts that the service is giving them the results they've asked for. This usually involves algorithms to display information in a way that makes sense to the user — including filtering, ranking, and selecting information intelligently. For most services, the user has little-to-no choice on how this search and discovery is executed on their behalf, and if controls are offered, these options are usually buried within profile and platform settings. 12 | 13 | In a decentralized world, users can choose which service is searching on their behalf to discover new information and users. New problems arise from this ability to choose their service, including: 14 | 15 | - Whose data am I searching? 16 | - Am I searching across the entire network, or just a subset of the network? 17 | - Who can I ask for help if the search doesn't work as intended? 18 | - How did this content get in my search, and how can I see more or less of certain topics? 19 | 20 | In a peer-to-peer application, you can only search for what you have downloaded, or what your known peers have downloaded. Similarly, in a federated context, search is only possible through your known server or federated server network. In both cases, if the network is very large, this decentralized search begins to surface problems in safety and performance. 21 | 22 | ### The Design Solution 23 | 24 | Users need to obtain a basic understanding of the differences between search that is mediated by federation and search enabled by a central service. Pair with the [[Content Curators]] pattern. 25 | 26 | Allow users to opt-in to search and discovery of content. For search, add indicators for scope (e.g., local vs global). For discovery, add indicators for filtering and curation. Allow users to opt-out of having their content searched through (e.g. locally vs globally). 27 | 28 | Provide the ability for users to easily configure which servers to search. These considerations can be governed by the protocol or client. For example, the client can be 'fat' (e.g., download everything by default and search it all); 'thin' (e.g., download very little and call out to another server for search); or 'gossipy' (e.g., search only what my direct peers or peers of peers have downloaded). 29 | 30 | ### Examples 31 | 32 | ::: examples 33 | 34 | - [![Discovery servers in Radicle](discovery-pub-radicle.png) Discovery servers are called 'Seeds' in Radicle](discovery-pub-radicle.png) 35 | 36 | - [![Secure Scuttlebutt](discovery-pub-ssb.jpeg) 'Pubs' in Secure Scuttlebutt](discovery-pub-ssb.jpeg) 37 | 38 | ::: 39 | 40 | ### Why Choose Discovery Server? 41 | 42 | When your application is heavily enriched by the ability to search and discover new content (e.g., social networks). 43 | 44 | ### Best Practice: How to Implement Discovery Server 45 | 46 | - Provide the possibilities to curate data and expand one's network while staying local. 47 | - If you are using a service for your search algorithm, transparently show the name of the service along with a way to contact those people (e.g., a git repository or website). 48 | - Services should provide filters for well-known abusive, fraudulent, or spam content. This is critical to prevent a scenario where first-time users see a bombardment of irrelevant or harmful content. 49 | 50 | ### Potential Problems with Discovery Server 51 | 52 | This can cause a dependency on particular services, re-centralizing the technical architecture and causing potential failures. To mitigate this, the protocol could allow for any peer to provide the search functions to another peer. 53 | 54 | There is still a need to address the privacy concerns regarding search queries and end-to-end encrypted information. For example, in a pure peer-to-peer network, users' search queries might encounter a risk if exposed to a wider network. 55 | 56 | ### The Take Away 57 | 58 | Search is possible in a decentralized network, and can provide users better control over which algorithms and filters to use, opening space for a variety of discovery services that can be run by anybody. 59 | -------------------------------------------------------------------------------- /patterns/discovery-server/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | -------------------------------------------------------------------------------- /patterns/disposable-identity/disposable-identity-cabal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/disposable-identity/disposable-identity-cabal.png -------------------------------------------------------------------------------- /patterns/disposable-identity/disposable-identity-deltachat.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/disposable-identity/disposable-identity-deltachat.png -------------------------------------------------------------------------------- /patterns/disposable-identity/disposable-identity-discord.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/disposable-identity/disposable-identity-discord.png -------------------------------------------------------------------------------- /patterns/disposable-identity/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | -------------------------------------------------------------------------------- /patterns/disposable-identity/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Disposable Identity 3 | topic: agency-identity 4 | tags: 5 | - protocol 6 | description: 7 | --- 8 | 9 | ### Why Choose Disposable Identity? 10 | 11 | - When you want to allow for a privacy-preserving method of connecting 12 | with trusted contacts. 13 | 14 | ### The Design Problem 15 | 16 | In many centralized applications, users are forced to create an identity (i.e., 17 | username and password) before interacting or creating content. Not only do 18 | "mandatory registration" pages pose a barrier to adoption, they also create 19 | a potential privacy breach and safety concern for some users. Furthermore, 20 | certain scenarios and contexts could be dangerous when long-lived identities 21 | are required, and can lead to violence and harassment. 22 | 23 | ### The Design Solution 24 | 25 | Store as much identifying information as possible on the user's device, and as 26 | little as possible identifying information on any service. Allow users to 27 | manually "self-destruct" all related identity information. 28 | 29 | You can also create an internal timer that deletes the identity after a certain 30 | amount of time. Display this prominently to the user upon identity creation. 31 | 32 | ### Examples 33 | 34 | ::: examples 35 | 36 | - [![Disposable identity in Delta.chat](disposable-identity-deltachat.png) Delta.chat QR codes create short-lived Email accounts](disposable-identity-deltachat.png) 37 | 38 | - [![Disposable identity in Discord](disposable-identity-discord.png) Discord requires only a nickname to get started](disposable-identity-discord.png) 39 | 40 | - [![Disposable identity in Cabal](disposable-identity-cabal.png) Cabal random nicknames can be changed later](disposable-identity-cabal.png) 41 | 42 | ::: 43 | 44 | ### Best Practice: How to Implement Disposable Identity 45 | 46 | - Identities could be created with limits set up front. For example, "this 47 | identity will self-destruct after 90 days". Allow the user to change this 48 | parameter. 49 | 50 | - Some users may want to decide to keep their identities as their permanent 51 | one after some time in use. Allow users to upgrade to a [[persistent 52 | identity]] if they want to keep it. 53 | 54 | - Consider making disposable identity very easy to create or even the default 55 | identity creation action. Allow users to simply scan a QR Code or click a link 56 | to generate their disposable identity. 57 | 58 | ### Potential Problems with Disposable Identity 59 | 60 | - **Guaranteeing anonymity is hard.** Clearly communicate the risks to users who 61 | are creating disposable identities. 62 | - **Spam and harassment.** Disposable identities should be paired with 63 | invite-only groups and contact requests for private messages. Implement 64 | strong anti-abuse features for public communities and content. 65 | - **Scaling issues.** With many disposable identities over time, some protocols 66 | or applications may have challenges with performance. Consider removing 67 | content after the identity has expired, but clearly communicate this to 68 | users. 69 | 70 | ### The Take Away 71 | 72 | When the main focus of your application is trusted connections and private 73 | communities, there are strong benefits in both usability and safety when 74 | disposable identities are the default interaction. With public content, 75 | this is much more difficult to implement safely. 76 | -------------------------------------------------------------------------------- /patterns/disposable-identity/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | -------------------------------------------------------------------------------- /patterns/host-roulette/Nextcloud.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/host-roulette/Nextcloud.png -------------------------------------------------------------------------------- /patterns/host-roulette/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | -------------------------------------------------------------------------------- /patterns/host-roulette/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Host Roulette 3 | topic: identity-agency 4 | description: "Encourage an equal distribution of users per server." 5 | tags: 6 | - ui 7 | --- 8 | 9 | ### The Design Problem 10 | 11 | In a centralized world, onboarding users to a service doesn't involve too many 12 | individual decisions. Data is hosted in the same place, permissions are handled 13 | by an administrator, and if problems arise — from questions around app usage, 14 | privacy policies, or tracking logs and activities — it's often all in the same 15 | hands of the service provider. 16 | 17 | In a decentralized world, onboarding users to a service require many user-side 18 | decisions. Data can be hosted by different parties; permissions can be handled 19 | by end users, super users, or the protocol itself; and if problems arise, it's 20 | unclear who or what to approach. 21 | 22 | A good design practice is to provide default options when onboarding. The app 23 | and protocol developers should think about sensible options for its user group, 24 | and offer them as pre-selected, out-of-the-box options. For example, when you 25 | are choosing a hosting provider (the party that will host an instance of your 26 | software, as it is in federations), you should always provide a default, 27 | recommended "host" and not let users research and choose among the many 28 | options. 29 | 30 | But this introduces another special problem: if all users get the same default, 31 | recommended "host", then that host will become a super server in the networks, 32 | thus accidentally introducing centralization again. 33 | 34 | ### The Design Solution 35 | 36 | The solution here is simple: if there is no reason to choose one hosting 37 | provider over another, randomly assign new users to a hosting provider. 38 | 39 | ### Examples 40 | 41 | ::: examples 42 | 43 | - [![Nextcoud hosts](Nextcloud.png) Nextcloud randomly selects a server for you](Nextcloud.png) 44 | 45 | ::: 46 | 47 | ### Why Choose Host Roulette ? 48 | 49 | When you want to steer the network into further distribution 50 | 51 | ### Best Practice: How to Implement Host Roulette 52 | 53 | Make sure you indicate that the host was randomly chosen, e.g. write "choose 54 | a different host" next to it, and visualizing the next randomly assigned host 55 | in a similar fashion. Think about animating this, too. 56 | 57 | Always offer users their own choice by making the choice editable (choose 58 | from list, for example). 59 | 60 | ### Potential Problems with Host Roulette 61 | 62 | Host Roulette only works if the options are truly equal. If you are building 63 | a social networks (more than an infrastructural network), you might want to 64 | present and even showcase different communities differently. In those cases, 65 | **choice matters**, and no default option should be provided at all. Instead, 66 | think about the 3-5 bigger communities that you want to offer as options, and 67 | test the copy with users to see if they all sound similarly attractive. See 68 | [[Village or City]] for ways to describe differences between instances. 69 | 70 | ### The Take Away 71 | 72 | Host Roulette can help you decentralize a network among equal, federated 73 | servers. 74 | 75 | ## References & Where to Learn More 76 | 77 | [Nextcloud's design decision](https://opensource.com/article/20/9/decentralization-signup) 78 | -------------------------------------------------------------------------------- /patterns/host-roulette/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | -------------------------------------------------------------------------------- /patterns/library.11tydata.js: -------------------------------------------------------------------------------- 1 | // This file configures data inserted into each pattern as it is displayed 2 | // on the dots-website 3 | 4 | module.exports = { 5 | layout: "pattern", 6 | tags: "pattern", 7 | eleventyComputed: { 8 | published: (data) => data.page.date.toLocaleDateString("en-us"), 9 | relatedPatterns: (data) => data.helpers.relatedPatterns(data), 10 | categoryName: (data) => data.helpers.categoryName(data), 11 | }, 12 | }; 13 | -------------------------------------------------------------------------------- /patterns/network-health-indicator/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | -------------------------------------------------------------------------------- /patterns/network-health-indicator/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Network Health Indicator 3 | topic: sync-status 4 | description: "Build trust through data visualizations." 5 | tags: 6 | - protocol 7 | - ui 8 | --- 9 | 10 | ### The Design Problem 11 | 12 | In a centralized world, users trust a particular server with data. It's assumed 13 | that the website will always be online, and if it goes down, you aren't able to 14 | access that data. 15 | 16 | In a decentralized world, we're able to increase the resilience of data by 17 | relying on multiple providers instead of a single provider. This means that if 18 | for some reason one service loses your data, another provider will have a copy. 19 | 20 | However, in a peer to peer or federated application, each of these servers is 21 | run by a different entity. It's sometimes unclear how and when these servers 22 | are online. 23 | 24 | ### The Design Solution 25 | 26 | Monitor and record device that downloads data. Keep a history of 27 | the time that data was synchronized for each device, and periodically check on 28 | these devices to ensure they have the latest copies. You can use this in 29 | conjunction with [[conditional-sharing]] to intelligently 30 | synchronize data to new devices. 31 | 32 | Allow the user to see what other devices have access and are re-hosting their 33 | data to the network. Visualize this information in the user interface at 34 | multiple scales depending on the details necessary per screen. You can use this 35 | in conjunction with [[age-indicator]] to understand how long 36 | it's been since a device has seen another, helping users understand if their 37 | data is safely replicated to another device and they can turn off their computer. 38 | 39 | ### Examples 40 | 41 | ::: examples 42 | 43 | - [![Network health indicator in uTorrent](network-health-indicator-utorrent.png) uTorrent provides a dense overview of network traffic](network-health-indicator-utorrent.png) 44 | 45 | - [![Network health indicator in IPFS](network-health-indicator-ipfs.png) IPFS gives it a modern touch](network-health-indicator-ipfs.png) 46 | 47 | - [![Network health indicator in Syncthing](network-health-indicator-syncthing.png) Syncthing provides device monitoring & control](network-health-indicator-syncthing.png) 48 | 49 | 50 | ::: 51 | 52 | ### Why Choose Network Heath Indicator? 53 | 54 | - Confirm that shared data remains widely available 55 | - Confirm that hosts supply data for a long time 56 | - Confirm that hosts do _not_ continue providing files after a deletion request 57 | - Identify peers with similar interests 58 | 59 | ### Best Practice: How to Implement Network Health Indicator 60 | 61 | - Allows users to perform self-diagnosis and debug their own network and get updated on the uptime of other devices. 62 | - Provides a variety of different network indicators such as confirmation of uptime, number of active connections, percent downloaded, etc. 63 | 64 | ### Potential Problems with Network Health Indicator 65 | 66 | There can be a lot of information about each device that isn't really useful 67 | to all users. Some users will want to see advanced information, like the IP address. Consider 'advanced' and 'basic' views that users can toggle on or 68 | off depending on what they need from the interface. 69 | 70 | Keeping a local database may not be enough to have the full scope of history, 71 | especially in peer to peer applications. Consider gossiping the data as part 72 | of the replication protocol. For example, if Bob synchronizes with Sally, and 73 | then logs off. Later Sally synchronizes with John, and John logs off. When Bob 74 | logs back on, he will not know that John also has the data. Sally's device 75 | should automatically tell Bob that she saw John while Bob was offline. This 76 | will ensure that users know who has seen the latest information. 77 | 78 | Some protocols by default will not have the ability to acknowledge or verify how much 79 | of a dataset has been replicated by particular devices. This is required 80 | to make Network Health Indicator more informative and accurate. 81 | 82 | Network Health Indicators may be unreliable in offline (i.e., [sneakernet](https://en.wikipedia.org/wiki/Sneakernet)) networks, 83 | where people share data offline using hard drives or other physical methods. 84 | This is also true for applications where users may disconnect from the network 85 | for large stretches of time. Implementing indicators in these environments may 86 | require tracking detailed network health history rather than continued uptime. 87 | Alternatively, utilize a notification protocol, such that peers notify one another 88 | when they are connected and available, rather than nodes polling all peers 89 | periodically to discover availability. 90 | 91 | ### The Take-Away 92 | 93 | Network health indicators reassure users and build trust in your application. 94 | 95 | ### References & Where to Learn More 96 | 97 | Network health indicators overlap with reputation and trust management, in that hosting data for a long period of time can be used to gauge the reliability of a peer. See [[cautious optimism]] and [[conditional file sharing]]. There are potential applications related to preventing DDoS and Sybil attacks. 98 | 99 | Network [heartbeats]() confirm _lack of data availability_, a component of [[tombstones]]. 100 | 101 | Tracking peers that re-host content can be used for social peer discovery, because someone mirroring files on an obscure topic likely shares that obscure interest. 102 | -------------------------------------------------------------------------------- /patterns/network-health-indicator/network-health-indicator-ipfs.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/network-health-indicator/network-health-indicator-ipfs.png -------------------------------------------------------------------------------- /patterns/network-health-indicator/network-health-indicator-syncthing.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/network-health-indicator/network-health-indicator-syncthing.png -------------------------------------------------------------------------------- /patterns/network-health-indicator/network-health-indicator-utorrent.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/network-health-indicator/network-health-indicator-utorrent.png -------------------------------------------------------------------------------- /patterns/network-health-indicator/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | -------------------------------------------------------------------------------- /patterns/paper-keys/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | -------------------------------------------------------------------------------- /patterns/paper-keys/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Paper Keys 3 | topic: sharing-permissions 4 | description: "Accessible verification, backup, and sharing" 5 | tags: 6 | - ui 7 | --- 8 | 9 | ### The Design Problem 10 | 11 | When wanting to grant access to a resource in a decentralized system, we can't 12 | necessarily depend on a trusted entity. Instead, we use a randomly generated 13 | list of numbers and letters, commonly called "keys," that grant access to 14 | resources. A resource could be an account, a group invitation, or a piece of 15 | data. 16 | 17 | These passwords can be very large, sometimes hundreds of 18 | characters. Because of this, it can be difficult to save or share these keys 19 | in the physical world. 20 | 21 | ### The Design Solution 22 | 23 | The user can save or print a file that can be used to gain access to the 24 | resource. The file itself should be easily human readable and printable. 25 | 26 | You can use this in conjunction with the [[QR Code 27 | verification]] pattern to make it easier to import the 28 | codes with the device's camera. 29 | 30 | #### Examples 31 | 32 | ::: examples 33 | 34 | - [![Paper Keys in 1Password ](paper-keys-1password.png) 1Password offers an all-in-one 'Emergency Kit'](paper-keys-1password.png) 35 | 36 | - [![Paper Keys in Filevault](paper-keys-filevault.png) Apple Filevault uses a serial number style key](paper-keys-filevault.png) 37 | 38 | - [![Paper Keys in Keybase](paper-keys-keybase.png) Keybase generates a multiple word passphrase](paper-keys-keybase.png) 39 | 40 | ::: 41 | 42 | ### Why Choose Paper Keys? 43 | 44 | Paper Keys is a safe and accessible method to verify, share, or backup information. 45 | 46 | ### Best Practice: How to Implement Paper Keys 47 | 48 | It is advisable that users know the risks, and have a secure and oragnised 49 | place to store the keys. Be clear with users that they should print it or 50 | save it in a safe backup location in case their device gets lost or stolen. 51 | 52 | ### Potential Problems with Paper Keys 53 | 54 | If lost, access to data is potentially lost permanently. 55 | 56 | If found by an adversary, it can lead to unauthorized access to data. 57 | 58 | ### References & Where to Learn More 59 | 60 | Projects by IF has outlined a similar design pattern called [Recovery Codes](https://catalogue.projectsbyif.com/patterns/recovery-codes/). 61 | 62 | [Investigating the Usability Issues Non-Crypto Savvy Users Encounter When Setting Up Desktop Wallets](https://medium.com/chockablock-io/investigating-the-usability-issues-non-crypto-savvy-users-encounter-when-setting-up-desktop-68323106587b) 63 | -------------------------------------------------------------------------------- /patterns/paper-keys/paper-keys-1password.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/paper-keys/paper-keys-1password.png -------------------------------------------------------------------------------- /patterns/paper-keys/paper-keys-filevault.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/paper-keys/paper-keys-filevault.png -------------------------------------------------------------------------------- /patterns/paper-keys/paper-keys-keybase.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/paper-keys/paper-keys-keybase.png -------------------------------------------------------------------------------- /patterns/paper-keys/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | -------------------------------------------------------------------------------- /patterns/persistent-identity/gpg.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/persistent-identity/gpg.png -------------------------------------------------------------------------------- /patterns/persistent-identity/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Persistent Identity 3 | topic: identity-agency 4 | tags: 5 | - protocol 6 | description: "Securely move between providers and aliases." 7 | --- 8 | 9 | ### The Design Problem 10 | 11 | A good design practice is to display extra information that can be used to 12 | locate a particular user. For example, for a federated service like e-mail, you 13 | add the service provider's name in addition to the name 14 | (sally@emailspace.net). This is sufficient but runs into issues when a user 15 | wants to change their name or provider. The user then needs to take on the 16 | cumbersome task of notifying all contacts of their new address. Recipients 17 | would need to trust your new e-mail address, without any strong proof that the 18 | sender is the same person or even using the same device. Users thus rarely 19 | change names or move providers even if they grow to dislike their current 20 | provider. 21 | 22 | ### The Design Solution 23 | 24 | Generate a new `id` when a user creates a profile. This is a sufficiently long 25 | string of characters that would be nearly impossible to guess (e.g., a public 26 | key). If the user changes their service provider or 27 | name, the `id` does not change, allowing an application to keep an 28 | up-to-date contact list and make it easier for users to understand if they are 29 | talking to the same person. 30 | 31 | ### Examples 32 | 33 | ::: examples 34 | 35 | - [![Persistent Identity in Keybase](persistent-identity-keybase.png) Keybase encourages publicly proving long-term ownership](persistent-identity-keybase.png) 36 | 37 | - [![GPG Keychain](gpg.png) GPG Keychains associate 38 | multiple keypairs with a single address](gpg.png) 39 | 40 | ::: 41 | 42 | ### Why Choose Persistent Identity? 43 | 44 | - When you want to enable users to securely move between providers and names 45 | with ease. 46 | 47 | ### Best Practice: How to Implement Persistent Identity 48 | 49 | - Users need to have strict control over when and where their id is shared. 50 | Never automatically share this id on a public service 51 | unless users explicitly opt-in to publicly sharing this id, as it could be used 52 | nefariously by 3rd parties to contact a user without their consent. 53 | - Make sure that the same id is not reused across names that are intended 54 | to be separate (e.g., two users on the same device should have two different 55 | ids). 56 | 57 | ### Potential Problems with Persistent Identity 58 | 59 | By assigning an id to a particular account, it can make it more difficult to 60 | create entirely anonymous accounts. For example, if a 3rd-party finds the id 61 | secret in the profile on the device's hard drive, they have linked that device 62 | to that account. To give extra security guarantees, ensure any identifiers are deleted 63 | completely from devices upon account deletion. See 64 | [[disposable-identity]] for more information about 65 | anonymous, one-time, and short-lived accounts. 66 | 67 | ### The Take Away 68 | 69 | Persistent identities can help give users continuity and trust in who they're 70 | talking to. It also encourages healthy competition between clients that 71 | implement the protocol, as it's more difficult to lock users into 72 | a specific provider. 73 | 74 | ### References & Where to Learn More 75 | 76 | - [Keybase seitan tokens](https://keybase.io/docs/seitan) 77 | -------------------------------------------------------------------------------- /patterns/persistent-identity/persistent-identity-keybase.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/persistent-identity/persistent-identity-keybase.png -------------------------------------------------------------------------------- /patterns/persistent-identity/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | -------------------------------------------------------------------------------- /patterns/physical-beacon/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | -------------------------------------------------------------------------------- /patterns/physical-beacon/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Physical Beacon 3 | topic: sync-status 4 | description: "Control the physical location of data." 5 | tags: 6 | - ui 7 | --- 8 | 9 | ### The Design Problem 10 | 11 | In a centralized world, you must trust that your provider is managing 12 | access and resiliency across the world. Hosting giants have made this 13 | relatively easy for the vast majority of cases. However, the choice of provider 14 | (e.g., Cloudflare, Amazon, or Google) can dictate the policies and terms of use 15 | of data, based on where the user lives. 16 | 17 | For example, in Fall 2019, a change in export law required that US companies 18 | block users connecting from [certain countries](https://techcrunch.com/2019/07/29/github-ban-sanctioned-countries). 19 | Without warning, some US companies effectively cut off account access for 20 | people connecting from these regions. Companies also give data to authorities 21 | – for example, [Yahoo! collaborated with 22 | China](https://www.theguardian.com/world/2013/sep/08/chinese-activist-yahoo-email-freed) 23 | to incriminate political dissidents in 2005. These acts set a dangerous 24 | precedent, where knowledge can disappear, becoming inaccessible permanently, or 25 | be shared with third parties without warning. This is a power 26 | dynamic that creates information security vulnerabilities and is especially 27 | dangerous for vulnerable populations with sensitive information. 28 | 29 | In a decentralized world, users can choose their provider, and where their data 30 | is stored. However, it isn't always clear how or why to make this choice, and 31 | how best to offer this choice to users. 32 | 33 | ### The Design Solution 34 | 35 | A physical beacon is as an 'always-on node' that operates in a particular 36 | jurisdiction. In peer-to-peer and federated contexts, there could be many 37 | physical beacons that are synchronizing and backing up the data on the internet. 38 | 39 | It is good for grasping a concrete aspect of the network for those who might 40 | not understand the conceptual aspect of it. 41 | 42 | Use this in conjunction with [[Network Health 43 | Indicator]] to show which physical beacons are 44 | currently online. Include concrete information about these locations, such as 45 | their IP address, city, country, provider name (e.g., URL), and latency. 46 | 47 | ### Examples 48 | 49 | ::: examples 50 | 51 | - [![Physical Beacon in Holo](physical-beacon-holo.png) Holo is a box 52 | comparable in size to a home router](physical-beacon-holo.png) 53 | 54 | - [![Physical Beacon in Syncthing](physical-beacon-syncthing.png) One of syncthing's primary functions is to add a remote device](physical-beacon-syncthing.png) 55 | 56 | ::: 57 | 58 | ### Why Choose Physical Beacon? 59 | 60 | - When users want to control the physical location of their data. 61 | 62 | ### Best Practice: How to Implement Physical Beacon 63 | 64 | - Show users when data has been replicated fully to at least one physical beacon. This helps them know when they are able to shut off their device. 65 | - It should be easy to manage active beacons and transfer data from one beacon to another through a user interface. 66 | - Make an easy "out-of-the-box" setup experience for new physical beacons. 67 | - Hosting fees to beacon operators can help sustain infrastructure when users 68 | do not want to setup and maintain the beacon themselves. 69 | 70 | ### Potential Problems with Physical Beacon 71 | 72 | Physical Beacon can expose a new attack surface or become a point of failure. 73 | To avoid this, consider using end-to-end encryption and synchronize with beacons 74 | in multiple locations. 75 | 76 | ### The Take-Away 77 | 78 | Physical Beacon can be useful when it's important that data is stored in 79 | a particular physical location (or many physical locations) for improved data 80 | resiliency & archiving capabilities. 81 | 82 | ### References & Where to Learn More 83 | 84 | -------------------------------------------------------------------------------- /patterns/physical-beacon/physical-beacon-holo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/physical-beacon/physical-beacon-holo.png -------------------------------------------------------------------------------- /patterns/physical-beacon/physical-beacon-syncthing.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/physical-beacon/physical-beacon-syncthing.png -------------------------------------------------------------------------------- /patterns/physical-beacon/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | -------------------------------------------------------------------------------- /patterns/prioritize-backup/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | -------------------------------------------------------------------------------- /patterns/prioritize-backup/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Prioritize Backup 3 | tags: 4 | - protocol 5 | topic: moderation-curation 6 | description: "Prioritizing backup is crucial for competing with centralized services that provide long-term storage." 7 | --- 8 | 9 | ### The Design Problem 10 | 11 | In a centralized application, it is assumed that the owner will prioritize backing up all your data. If there was some natural disaster at one of Google's data centers, for example, they have a variety of backups of your data in various locations around the world. 12 | 13 | In a decentralized application, we have no guarantee that data will be replicated to other locations. In fact, for some use cases, this user agency and control over who has access to their data is a feature, not a bug. But if users expect long-term storage across the world's data centers, your app needs to provide timely information about status and availability. 14 | 15 | ### The Design Solution 16 | 17 | Prioritize backing up all data in multiple locations, ideally across the world. Tell the user when data has been synchronized to long-term storage locations. Pair this with [[Network Health Indicator]] for more fine-grained information about where data is synchronized. 18 | 19 | ### Examples 20 | 21 | - Status.im 22 | - IPFS 23 | - Aether 24 | 25 | ### Why Choose Prioritize Backup? 26 | 27 | When users depend upon long-term storage of their data. 28 | 29 | ### Best Practice: How to Implement Prioritize Backup 30 | 31 | - It can be more useful for static data (i.e., data that doesn't change). 32 | - Trust needs to be established among any partner organizations beforehand to ensure a resilient backup network. 33 | - Make sure to communicate about the community-owned infrastructure up-front. 34 | - If possible, encrypt data before backup so that it is not readable by the storage providers. 35 | 36 | ### Potential Problems with Prioritize Backup 37 | 38 | - Without encryption, users could be subject to attacks. Be sure to communicate when unencrypted data will be stored and readable by others. 39 | - Prioritize backup can be too technical. Hide advanced metrics and show users simple indicators for canceled, paused, in progress, completed, and error. 40 | - It could be difficult to delete data if there are many storage providers or peers on the network. 41 | 42 | ### The Take-Away 43 | 44 | Prioritizing backup is crucial for competing with centralized services that provide long-term storage. 45 | -------------------------------------------------------------------------------- /patterns/prioritize-backup/prioritize-backup-status.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/prioritize-backup/prioritize-backup-status.png -------------------------------------------------------------------------------- /patterns/prioritize-backup/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | -------------------------------------------------------------------------------- /patterns/protocol-agnosticism/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Protocol Agnosticism 3 | topic: sync-status 4 | tags: 5 | - protocol 6 | description: "Give options for which relevant protocols to use." 7 | layout: pattern 8 | --- 9 | 10 | ### The Design Problem 11 | 12 | Two computers connect directly to each other to exchange using information by using a protocol. Protocols have different strengths and weaknesses for particular use cases. 13 | 14 | When an application needs to support a variety of user needs and personas, it can limit usability to only support one protocol. Decentralized applications that support multiple protocols for different scenarios need to know when and where within the user interface to expose those choices. 15 | 16 | ### The Design Solution 17 | 18 | Give users the option to choose a protocol as their default communication method for their given profile. Offer explanatory in-app tutorials to help users understand which choices are the best for them. 19 | 20 | ### Examples 21 | 22 | ::: examples 23 | 24 | - [![Email](protocol-agnosticism-email.png) Email clients require users to choose either POP or IMAP.](protocol-agnosticism-email.png) 25 | 26 | - [![Adium](protocol-agnosticism-adium.png) Adium allows users to select from a variety of different chat applications.](protocol-agnosticism-adium.png) 27 | 28 | - [![Brave](protocol-agnosticism-brave.png) Brave offers a 'New Private Window with Tor' option ](protocol-agnosticism-brave.png) 29 | 30 | ::: 31 | 32 | ### Why Choose Protocol Agnosticism? 33 | 34 | Use Protocol Agnosticism if you are supporting a large user base with varied preferences and requirements. 35 | 36 | ### Best Practice: How to Implement Protocol Agnosticism 37 | 38 | - The default protocol should reflect what the majority of your users expect it to be, or what behavior the application is expected to exhibit. This can be confirmed through user testing and prototyping. 39 | 40 | - Offer in-app help text that explicitly states a scenario or user story in which one protocol may be useful over another. For example, "IMAP is better if you are going to be accessing your email from multiple devices, such as a work computer and a smart phone. POP3 works better if you are only using one device, but have a very large number of emails." ([source](https://www.name.com/support/articles/205935497-Understanding-the-difference-between-POP-and-IMAP)) 41 | 42 | ### Potential Problems with Protocol Agnosticism 43 | 44 | It can be difficult for most users to fully grasp the ramifications of their protocol choices. 45 | 46 | ### The Take-Away 47 | 48 | Protocol agnosticism is a step toward real interoperability. 49 | -------------------------------------------------------------------------------- /patterns/protocol-agnosticism/protocol-agnosticism-adium.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/protocol-agnosticism/protocol-agnosticism-adium.png -------------------------------------------------------------------------------- /patterns/protocol-agnosticism/protocol-agnosticism-brave.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/protocol-agnosticism/protocol-agnosticism-brave.png -------------------------------------------------------------------------------- /patterns/protocol-agnosticism/protocol-agnosticism-email.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/protocol-agnosticism/protocol-agnosticism-email.png -------------------------------------------------------------------------------- /patterns/protocol-agnosticism/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | -------------------------------------------------------------------------------- /patterns/secret-sharing/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | -------------------------------------------------------------------------------- /patterns/secret-sharing/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Secret Sharing 3 | tags: 4 | - protocol 5 | topic: sharing-permissions 6 | description: "Backup your keys and other secrets with your trusted peers." 7 | --- 8 | 9 | ## The Design Problem 10 | 11 | Managing your "secrets" (like keys and passwords) is hard! If they are saved only on 12 | a single device, they are highly secure because someone must gain possession of 13 | your device to get your secrets. But these secrets can be gone forever if the 14 | device is lost or stolen, so this approach can be highly risky. If your secrets are uploaded to 15 | a server owned by another person, company, or organization, it's highly 16 | available anywhere even if you lose your device. But it is possible that an 17 | attacker or rogue employee may lose, corrupt, or misuse it (intentionally or 18 | unintentionally). 19 | 20 | Thus, gaining trust thus has become an important part of marketing strategies 21 | for many Internet companies today that store your important information. This 22 | is why many companies focus on creating a social, friendly, and trusted image 23 | in their brand. 24 | 25 | ## The Design Solution 26 | 27 | Because trust is inherently social, we can also model secret management in a social 28 | way. Secret sharing allows you to share your secret with a number of 29 | people - friends, family members, or any organization you place your trust in! 30 | 31 | If you lose your original secret, these people (peers) could choose to come together to 32 | recreate your secret for you. Secret sharing is also known as "sharding" -- think about breaking up a secret 33 | into different shards, spread across a number of peers. Thanks to some mathematical magic (cryptography!) no 34 | single peer can recreate your secret with their shard. This prevents a single attacker or rogue 35 | employee from stealing your secret, as they would need to coordinate with 36 | a number of your peers to unlock the secret. 37 | 38 | 39 | ## Examples 40 | 41 | ::: examples 42 | 43 | - [![Dark Crystal demo](secret-history-screenshot.png) Dark Crystal in Secure Scuttlebutt](secret-history-screenshot.png) 44 | 45 | ::: 46 | 47 | ## Why Choose Secret Sharing? 48 | 49 | Secret sharing is great in a scenario where users have to maintain a single secret across all of their 50 | devices, and losing that secret can be catastrophic. For example, in 51 | applications that manage sensitive information such as money, personally 52 | identifying information, or encrypted documents. 53 | 54 | ## Best Practice: How to Implement Secret Sharing 55 | 56 | Allow users to choose a minimum number of peers that need to come together to 57 | re-create the secret. The number of peers can be small, as little as two. Most 58 | users may not need more than two or three peers to have a high guarantee of 59 | security and usability. 60 | 61 | Despite only needing two or more peers to use secret sharing, it's important 62 | that more peers are included just in case something goes wrong with a peer. For 63 | example, recommend that the user create at least three shards with two minimum 64 | peers, or five shards with at least three minimum peers. This way, if one of 65 | the peers is unable or unwilling to participate at a later date, the secret 66 | won't be lost. 67 | 68 | ## Potential Problems with Secret Sharing 69 | 70 | The simplest way to implement secret sharing likely requires the users to 71 | distribute the secret shards to peers themselves in an ad-hoc manner. There 72 | are three significant problems: 73 | 74 | 1. The shard could be stolen by an unauthorized third-party. 75 | 2. The shard could be lost by the intended recipient. 76 | 3. The shard could be rendered invalid because one of the peers went rogue. 77 | 78 | The shard distribution workflow could be automated through a user interface on 79 | the application to make it easier for users to create, send, and revoke keys 80 | over encrypted channels, but that is not always an easy task for development 81 | teams to build and deploy. 82 | 83 | ## The Take Away 84 | 85 | Secret Sharing is a protocol that models trust in a social and distributed fashion. 86 | 87 | ## References & Where to Learn More 88 | 89 | [Dark Crystal](https://darkcrystal.pw/what-is-secret-sharing/) 90 | -------------------------------------------------------------------------------- /patterns/secret-sharing/secret-history-screenshot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/secret-sharing/secret-history-screenshot.png -------------------------------------------------------------------------------- /patterns/secret-sharing/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | -------------------------------------------------------------------------------- /patterns/social-radius-slider/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | -------------------------------------------------------------------------------- /patterns/social-radius-slider/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Social Radius Slider 3 | topic: moderation-curation 4 | description: "Control information overload in large networks." 5 | tags: 6 | - ui 7 | --- 8 | 9 | ### The Design Problem 10 | 11 | Social networks are mentally taxing. Sometimes news from around the world is inspiring, other times it is just depressing. Sometimes you want to hear from 12 | strangers, other times you just want posts from your closest friends and 13 | family. Wanting to pro-actively manage your feed requires a lot of overhead. 14 | 15 | ### The Design Solution 16 | 17 | Use a radius to indicate how "big" your circle is today. 18 | 19 | ### Examples 20 | 21 | ::: examples 22 | 23 | - [![Social Radius Slider in SSB](patchbay.png) Patchbay presents choices horizontally](patchbay.png) 24 | 25 | - [![Social Radius Slider in Gather.town](social-radius-slider-gathertown.png) Gathertown radius displayed as a circle](social-radius-slider-gathertown.png) 26 | 27 | 28 | ::: 29 | 30 | ### Why Choose Social Radius Slider? 31 | 32 | When you have a social network that can be potentially large but doesn't always 33 | need to be. When you are using a protocol that has gossip or federation 34 | built-in, and you want to give the user option to participate in smaller common spaces as well as larger ones. 35 | 36 | ### Best Practice: How to Implement Social Radius Slider 37 | 38 | Social Radius Slider is a temporary filter and doesn't have to be persistent. 39 | It allows users to control and extend their network as well as to moderate 40 | their data consumption. 41 | 42 | ### Potential Problems with Social Radius Slider 43 | 44 | Users will expect different behaviors based on a 'large' or 'small' radius. 45 | 46 | Do research on your target user base to understand what the default setting 47 | should be, as many users do not change default settings. 48 | 49 | ### The Take-Away 50 | 51 | Social radius slider helps users control information overload in otherwise 52 | large networks. 53 | 54 | ### References & Where to Learn More 55 | 56 | Thanks to cinnamon for this idea! 57 | -------------------------------------------------------------------------------- /patterns/social-radius-slider/patchbay.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/social-radius-slider/patchbay.png -------------------------------------------------------------------------------- /patterns/social-radius-slider/social-radius-slider-gathertown.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/social-radius-slider/social-radius-slider-gathertown.png -------------------------------------------------------------------------------- /patterns/social-radius-slider/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | -------------------------------------------------------------------------------- /patterns/standards-marker/deltachat.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/standards-marker/deltachat.png -------------------------------------------------------------------------------- /patterns/standards-marker/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | -------------------------------------------------------------------------------- /patterns/standards-marker/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Standards Marker 3 | topic: sharing-permissions 4 | description: "Quickly find and open files that are related to your application." 5 | tags: 6 | - ui 7 | --- 8 | 9 | ### The Design Problem 10 | 11 | Decentralized applications prioritize portability. In other words, data is not tied to one centralized location and should be easily moved between installations, devices, or instances. Although beneficial for many use cases, this feature poses usability challenges when exporting and importing data. 12 | 13 | ### The Design Solution 14 | 15 | When exporting data, such as keys or backups, from the application, ensure that the file has a distinguishable and noticeable file extension (e.g., docx or zip). Instead, use the name of your application, or some other name that is unique to your application. 16 | 17 | ### Examples 18 | 19 | ::: examples 20 | 21 | - [![Standards Marker in Mapeo](mapeo.jpeg) Mapeo users can export and import 'mapeosettings' file to share a project between peers](mapeo.jpeg) 22 | 23 | - [![Delta Chat](deltachat.png) Delta.Chat exports to a 'bak' file with the current date](deltachat.png) 24 | 25 | ::: 26 | 27 | ### Why Choose Standards Marker? 28 | 29 | When there are sharable or backup files. 30 | 31 | ### Best Practice: How to Implement Standards Marker 32 | 33 | - In the import/open dialog, filter the results in the file picker to only show files with your app's standard extension. 34 | - Make sure that your chosen file extension is unique enough that it is not used by another program. 35 | - Version your file format internally (either using a zip file or some initial byte string) so that you can make changes to the format if necessary. 36 | 37 | ### Potential Problems with Standards Marker 38 | 39 | If you're using a common file format, like sql or zip, it won't be immediately obvious. Include in your help desk and documentation a clear description of what your file format contains and how to use it outside of the application. 40 | 41 | ### The Take-Away 42 | 43 | Standards marker helps users quickly find and open files that are related to your application. 44 | -------------------------------------------------------------------------------- /patterns/standards-marker/mapeo.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/standards-marker/mapeo.jpeg -------------------------------------------------------------------------------- /patterns/standards-marker/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | -------------------------------------------------------------------------------- /patterns/tombstones/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | -------------------------------------------------------------------------------- /patterns/tombstones/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Tombstones 3 | topic: moderation-curation 4 | description: "Protect privacy & safety through networked deletion" 5 | tags: 6 | - protocol 7 | --- 8 | 9 | ### The Design Problem 10 | 11 | User-generated content may be available forever on some devices; and thus, it's difficult to delete all copies on all other devices. This is more likely the longer this content is online, as crawlers will begin to find it, copy it, and give it to other people. 12 | 13 | This deletion problem is not just a decentralization issue. In centralized applications, any conversation could be saved as screenshots or as raw data, long after the original account deleted the information. Thus, it is already very difficult to delete content from the Web once it has been shared. 14 | 15 | In a decentralized application, deletion gets even harder, because we can't just ask a single, central database to delete all references to the data -- instead, we have to ask many databases or devices to delete their copies. 16 | 17 | ### The Design Solution 18 | 19 | We can encourage deletion across the network quite well by using Tombstones. A tombstone is a message that says "Please, delete the information with the following identification numbers." These tombstone messages can be sent to everyone or only certain devices or servers, depending on the use case. 20 | 21 | ### Examples 22 | 23 | ::: examples 24 | 25 | - [![Tombstones in Mapeo](mapeo.png) Mapeo has a delete feature which hides items from view](mapeo.png) 26 | 27 | ::: 28 | 29 | ### How to best implement 30 | 31 | - When a message is deleted, show users if the content is still available somewhere on the network (e.g., it could be that some client is not respecting the message). 32 | - Some clients may not respect tombstones, give users visibility into this and allow blocking replication with those clients. 33 | - Allow 'reversing' tombstones, that is, a tombstone should be a boolean value that can be turned off or on in the future. 34 | 35 | ### Why Choose Tombstones? 36 | 37 | When you want to protect the safety and privacy of users. 38 | 39 | ### Potential Problems with Tombstones 40 | 41 | It won't always be clear that content won't be deleted immediately from the network. It can take time before the tombstone message is sent to other devices. 42 | 43 | Depending on the protocol or library you choose for storage, it may not be possible to delete historical data. In this case, tombstones only 'hide' data from view, rather than delete it from disk. 44 | 45 | ### References & Where to Learn More 46 | 47 | Network "[heartbeats]()" can track which peers with a copy of data continue to share it after a tombstone has been sent. See [[network health indicator]] for more on this approach. 48 | -------------------------------------------------------------------------------- /patterns/tombstones/mapeo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/tombstones/mapeo.png -------------------------------------------------------------------------------- /patterns/tombstones/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | -------------------------------------------------------------------------------- /patterns/trackers/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | -------------------------------------------------------------------------------- /patterns/trackers/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Trackers 3 | topic: sync-status 4 | tags: 5 | - protocol 6 | description: "Trackers can facilitate introduction in peer-to-peer networks." 7 | --- 8 | 9 | ### The Design Problem 10 | 11 | On centralized social networks, users can identify content and peers relevant to their own interests and "follow" or "subscribe" to the content. The platform provides the supporting infrastructure to connect with peers and browse available content. 12 | 13 | This is not always true in peer-to-peer systems. Once a user found peers offering relevant content, they can ask those peers for contact information for adjacent peers, and connect to a larger portion of the network - but finding the initial "introduction" peers is a complicated challenge. 14 | 15 | ### The Design Solution 16 | 17 | Create centralized "tracker" servers to introduce peers. These trackers have 18 | well known domain names or IP addresses so they can be easily found 19 | by users, and may even have their addresses included in client software. 20 | 21 | Trackers are a database of content and the contact information (i.e., IP 22 | address) all for devices that have that content. This contact information may contain 23 | additional metadata about the peer's bandwidth and supported functionality. 24 | 25 | ### Examples 26 | 27 | ::: examples 28 | 29 | - [![BitTorrent](trackers-bittorrent.jpeg) 'Trackers' in BitTorrent](trackers-bittorrent.jpeg) 30 | - [![Tor](trackers-tor.png) 'Directory Authorities' in Tor use consensus to 31 | stay up-to-date](trackers-tor.png) 32 | - [![IPFS Bootstrap Peers](trackers-ipfs.png) Kademlia Distributed Hash Tables, like the 33 | one in IPFS, offer "bootstrap peers"](trackers-ipfs.png) 34 | 35 | ::: 36 | 37 | ### Why Choose Trackers? 38 | 39 | Trackers are a simple technique to solve "first introduction" problems in peer-to-peer systems, provide a natural solution to NAT traversal, and can serve as a bootstrapping step to add clients to a more decentralized network like a distributed hash table. If you want to provide more reliable service for unpopular content, use a [[Discovery Server]] which acts as a backup location in addition to tracking content. 40 | 41 | ### Best Practice: How to Implement Trackers 42 | 43 | - Include multiple redundant trackers in content links (such as torrent files or magnet links) or hardcoded in client software 44 | - Have clients periodically re-submit their contact information to trackers to indicate continual interest in content 45 | - Trackers may prune contact information after an age threshold, or their may include the last "check-in date" with any contact information to allow clients to make pruning decisions on their own 46 | 47 | ### Potential Problems with Trackers 48 | 49 | - Centralized trackers make surveillance easier and introduce a small number of critical hubs that can be disrupted to prevent new clients from joining a network 50 | - By default, trackers can read any contact information supplied to them, and so can identify the number of peers interested in an identifier and their contact information 51 | - Mitigate this vulnerability by encrypting the contact information before submitting it to a tracker, and using a derived hash of the encryption key as a tracker identifier, so interested peers will be able to read the peer contact data 52 | - Trackers only solve discovery of peers based on a shared content, but do _not_ necessarily facilitate discovery of new content. 53 | - Content identifiers must be shared beforehand, so trackers do not completely solve content discovery. 54 | 55 | ### The Take Away 56 | 57 | Trackers are a common component of many peer-to-peer networks, and facilitate peer introduction. 58 | 59 | ### References & Where to learn more 60 | 61 | Even once relevant peers are identified by a tracker, creating a peer-to-peer network connection between two home networks requires [NAT traversal](https://en.wikipedia.org/wiki/NAT_traversal), also referred to as NAT hole punching. This usually involves utilizing a third party to exchange network address and port information to facilitate a direct connection. 62 | 63 | IPFS illustration by [Matt 64 | Ober](https://medium.com/pinata/speeding-up-ipfs-pinning-through-swarm-connections-b509b1471986) 65 | -------------------------------------------------------------------------------- /patterns/trackers/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | -------------------------------------------------------------------------------- /patterns/trackers/trackers-bittorrent.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/trackers/trackers-bittorrent.png -------------------------------------------------------------------------------- /patterns/trackers/trackers-ipfs.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/trackers/trackers-ipfs.png -------------------------------------------------------------------------------- /patterns/trackers/trackers-tor.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/trackers/trackers-tor.png -------------------------------------------------------------------------------- /patterns/village-or-city/aether.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/village-or-city/aether.png -------------------------------------------------------------------------------- /patterns/village-or-city/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | -------------------------------------------------------------------------------- /patterns/village-or-city/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Village or City 3 | topic: moderation-curation 4 | tags: 5 | - ui 6 | description: "Set clear expectations around the kinds of social interactions you want to see." 7 | --- 8 | 9 | ### The Design Problem 10 | 11 | When building a new platform (e.g., a social network), it is hard to make design decisions about features and workflows that fit a variety of users, use cases, and contexts. Decentralized technologies often want to be "forked" and implemented by many different and vibrant communities. This means that there won't be a unifying way to describe user groups and their needs, and the design process can feel "stuck". 12 | 13 | ### The Design Solution 14 | 15 | Instead of thinking specifically about user groups and their needs, consider the feeling or atmosphere you want to create. 16 | What kinds of interactions do you want to see? If it’s more like a village, you'll have 17 | close connections with everyone you talk to. Think of a texting app, or an 18 | invite-only chat room. If it's more like a city (think Twitter), your users will have more 19 | interactions with strangers. 20 | 21 | Some users will want to be in a village in certain contexts; but some 22 | communities may want to feel more like cities. Making sure your assumptions 23 | about village or city is built into your platform will help users understand 24 | the kinds of interactions that are possible and appropriate. Consider patterns 25 | like [[cautious optimism]] to allow users to opt-in to 26 | discovering new users safely. 27 | 28 | If you envision a city-like platform, make posts public and anonymous by default - people are used to random and rude behavior in cities. But if you are building a village-like platform, people will expect posts to be shared within a smaller and safer group. 29 | 30 | This aspect also affects community growth. For example, communities that are invite-only will feel more like villages. The more 31 | controls you create around who is allowed to issue invites (e.g., only 32 | moderators/admins or everyone) will further restrict community growth. Give users and moderators clear controls on how to grow their communities. 33 | Utilize patterns like [[social radius slider]] 34 | and [[content curators]] to give fine-grained control over 35 | social feeds. 36 | 37 | ### Examples 38 | 39 | 40 | ::: examples 41 | 42 | - [![Mastodon](mastodon.png) Mastodon can be 43 | configured as invite-only](mastodon.png) 44 | 45 | - [![Aether](aether.png) Aether users vote and impeach moderators similar to a democratic city government](aether.png) 46 | 47 | ::: 48 | 49 | ### Why Choose Village or City? 50 | 51 | When you are building an application that relies heavily on social interaction. 52 | 53 | ### Best Practice: How to Implement Village or City 54 | 55 | - Guidelines and parameters regarding community size and interactive elements 56 | must be communicated clearly. 57 | 58 | ### Potential Problems with Village or City 59 | 60 | It can cause more cognitive load to have more choices in moderation, 61 | community interaction, and growth. Decide on where you fall on the "Village or City?" spectrum and make consistent design decisions throughout. 62 | Create default settings or an in depth onboarding flow that helps moderators and users understand what the 63 | implications are for community openness, public visibility, and invitation rules. 64 | 65 | ### The Take-Away 66 | 67 | Users will feel more grounded and active on your platform when community 68 | boundaries are clear and aligned with what they are looking for. 69 | 70 | ### References & Where to Learn More 71 | 72 | [Run Your Own Social](https://runyourown.social/) 73 | -------------------------------------------------------------------------------- /patterns/village-or-city/mastodon.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/village-or-city/mastodon.png -------------------------------------------------------------------------------- /patterns/village-or-city/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | -------------------------------------------------------------------------------- /patterns/visual-hash/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | -------------------------------------------------------------------------------- /patterns/visual-hash/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Visual Hash 3 | topic: sharing-permissions 4 | tags: 5 | - ui 6 | description: "Quickly differentiate between two users or pieces of content." 7 | layout: pattern 8 | --- 9 | 10 | ### The Design Problem 11 | 12 | Differentiating between users on a social network scales in difficulty with the 13 | amount of information. To quickly discern the difference between one person and 14 | another; or one piece of content from another, we use icons or pictures. Often 15 | this can be solved by choosing or uploading a photo as a profile picture, or 16 | using a thumbnail version of the content. 17 | 18 | However, when neither of these are available, it's difficult to tell content or 19 | users a part quickly. 20 | 21 | ### The Design Solution 22 | 23 | Generate an image based upon the hash of the content or the ID of 24 | the user. 25 | 26 | ### Examples 27 | 28 | ::: examples 29 | 30 | - [![Visual hash in Cabal](visual-hash-cabal.png) Cabal's visual hash format](visual-hash-cabal.png) 31 | - [![Visual hash in Cabal](visual-hash-github.png) Github uses colors as well as patterns](visual-hash-github.png) 32 | - [![Visual hash in Radicle](visual-hash-radicle.png) Radicle's visual hashes don't look like QR codes](visual-hash-radicle.png) 33 | 34 | ::: 35 | 36 | ### Why Choose Visual Hash? 37 | 38 | When you need a default image to quickly differentiate between two users or pieces 39 | of content. 40 | 41 | ### Best Practice: How to Implement Visual Hash 42 | 43 | This image should have high enough entropy to cover the elements that would be 44 | visible in a typical user's social network (e.g., 1000 items). 45 | 46 | ### Potential Problems with Visual Hash 47 | 48 | - It often isn't a great proxy for the actual user or the content. Use visual 49 | nudges to remind the user to choose an image. 50 | - Color blindness could be an issue in differentiating two visual hashes from 51 | each other. Ensure that the visual hash uses two colors that can be seen by all users. 52 | 53 | ### The Take-Away 54 | 55 | Visual hash is a good default image picker that helps you differentiate between users or content. 56 | -------------------------------------------------------------------------------- /patterns/visual-hash/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | -------------------------------------------------------------------------------- /patterns/visual-hash/visual-hash-cabal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/visual-hash/visual-hash-cabal.png -------------------------------------------------------------------------------- /patterns/visual-hash/visual-hash-github.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/visual-hash/visual-hash-github.png -------------------------------------------------------------------------------- /patterns/visual-hash/visual-hash-radicle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/visual-hash/visual-hash-radicle.png -------------------------------------------------------------------------------- /patterns/whisper-links/illustration.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | -------------------------------------------------------------------------------- /patterns/whisper-links/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Whisper Links 3 | topic: sharing-permissions 4 | tags: 5 | - ui 6 | - protocol 7 | description: "Share resources quickly between two trusted users." 8 | --- 9 | 10 | ### The Design Problem 11 | 12 | In a peer-to-peer application, two devices are able to connect their computers 13 | and share content directly. However, stabilizing that initial connection can be 14 | challenging. 15 | 16 | ### The Design Solution 17 | 18 | One user creates a code that can be shared with the other easily using another 19 | communication channel. The code should be short and human-pronounceable, using 20 | a phonetically-distinct word list. 21 | 22 | Consider using a URI protocol handler link (e.g., myapp://) so that 23 | when clicked on, your application will automatically open. 24 | 25 | ### Examples 26 | 27 | ::: examples 28 | 29 | - [![Whisper links in Magic Wormhole](whisper-links-magicwormhole.png) Magic Wormhole automatically generates pronounceable phrases](whisper-links-magicwormhole.png) 30 | 31 | - [![Whisper links in Jitsi](whisper-links-jitsi.png) Jitsi allows users to choose a phrase](whisper-links-jitsi.png) 32 | 33 | - [![Whisper links in Briar](whisper-links-briar.png) Briar's phrases are cryptographicly secure but unpronounceable](whisper-links-briar.png) 34 | 35 | ::: 36 | 37 | ### Why Choose Whisper Links? 38 | 39 | When you want to establish a connection between two users for common use cases 40 | where there is a human-mediated communication channel (such as text, chat, or 41 | phone call) already in progress. 42 | 43 | ### Best Practice: How to Implement Whisper Links 44 | 45 | If using a word list, localize it. In other words, use a word list language that 46 | is the same as the user's chosen language. 47 | 48 | Allow users to create their own whisper links. 49 | 50 | Consider only allowing a certain number of failed attempts to protect against spammers and brute-force attacks. See [password-authenticated key agreement](https://en.wikipedia.org/wiki/Password-authenticated_key_agreement) for more implementation details. 51 | 52 | This could be used in conjunction with [[QR code verification]] if two users are able to share an image or 53 | are in the same physical location. 54 | 55 | ### Potential Problems with Whisper Links 56 | 57 | Use longer lengths for higher security use cases and shorter lengths for 58 | links intended to be publicly accessible. The longer the code, the less likely 59 | it is that an attacker could randomly guess the whisper link and connect to 60 | an unauthorized computer. However, longer links may be more difficult to copy 61 | and remember. 62 | 63 | When users are able to choose their own whisper links, it's possible they will 64 | choose names that are easy to guess. Consider implementing a "bad meeting name 65 | detector" which tells users when their link could be hijacked by an suspicious 66 | third-party attacker. 67 | 68 | ### The Take-Away 69 | 70 | Whisper Links make it easy to share information quickly between two trusted users. 71 | 72 | ### References & Where to Learn More 73 | 74 | [What Three Words](https://what3words.com/about-us-old/) maps every 3x3m location on earth to three words! This is how powerful three words alone can be. 75 | -------------------------------------------------------------------------------- /patterns/whisper-links/thumbnail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | -------------------------------------------------------------------------------- /patterns/whisper-links/whisper-links-briar.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/whisper-links/whisper-links-briar.png -------------------------------------------------------------------------------- /patterns/whisper-links/whisper-links-jitsi.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/whisper-links/whisper-links-jitsi.png -------------------------------------------------------------------------------- /patterns/whisper-links/whisper-links-magicwormhole.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sprblm/dots-patterns/9faf44690612fb1113d15cca652f6144ad3c71e3/patterns/whisper-links/whisper-links-magicwormhole.png -------------------------------------------------------------------------------- /topics/identity-agency.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: topic 3 | title: Identity & Agency 4 | slug: identity-agency 5 | --- 6 | 7 | In a centralized application, the concept of “who am I” is coordinated by a single authoritative database. In decentralized applications, by contrast, user “accounts” may not exist, or they might get verified in a variety of ways. The patterns in this category help bring clarity to users dealing with questions of how to best manage their own online identity and credentials as well as those of other people. 8 | -------------------------------------------------------------------------------- /topics/moderation-curation.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: topic 3 | title: Moderation & Curation 4 | slug: moderation-curation 5 | --- 6 | 7 | Information overload, spam, and abuse can be serious problems for decentralized applications that allow strangers to interact with each other directly. The patterns in this category therefore deal primarily with applications where content and users are publicly discoverable. By integrating the patterns, applications will be more useful to a wider set of communities, and will help keep vulnerable people safer from online abuse. 8 | -------------------------------------------------------------------------------- /topics/sharing-permissions.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: topic 3 | title: Sharing & Permissions 4 | slug: sharing-permissions 5 | --- 6 | 7 | Most decentralized applications share everything publicly by default. This default assumption, however, can risk limiting use cases as well as user trust in the application (thereby also reducing adoption). The patterns in this category help build trust with the application by providing methods for users to decide who sees what, and when. 8 | -------------------------------------------------------------------------------- /topics/sync-status.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: topic 3 | title: Sync & Status 4 | slug: sync-status 5 | --- 6 | 7 | Decentralized applications aren’t always connected to a single server that is the source of truth for all information. This can lead to hard problems around resolving data conflicts, finding peers, and deciding on common standards. The patterns in this category help users understand where data is available, how it is synced across devices, and whether it is discoverable. 8 | -------------------------------------------------------------------------------- /topics/topics.11tydata.js: -------------------------------------------------------------------------------- 1 | module.exports = { 2 | layout: "topic", 3 | tags: "topic", 4 | eleventyComputed: { 5 | // All patterns that have a `topic` property equal to a topic's 6 | // `slug` belong to that topic's patterns. 7 | patterns: (data) => 8 | data.collections.patternsByTitle.filter( 9 | (p) => p.data.topic === data.slug 10 | ), 11 | }, 12 | }; 13 | --------------------------------------------------------------------------------