├── .gitignore ├── whitepaper ├── dsnp_whitepaper.pdf ├── figures │ ├── Cost Shifting.png │ ├── SaaS Ecosystem.png │ ├── Graph Change Events.png │ ├── Example Batch Process.png │ ├── Batch Message Structure.png │ ├── Key Storage and Retrieval.png │ ├── Message Types and Replies.png │ ├── Announcement Metadata Structure.png │ ├── Social Identity Ownership Structure.png │ └── DDID Flow For Alice with Two Associates.png ├── .gitignore ├── Makefile ├── biblio.bib └── dsnp_whitepaper.tex ├── README.md ├── CODE_OF_CONDUCT.md └── LICENSE.md /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | -------------------------------------------------------------------------------- /whitepaper/dsnp_whitepaper.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LibertyDSNP/papers/HEAD/whitepaper/dsnp_whitepaper.pdf -------------------------------------------------------------------------------- /whitepaper/figures/Cost Shifting.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LibertyDSNP/papers/HEAD/whitepaper/figures/Cost Shifting.png -------------------------------------------------------------------------------- /whitepaper/figures/SaaS Ecosystem.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LibertyDSNP/papers/HEAD/whitepaper/figures/SaaS Ecosystem.png -------------------------------------------------------------------------------- /whitepaper/figures/Graph Change Events.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LibertyDSNP/papers/HEAD/whitepaper/figures/Graph Change Events.png -------------------------------------------------------------------------------- /whitepaper/figures/Example Batch Process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LibertyDSNP/papers/HEAD/whitepaper/figures/Example Batch Process.png -------------------------------------------------------------------------------- /whitepaper/figures/Batch Message Structure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LibertyDSNP/papers/HEAD/whitepaper/figures/Batch Message Structure.png -------------------------------------------------------------------------------- /whitepaper/figures/Key Storage and Retrieval.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LibertyDSNP/papers/HEAD/whitepaper/figures/Key Storage and Retrieval.png -------------------------------------------------------------------------------- /whitepaper/figures/Message Types and Replies.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LibertyDSNP/papers/HEAD/whitepaper/figures/Message Types and Replies.png -------------------------------------------------------------------------------- /whitepaper/figures/Announcement Metadata Structure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LibertyDSNP/papers/HEAD/whitepaper/figures/Announcement Metadata Structure.png -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Project Liberty Papers 2 | 3 | ## Decentralized Social Networking Protocol (DSNP) 4 | 5 | [October 2020 Whitepaper (PDF)](whitepaper/dsnp_whitepaper.pdf) 6 | -------------------------------------------------------------------------------- /whitepaper/.gitignore: -------------------------------------------------------------------------------- 1 | dsnp_whitepaper-blx.bib 2 | dsnp_whitepaper.aux 3 | dsnp_whitepaper.bbl 4 | dsnp_whitepaper.blg 5 | dsnp_whitepaper.log 6 | dsnp_whitepaper.run.xml 7 | -------------------------------------------------------------------------------- /whitepaper/figures/Social Identity Ownership Structure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LibertyDSNP/papers/HEAD/whitepaper/figures/Social Identity Ownership Structure.png -------------------------------------------------------------------------------- /whitepaper/figures/DDID Flow For Alice with Two Associates.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LibertyDSNP/papers/HEAD/whitepaper/figures/DDID Flow For Alice with Two Associates.png -------------------------------------------------------------------------------- /whitepaper/Makefile: -------------------------------------------------------------------------------- 1 | PROJECT=dsnp_whitepaper 2 | TEX=pdflatex 3 | LATEXFLAGS+= -file-line-error -halt-on-error -interaction nonstopmode 4 | BIBTEX=bibtex 5 | BUILDTEX=$(TEX) $(LATEXFLAGS) $(PROJECT).tex 6 | 7 | all: clean 8 | $(BUILDTEX) 9 | $(BIBTEX) $(PROJECT) 10 | $(BUILDTEX) 11 | $(BUILDTEX) 12 | 13 | clean-all: clean 14 | rm -f *.dvi *.ps *.eps *.pdf *.toc 15 | 16 | clean: 17 | rm -f *.log *.bak *.aux *.bbl *.blg *.idx *.toc *.out *~ *.fls *-blx.bib *.run.xml 18 | 19 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | 2 | # Contributor Covenant Code of Conduct 3 | 4 | ## Our Pledge 5 | 6 | We as members, contributors, and leaders pledge to make participation in our 7 | community a harassment-free experience for everyone, regardless of age, body 8 | size, visible or invisible disability, ethnicity, sex characteristics, gender 9 | identity and expression, level of experience, education, socio-economic status, 10 | nationality, personal appearance, race, religion, or sexual identity 11 | and orientation. 12 | 13 | We pledge to act and interact in ways that contribute to an open, welcoming, 14 | diverse, inclusive, and healthy community. 15 | 16 | ## Our Standards 17 | 18 | Examples of behavior that contributes to a positive environment for our 19 | community include: 20 | 21 | * Demonstrating empathy and kindness toward other people 22 | * Being respectful of differing opinions, viewpoints, and experiences 23 | * Giving and gracefully accepting constructive feedback 24 | * Accepting responsibility and apologizing to those affected by our mistakes, 25 | and learning from the experience 26 | * Focusing on what is best not just for us as individuals, but for the 27 | overall community 28 | 29 | Examples of unacceptable behavior include: 30 | 31 | * The use of sexualized language or imagery, and sexual attention or 32 | advances of any kind 33 | * Trolling, insulting or derogatory comments, and personal or political attacks 34 | * Public or private harassment 35 | * Publishing others' private information, such as a physical or email 36 | address, without their explicit permission 37 | * Other conduct which could reasonably be considered inappropriate in a 38 | professional setting 39 | 40 | ## Enforcement Responsibilities 41 | 42 | Community leaders are responsible for clarifying and enforcing our standards of 43 | acceptable behavior and will take appropriate and fair corrective action in 44 | response to any behavior that they deem inappropriate, threatening, offensive, 45 | or harmful. 46 | 47 | Community leaders have the right and responsibility to remove, edit, or reject 48 | comments, commits, code, wiki edits, issues, and other contributions that are 49 | not aligned to this Code of Conduct, and will communicate reasons for moderation 50 | decisions when appropriate. 51 | 52 | ## Scope 53 | 54 | This Code of Conduct applies within all community spaces, and also applies when 55 | an individual is officially representing the community in public spaces. 56 | Examples of representing our community include using an official e-mail address, 57 | posting via an official social media account, or acting as an appointed 58 | representative at an online or offline event. 59 | 60 | ## Enforcement 61 | 62 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 63 | reported to the community leaders responsible for enforcement at 64 | coc@projectliberty.io. 65 | All complaints will be reviewed and investigated promptly and fairly. 66 | 67 | All community leaders are obligated to respect the privacy and security of the 68 | reporter of any incident. 69 | 70 | ## Enforcement Guidelines 71 | 72 | Community leaders will follow these Community Impact Guidelines in determining 73 | the consequences for any action they deem in violation of this Code of Conduct: 74 | 75 | ### 1. Correction 76 | 77 | **Community Impact**: Use of inappropriate language or other behavior deemed 78 | unprofessional or unwelcome in the community. 79 | 80 | **Consequence**: A private, written warning from community leaders, providing 81 | clarity around the nature of the violation and an explanation of why the 82 | behavior was inappropriate. A public apology may be requested. 83 | 84 | ### 2. Warning 85 | 86 | **Community Impact**: A violation through a single incident or series 87 | of actions. 88 | 89 | **Consequence**: A warning with consequences for continued behavior. No 90 | interaction with the people involved, including unsolicited interaction with 91 | those enforcing the Code of Conduct, for a specified period of time. This 92 | includes avoiding interactions in community spaces as well as external channels 93 | like social media. Violating these terms may lead to a temporary or 94 | permanent ban. 95 | 96 | ### 3. Temporary Ban 97 | 98 | **Community Impact**: A serious violation of community standards, including 99 | sustained inappropriate behavior. 100 | 101 | **Consequence**: A temporary ban from any sort of interaction or public 102 | communication with the community for a specified period of time. No public or 103 | private interaction with the people involved, including unsolicited interaction 104 | with those enforcing the Code of Conduct, is allowed during this period. 105 | Violating these terms may lead to a permanent ban. 106 | 107 | ### 4. Permanent Ban 108 | 109 | **Community Impact**: Demonstrating a pattern of violation of community 110 | standards, including sustained inappropriate behavior, harassment of an 111 | individual, or aggression toward or disparagement of classes of individuals. 112 | 113 | **Consequence**: A permanent ban from any sort of public interaction within 114 | the community. 115 | 116 | ## Attribution 117 | 118 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], 119 | version 2.0, available at 120 | [https://www.contributor-covenant.org/version/2/0/code_of_conduct.html][v2.0]. 121 | 122 | Community Impact Guidelines were inspired by 123 | [Mozilla's code of conduct enforcement ladder][Mozilla CoC]. 124 | 125 | For answers to common questions about this code of conduct, see the FAQ at 126 | [https://www.contributor-covenant.org/faq][FAQ]. Translations are available 127 | at [https://www.contributor-covenant.org/translations][translations]. 128 | 129 | [homepage]: https://www.contributor-covenant.org 130 | [v2.0]: https://www.contributor-covenant.org/version/2/0/code_of_conduct.html 131 | [Mozilla CoC]: https://github.com/mozilla/diversity 132 | [FAQ]: https://www.contributor-covenant.org/faq 133 | [translations]: https://www.contributor-covenant.org/translations 134 | 135 | -------------------------------------------------------------------------------- /whitepaper/biblio.bib: -------------------------------------------------------------------------------- 1 | @misc{twitter_verified_accounts, 2 | title = {About verified accounts}, 3 | publisher = {Twitter}, 4 | url = {https://help.twitter.com/en/managing-your-account/about-twitter-verified-accounts}, 5 | } 6 | @misc{ccpa2018, 7 | title = {California Consumer Privacy Act of 2018}, 8 | year = 2018, 9 | publisher = {State of California}, 10 | url = {http://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5}, 11 | } 12 | @misc{gdpr2016, 13 | title = {General Data Protection Regulation}, 14 | year = 2016, 15 | publisher = {Official Journal of the European Union}, 16 | url = {https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679}, 17 | } 18 | @misc{gnosissafe, 19 | title = {Gnosis Safe}, 20 | publisher = {Gnosis Limited}, 21 | url = {https://gnosis-safe.io/}, 22 | } 23 | @misc{whisper-how, 24 | title = {How to Whisper}, 25 | url = {https://geth.ethereum.org/docs/whisper/how-to-whisper}, 26 | } 27 | @misc{lgpd2019, 28 | title = {Lei Geral de Proteção de Dados Pessoais}, 29 | year = 2019, 30 | publisher = {Brazil}, 31 | url = {http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/Lei/L13709.htm}, 32 | } 33 | @misc{metamask_doc, 34 | title = {MetaMask Documentation: RPC API}, 35 | url = {https://docs.metamask.io/guide/rpc-api.html}, 36 | } 37 | @misc{openzeppelin, 38 | title = {OpenZeppelin}, 39 | publisher = {zOS Global Limited}, 40 | url = {https://openzeppelin.com/}, 41 | } 42 | @misc{pirk, 43 | title = {Pirk Proposal}, 44 | publisher = {Apache Software Foundation}, 45 | url = {https://cwiki.apache.org/confluence/display/incubator/PirkProposal}, 46 | } 47 | @article{psychology_today_2017, 48 | title = {Social Media Is Harmful to Your Brain and Relationships}, 49 | year = 2017, 50 | month = oct, 51 | journal = {Psychology Today}, 52 | publisher = {Sussex Publishers}, 53 | url = {https://www.psychologytoday.com/us/blog/obesely-speaking/201710/social-media-is-harmful-your-brain-and-relationships}, 54 | } 55 | @misc{unilogin, 56 | title = {UniLogin}, 57 | url = {https://github.com/UniLogin/UniLogin}, 58 | } 59 | @misc{whisper, 60 | title = {Whisper Protocol}, 61 | url = {https://geth.ethereum.org/docs/whisper/whisper-overview}, 62 | } 63 | @article{al-dahhan2019, 64 | title = {Survey on Revocation in Ciphertext-Policy Attribute-Based Encryption}, 65 | author = {Al-Dahhan, Ruqayah R. and Shi, Qi and Lee, Gyu Myoung and Kifayat, Kashif}, 66 | journal = {Sensors}, 67 | address = {Basel, Switzerland}, 68 | volume = 19, 69 | number = 7, 70 | doi = {10.3390/s19071695}, 71 | url = {https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6479996/pdf/sensors-19-01695.pdf}, 72 | date = {2019-04}, 73 | } 74 | @article{ateniese2006a, 75 | title = {Improved proxy re-encryption schemes with applications to secure distributed storage}, 76 | author = {Ateniese, Giuseppe and Fu, Kevin and Green, Matthew Daniel and Hohenberger, Susan}, 77 | journal = {ACM Transactions on Information and System Security}, 78 | volume = 9, 79 | number = 1, 80 | doi = {10.1145/1127345.1127346}, 81 | url = {https://doi.org/10.1145/1127345.1127346}, 82 | date = {2006-02}, 83 | } 84 | @article{nacl, 85 | title = {The security impact of a new cryptographic library}, 86 | author = {Bernstein, Daniel and Lange, Tanja and Schwabe, Peter}, 87 | year = 2012, 88 | journal = {Progress in Cryptology--LATINCRYPT 2012}, 89 | publisher = {Springer}, 90 | pages = {159--176}, 91 | } 92 | @article{eip712, 93 | title = {EIP-712: Ethereum Typed Structured Data Hashing and Signing [DRAFT]}, 94 | author = {Bloemen, Remco and Logvinov, Leonid and Evans, Jacob}, 95 | journal = {Ethereum Improvement Proposals}, 96 | volume = {no. 712}, 97 | url = {https://eips.ethereum.org/EIPS/eip-712}, 98 | note = {[Online serial]}, 99 | date = {2017-09}, 100 | } 101 | @article{bünz2020, 102 | title = {Zether: Towards Privacy in a Smart Contract World}, 103 | author = {Bünz, Benedikt and Agrawal, Shashank and Zamani, Mahdi and Boneh, Dan}, 104 | year = 2020, 105 | journal = {Financial Cryptography and Data Security Lecture Notes in Computer Science}, 106 | pages = {423–443}, 107 | doi = {10.1007/978-3-030-51280-4_23}, 108 | url = {https://crypto.stanford.edu/~buenz/papers/zether.pdf}, 109 | } 110 | @misc{cheng2020, 111 | title = {Talek: Private Group Messaging with Hidden Access Patterns}, 112 | author = {Cheng, Raymond and Scott, William and Masserova, Elisaweta and Zhang, Irene and Goyal, Vipul and Anderson, Thomas and Krishnamurthy, Arvind and Parno, Bryan}, 113 | journal = {arXiv preprint}, 114 | date = 2020, 115 | arxiv = {2001.08250}, 116 | } 117 | @phdthesis{diebold2017, 118 | title = {Self-Sovereign Identity using Smart Contracts on the Ethereum Blockchain}, 119 | author = {Diebold, Zachary}, 120 | url = {https://www.scss.tcd.ie/publications/theses/diss/2017/TCD-SCSS-DISSERTATION-2017-016.pdf}, 121 | date = {2017-05}, 122 | school = {Thesis-University of Dublin, Trinity College}, 123 | } 124 | @article{diffie-hellman1976, 125 | title = {New directions in cryptography}, 126 | author = {Diffie, W. and Hellman, M.}, 127 | year = 1976, 128 | journal = {IEEE Transactions on Information Theory}, 129 | volume = 22, 130 | number = 6, 131 | pages = {644–654}, 132 | doi = {10.1109/tit.1976.1055638}, 133 | } 134 | @article{el2020, 135 | title = {Optimized and secure pairing-friendly elliptic curves suitable for one layer proof composition.}, 136 | author = {El Housni, Youssef and Guillevic, Aurore}, 137 | year = 2020, 138 | journal = {IACR Cryptol. ePrint Arch.}, 139 | pages = 351, 140 | } 141 | @inproceedings{ge2019, 142 | title = {Identity-based broadcast encryption with efficient revocation}, 143 | author = {Ge, Aijun and Wei, Puwen}, 144 | year = 2019, 145 | booktitle = {IACR International Workshop on Public Key Cryptography}, 146 | pages = {405--435}, 147 | url = {https://eprint.iacr.org/2019/038.pdf}, 148 | organization = {Springer}, 149 | } 150 | @misc{green2018, 151 | title = {Should you use SRP?}, 152 | author = {Green, Matthew}, 153 | url = {https://blog.cryptographyengineering.com/should-you-use-srp/}, 154 | date = {2018-10}, 155 | } 156 | @misc{hashemi2017, 157 | title = {The Infrastructure Behind Twitter: Scale}, 158 | author = {Hashemi, Mazdak}, 159 | publisher = {Twitter Engineering Blog}, 160 | url = {https://blog.twitter.com/engineering/en_us/topics/infrastructure/2017/the-infrastructure-behind-twitter-scale.html}, 161 | date = {2017-01}, 162 | } 163 | @article{henry2018, 164 | title = {Blockchain Access Privacy: Challenges and Directions}, 165 | author = {Henry, Ryan and Herzberg, Amir and Kate, Aniket}, 166 | year = 2018, 167 | journal = {IEEE Security \& Privacy}, 168 | volume = 16, 169 | number = 4, 170 | pages = {38–45}, 171 | doi = {10.1109/MSP.2018.3111245}, 172 | } 173 | @online{json-web-encryption, 174 | title = {{JSON} Web Encryption ({JWE})}, 175 | author = {Hildebrand, Joe and Jones, Michael}, 176 | url = {https://tools.ietf.org/html/rfc7516}, 177 | meta = {Request for Comments: 7516}, 178 | date = {2015-05}, 179 | } 180 | @misc{ugander2011, 181 | title = {The Anatomy of the Facebook Social Graph}, 182 | author = {Johan Ugander and Brian Karrer and Lars Backstrom and Cameron Marlow}, 183 | date = {2011-11-18}, 184 | eprint = {arXiv:1111.4503}, 185 | } 186 | @article{eip173, 187 | title = {EIP-173: Contract Ownership Standard [DRAFT]}, 188 | author = {Mudge, Nick and Finlay, Dan}, 189 | journal = {Ethereum Improvement Proposals}, 190 | volume = {no. 173}, 191 | url = {https://eips.ethereum.org/EIPS/eip-173}, 192 | note = {[Online serial]}, 193 | date = {2018-06}, 194 | } 195 | @article{omara2020, 196 | title = {The Messaging Layer Security (MLS) Architecture [Draft]}, 197 | author = {Omara, E. and Beurdouche, B. and Rescorla, E. and Inguva, S. and Kwon, A. and Duric, A.}, 198 | publisher = {IETF Network Working Group}, 199 | url = {https://messaginglayersecurity.rocks/mls-architecture/draft-ietf-mls-architecture.html}, 200 | date = {2020-07}, 201 | } 202 | @misc{anon_terminology, 203 | title = {A terminology for talking about privacy by data minimization: Anonymity, Unlinkability, Undetectability, Unobservability, Pseudonymity, and Identity Management}, 204 | author = {Pfitzmann, Andreas and Hansen, Marit}, 205 | url = {http://dud.inf.tu-dresden.de/literatur/Anon\_Terminology\_v0.34.pdf}, 206 | note = {v0.34}, 207 | date = {2010-09}, 208 | } 209 | @article{raikwar2019, 210 | title = {SoK of used cryptography in blockchain}, 211 | author = {Raikwar, Mayank and Gligoroski, Danilo and Kralevska, Katina}, 212 | year = 2019, 213 | journal = {IEEE Access}, 214 | publisher = {IEEE}, 215 | volume = 7, 216 | pages = {148550--148575}, 217 | } 218 | @article{eip1078, 219 | title = {EIP-1078: Universal Login/Signup Using ENS Subdomains [DRAFT]}, 220 | author = {Sande, Van and Alex}, 221 | journal = {Ethereum Improvement Proposals}, 222 | volume = {no. 1078}, 223 | url = {https://eips.ethereum.org/EIPS/eip-1078}, 224 | note = {[Online serial]}, 225 | date = {2018-05}, 226 | } 227 | @booklet{nakamoto, 228 | title = {{Bitcoin: A Peer-to-peer Electronic Cash System.}}, 229 | author = {Satoshi Nakamoto}, 230 | year = 2008, 231 | month = oct, 232 | howpublished = {\url{https://bitcoin.org/bitcoin.pdf}}, 233 | } 234 | @article{eip1271, 235 | title = {EIP-1271: Standard Signature Validation Method for Contracts [DRAFT]}, 236 | author = {Thorstensson, Joel}, 237 | journal = {Ethereum Improvement Proposals}, 238 | volume = {no. 1271}, 239 | url = {https://eips.ethereum.org/EIPS/eip-1271}, 240 | note = {[Online serial]}, 241 | date = {2018-07}, 242 | } 243 | @article{eip2844, 244 | title = {EIP-2844: Add DID related methods to the JSON-RPC [DRAFT]}, 245 | author = {Thorstensson, Joel}, 246 | journal = {Ethereum Improvement Proposals}, 247 | volume = {no. 2844}, 248 | url = {https://eips.ethereum.org/EIPS/eip-2844}, 249 | note = {[Online serial]}, 250 | date = {2020-08}, 251 | } 252 | @book{swarm, 253 | title = {The Book of Swarm}, 254 | author = {Viktor Trón}, 255 | url = {https://swarm-gateways.net/bzz:/latest.bookofswarm.eth/the-book-of-swarm.pdf}, 256 | note = {v1.0pre-release6}, 257 | date = {2020-09-10}, 258 | } 259 | @article{erc20, 260 | title = {ERC-20 Token Standard}, 261 | author = {Vogelsteller, Fabian and Buterin, Vitalik}, 262 | url = {https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md}, 263 | date = {2015-11}, 264 | } 265 | @misc{0xwhitepaper, 266 | title = {0x: An open protocol for decentralized exchange on the Ethereum blockchain}, 267 | author = {Warren, Will and Bandeali, Amir}, 268 | url = {https://github.com/0xProject/whitepaper}, 269 | date = {2017-02}, 270 | } 271 | @article{activitypub, 272 | title = {ActivityPub}, 273 | author = {Webber, Christopher Lemmer and Tallon, Jessica and Shepherd, Erin and Guy, Amy and Prodromou, Evan}, 274 | journal = {W3C Recommendation, Social Web Working Group}, 275 | url = {https://www.w3.org/TR/activitypub/}, 276 | date = {2018-01-23}, 277 | } 278 | @article{williams2019, 279 | title = {Arweave: A Protocol for Economically Sustainable Information Permanence}, 280 | author = {Williams, Same and Diordiiev, Viktor and Berman, Lev and Rayboul, India and Uemlianin, Ivan}, 281 | url = {https://www.arweave.org/yellow-paper.pdf}, 282 | date = {2019-11}, 283 | } 284 | @misc{ethereumyellow, 285 | title = {Ethereum: A Secure Decentralised Generalised Transaction Ledger}, 286 | author = {Wood, Gavin}, 287 | url = {https://ethereum.github.io/yellowpaper/paper.pdf}, 288 | note = {Petersburg Version 3e2c089}, 289 | date = {2020-09-05}, 290 | } 291 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | # Creative Commons Attribution-ShareAlike 4.0 International 2 | 3 | Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible. 4 | 5 | ### Using Creative Commons Public Licenses 6 | 7 | Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses. 8 | 9 | * __Considerations for licensors:__ Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. [More considerations for licensors](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensors). 10 | 11 | * __Considerations for the public:__ By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described. Although not required by our licenses, you are encouraged to respect those requests where reasonable. [More considerations for the public](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensees). 12 | 13 | ## Creative Commons Attribution-ShareAlike 4.0 International Public License 14 | 15 | By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. 16 | 17 | ### Section 1 – Definitions. 18 | 19 | a. __Adapted Material__ means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. 20 | 21 | b. __Adapter's License__ means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License. 22 | 23 | c. __BY-SA Compatible License__ means a license listed at [creativecommons.org/compatiblelicenses](http://creativecommons.org/compatiblelicenses), approved by Creative Commons as essentially the equivalent of this Public License. 24 | 25 | d. __Copyright and Similar Rights__ means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. 26 | 27 | e. __Effective Technological Measures__ means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements. 28 | 29 | f. __Exceptions and Limitations__ means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material. 30 | 31 | g. __License Elements__ means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike. 32 | 33 | h. __Licensed Material__ means the artistic or literary work, database, or other material to which the Licensor applied this Public License. 34 | 35 | i. __Licensed Rights__ means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license. 36 | 37 | j. __Licensor__ means the individual(s) or entity(ies) granting rights under this Public License. 38 | 39 | k. __Share__ means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. 40 | 41 | l. __Sui Generis Database Rights__ means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world. 42 | 43 | m. __You__ means the individual or entity exercising the Licensed Rights under this Public License. __Your__ has a corresponding meaning. 44 | 45 | ### Section 2 – Scope. 46 | 47 | a. ___License grant.___ 48 | 49 | 1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to: 50 | 51 | A. reproduce and Share the Licensed Material, in whole or in part; and 52 | 53 | B. produce, reproduce, and Share Adapted Material. 54 | 55 | 2. __Exceptions and Limitations.__ For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions. 56 | 57 | 3. __Term.__ The term of this Public License is specified in Section 6(a). 58 | 59 | 4. __Media and formats; technical modifications allowed.__ The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material. 60 | 61 | 5. __Downstream recipients.__ 62 | 63 | A. __Offer from the Licensor – Licensed Material.__ Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License. 64 | 65 | B. __Additional offer from the Licensor – Adapted Material.__ Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply. 66 | 67 | C. __No downstream restrictions.__ You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material. 68 | 69 | 6. __No endorsement.__ Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i). 70 | 71 | b. ___Other rights.___ 72 | 73 | 1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise. 74 | 75 | 2. Patent and trademark rights are not licensed under this Public License. 76 | 77 | 3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties. 78 | 79 | ### Section 3 – License Conditions. 80 | 81 | Your exercise of the Licensed Rights is expressly made subject to the following conditions. 82 | 83 | a. ___Attribution.___ 84 | 85 | 1. If You Share the Licensed Material (including in modified form), You must: 86 | 87 | A. retain the following if it is supplied by the Licensor with the Licensed Material: 88 | 89 | i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); 90 | 91 | ii. a copyright notice; 92 | 93 | iii. a notice that refers to this Public License; 94 | 95 | iv. a notice that refers to the disclaimer of warranties; 96 | 97 | v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable; 98 | 99 | B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and 100 | 101 | C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License. 102 | 103 | 2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information. 104 | 105 | 3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable. 106 | 107 | b. ___ShareAlike.___ 108 | 109 | In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply. 110 | 111 | 1. The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License. 112 | 113 | 2. You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material. 114 | 115 | 3. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply. 116 | 117 | ### Section 4 – Sui Generis Database Rights. 118 | 119 | Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: 120 | 121 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database; 122 | 123 | b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and 124 | 125 | c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. 126 | 127 | For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights. 128 | 129 | ### Section 5 – Disclaimer of Warranties and Limitation of Liability. 130 | 131 | a. __Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.__ 132 | 133 | b. __To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.__ 134 | 135 | c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. 136 | 137 | ### Section 6 – Term and Termination. 138 | 139 | a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically. 140 | 141 | b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: 142 | 143 | 1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or 144 | 145 | 2. upon express reinstatement by the Licensor. 146 | 147 | For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License. 148 | 149 | c. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License. 150 | 151 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License. 152 | 153 | ### Section 7 – Other Terms and Conditions. 154 | 155 | a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. 156 | 157 | b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License. 158 | 159 | ### Section 8 – Interpretation. 160 | 161 | a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License. 162 | 163 | b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions. 164 | 165 | c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor. 166 | 167 | d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority. 168 | 169 | > Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” The text of the Creative Commons public licenses is dedicated to the public domain under the [CC0 Public Domain Dedication](https://creativecommons.org/publicdomain/zero/1.0/legalcode). Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at [creativecommons.org/policies](http://creativecommons.org/policies), Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses. 170 | > 171 | > Creative Commons may be contacted at creativecommons.org. 172 | -------------------------------------------------------------------------------- /whitepaper/dsnp_whitepaper.tex: -------------------------------------------------------------------------------- 1 | \documentclass[12pt,letterpaper]{article} 2 | \usepackage[left=1in,right=1in,top=1in,bottom=1in]{geometry} 3 | \usepackage[utf8]{inputenc} 4 | \usepackage{afterpage} 5 | \usepackage{xcolor} 6 | \setlength{\emergencystretch}{3em} % prevent overfull lines 7 | \providecommand{\tightlist}{% 8 | \setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}} 9 | 10 | \usepackage[hidelinks,bookmarks]{hyperref} 11 | \usepackage{bookmark} 12 | \usepackage[compact]{titlesec} 13 | \usepackage[title]{appendix} 14 | \usepackage{graphicx} 15 | \usepackage{enumitem} 16 | \usepackage{dirtytalk} 17 | \usepackage[ 18 | backend=bibtex, 19 | sorting=none, 20 | ]{biblatex} 21 | \addbibresource{biblio.bib} 22 | 23 | \setlength{\parindent}{0em} 24 | \setlength{\parskip}{1em} 25 | \setlength{\footnotesep}{1em} 26 | 27 | \urlstyle{same} 28 | 29 | \title{Decentralized Social Networking Protocol (DSNP)} 30 | \author{ 31 | Project Liberty\\ 32 | \href{mailto:hello@dsnp.org}{hello@dsnp.org}\\ 33 | \url{projectliberty.io} \url{dsnp.org} 34 | } 35 | \date{\textit{Originally Released}\\ 36 | October 2020\\ 37 | \textit{Revised Edition}\\ 38 | March 2024} 39 | 40 | \begin{document} 41 | 42 | \maketitle 43 | 44 | \begin{abstract} 45 | The decentralized social networking protocol (DSNP) allows users to interact via a global, 46 | open, decentralized social graph, giving them control of their identities and personal data 47 | while avoiding the balkanization of the current social network 48 | platforms and creating an open ecosystem of network participants. We propose a protocol 49 | for writing and reading social network data on public consensus systems. 50 | This protocol defines how identity, social graph, and messaging elements are represented 51 | to create a decentralized social network. Applicable aspects of control, privacy, 52 | authenticity, portability, usability, and extensibility are addressed for each element. 53 | This paper is accompanied by a protocol specification document.\footnote{https://spec.dsnp.org} 54 | \end{abstract} 55 | 56 | \vfill 57 | \copyright\, 2020-2024 Project Liberty\\ 58 | Published under a Creative Commons Attribution-ShareAlike 4.0 License.\\ 59 | See \textit{https://creativecommons.org/licenses/by-sa/4.0/} for details. 60 | 61 | % Remove the page number from the title page and start numbering at 1 on the second page 62 | \thispagestyle{empty} 63 | \clearpage 64 | 65 | \raggedright 66 | 67 | \section*{Preface to the Revised Edition} 68 | 69 | In the several years since this white paper was first published, consensus systems---as 70 | represented by blockchains, distributed ledger systems, and other technologies---have 71 | continued to evolve rapidly, benefiting from both an increase in public interest and renewed 72 | enthusiasm from the worldwide academic and development communities. There has been a 73 | corresponding, and welcome, shift away from a seemingly single-minded focus on 74 | cryptocurrency and financialization toward a more nuanced idea of a world of decentralized 75 | identity and decentralized applications (dApps). While some discussion of economic 76 | incentives is unavoidable, and indeed important, for consensus systems to endure and thrive, 77 | this shift has helped to create a technological environment where the benefits of 78 | decentralization and consensus-based state management have been recognized as extending far 79 | beyond purely financial applications. This in turn has helped to usher in new language that 80 | allows us to speak about such systems in more inclusive terms: whereas the first edition of 81 | this paper referenced the well known blockchain smart contract paradigm specifically, we 82 | can, with the benefit of time and hindsight, address the protocol more generally in terms of 83 | consensus systems, shared state, and the invocation of operations and resulting state change 84 | records on these systems. 85 | 86 | In preparing this revised edition, we have tried to avoid radical alterations to the original 87 | text; as such, this work can be viewed as both a historical document of the thought 88 | processes and design decisions that shaped the protocol initially, and as a statement of the 89 | objectives and design principles that should continue to be applied to the protocol's future 90 | evolution. With that in mind, it is worth pointing out that some specific terminology or 91 | implementation strategies may now be different in the official DSNP specification (which did 92 | not exist when this white paper was first published). Where explanation is needed, we have 93 | provided footnotes to address the current state of protocol evolution and divergence from 94 | the initial proposal (such as the change from incremental Graph Change Events to bulk 95 | changes via a User Data management paradigm) but have kept the historical text as intact as 96 | possible, as in almost all cases the same concepts still apply, even if implementation 97 | strategies have changed. Finally, we have moved the section on Batch Announcements from the 98 | appendix to be its own core section. This reflects its importance for implementing DSNP 99 | systems that are economically viable and highly scalable. 100 | 101 | \clearpage 102 | \section{Introduction}\label{sec:introduction} 103 | 104 | Most people have come to rely predominantly on private platforms serving as trusted third 105 | parties to manage and facilitate communication with their broadest network of 106 | relationships. This network is commonly known as a \say{social graph,} and presently most 107 | social graphs are privately owned and controlled by a small number of large technology 108 | companies. While the current ecosystem of social graphs has pioneered a new way for people 109 | to interact with their personal network and public figures on an unprecedented scale, it 110 | suffers from inherent weaknesses related to trust, incentive models, and equitable 111 | participation in the attention economy. 112 | 113 | These large, corporate-owned social graphs have made it possible for people to expand 114 | their network of relationships to an extremely large scale. However, each social graph is 115 | isolated, locking in users as a result of the high cost of re-creating a social graph in 116 | another provider's \say{walled garden.} This balkanized environment also prevents the 117 | broader developer community from helping to address challenging problems or contributing 118 | new innovations to improve this pervasive technology. 119 | 120 | All major social networks employ personalization algorithms to determine what content is 121 | presented to users. These are centralized, usually closed algorithms that are opaque and 122 | proprietary, and they offer the user limited input or insight into how they operate. 123 | Through passive data collection, these algorithms often trigger users' negative, 124 | fight-or-flight reactions to increase engagement.\cite{psychology_today_2017} 125 | 126 | This approach, in turn, creates more advertising opportunities and drives more revenue to 127 | the large companies that control the largest social graphs. Malicious actors exploit these 128 | algorithms by deploying bots, artificial profiles, and divisive content to manipulate users 129 | at scale. 130 | 131 | What is needed is a universally accessible, unified, and decentralized social graph that 132 | allows developers to build an ecosystem with a variety of applications. By decoupling 133 | applications and data, this ecosystem will allow for a wide range of personalization 134 | algorithms to be developed and employed by different applications, and even applied to 135 | specific communities and topics. 136 | 137 | This new approach will enable users to move seamlessly between applications without 138 | rebuilding their network of friends and public figures at each destination. Further, users 139 | will be able to choose from a diverse set of recommendation and moderation systems. 140 | Unbundling the social graph will lower switching costs and allow for a marketplace where 141 | developers compete on a level playing field, with diverse winners based on user needs and 142 | preferences. 143 | 144 | 145 | In this paper, we propose a solution to the balkanization of social graphs by employing a 146 | public protocol for writing and reading social graph data on public consensus systems using 147 | data transactions. We include both a structure for the graph as well as the mechanism for 148 | creating authentic claims from and about the user. Further, we outline an approach to 149 | sharing content over such a social graph, and ways in which new services can be built to 150 | efficiently aggregate and disseminate such information on public consensus systems at the 151 | scale required for a universal decentralized graph to be adopted by the majority of the 152 | population. 153 | 154 | \section{Solution Overview}\label{sec:solution_overview} 155 | 156 | The decentralized social networking protocol (DSNP) is composed of three major elements. 157 | The first is identity, which creates a representation of users. The second is a social 158 | graph, which models relationships between user identities. The final element is messaging, 159 | which facilitates communication between the users based on their social graph connections. 160 | 161 | \begin{samepage} 162 | We considered many different design aspects when creating the elements of 163 | this protocol. Six core aspects we address are: 164 | 165 | \begin{description} 166 | \tightlist 167 | \item[Agency:] 168 | Who owns and controls the data? 169 | \item[Privacy:] 170 | How and when is data private, and how is that privacy managed? 171 | \item[Authenticity:] 172 | How can protocol actions be verified and attributed? 173 | \item[Portability:] 174 | How can users make use of their personal data in different contexts? 175 | What data is available to third parties and how is it obtained? 176 | \item[Usability:] 177 | What options exist for user interaction? 178 | \item[Extensibility:] 179 | How is functionality changed or upgraded over time? 180 | \end{description} 181 | \end{samepage} 182 | 183 | Most social networking products solve only some of these aspects, whether through technical 184 | limitations or explicit choices. Vertically integrated products inherently struggle with 185 | portability, and many choose not to enforce privacy or ownership standards. Federated 186 | protocols, with their dependence on shared servers, generally can't provide strong user data 187 | ownership guarantees. Existing decentralized networks have limited privacy and private 188 | communication capabilities and struggle with usability, often coupling the ability to exercise 189 | core social functionality with transaction fees denominated in a specific cryptocurrency token. 190 | We believe the optimal approach to 191 | address these six core aspects is a protocol that leverages an existing public consensus 192 | system as a neutral, decentralized platform for data and communications, while defining a 193 | standard format for data interaction and employing strong encryption for privacy, allowing 194 | any number of different user experiences to be created. 195 | 196 | DSNP models the identity of a user as individually owned shared state on a public consensus 197 | system. Protocol operations allow the user to maintain complete control of their data, and 198 | ensure that no third party can revoke their access. These data transactions also act as the 199 | root for other protocol actions, allowing user relationships, messages, and content to have 200 | a common attribution. The operations enable users to delegate permissions for certain 201 | actions in the protocol to third parties, such as user agents or applications, without 202 | sacrificing ownership and control. Delegation allows for cost shifting, so authorized 203 | delegates can pay for the calls they invoke on the user's behalf. A \say{design by 204 | contract} approach allows for functional upgrades and multiple different implementations, 205 | while preserving user discretion on when or if to make changes. 206 | 207 | The social graph is composed of events emitted on a consensus system, modeling a directed 208 | graph of \say{follow} relationships. Users have direct control to make changes on the graph 209 | independent of the provider they are using. Relationships can be public or private, 210 | including the indication of whether the event is starting or ending a relationship. By using 211 | a common data format on a consensus system, the data has inherent portability. Users decide 212 | whom they share their data with, instead of being locked in to a third-party system. As with 213 | identity, users can delegate permissions to a user agent or third party, allowing them to 214 | emit relationship events on their behalf. In addition, users can share encryption keys to 215 | give third parties the ability to read private graph data. The protocol also supports 216 | extending relationship types to support other use cases, such as friends, fans, or group 217 | membership. 218 | 219 | Messaging is modeled as broadcast event announcements on a consensus system that link to 220 | content stored on a public file server. The solution supports options for both message and 221 | recipient privacy. All message data, whether stored on or off the chain, has a cryptographic 222 | chain of trust back to the originating identity. Since all messages are announced on chain, 223 | the common data format allows messages to be retrieved by any conforming client or third 224 | party, although private messages require the appropriate keys to decrypt them. Users can 225 | also delegate permissions to send messages on their behalf, whether for usability or 226 | cost-shifting reasons. Finally, the types and formats of messages and message announcements 227 | can be expanded over time to support additional use cases, such as reactions, spam scoring, 228 | curated topics, or tag-based discovery. 229 | 230 | Combined, these elements represent an unbundling of social networks as they currently 231 | exist, and create a unified, universally accessible, and decentralized ecosystem for 232 | social activity at global scale. 233 | 234 | \section{Identity}\label{sec:identity} 235 | 236 | In any social network, users must be consistently identified to engage in most use cases. 237 | The protocol defines a concept of identity to represent users in social graph relationships 238 | called a Social Identity. Social Identities are pseudonymous,\cite{anon_terminology} user 239 | owned, and default private. These properties are essential to the user's overall control of 240 | their identity. Protocol operations define the interface for interaction with the user's 241 | data, standardizing both how users can share their data with others and how they can 242 | delegate certain rights to others to act on their behalf. 243 | 244 | \subsection{Pseudonymity}\label{sec:pseudonymity} 245 | 246 | DSNP requires Social Identities to be pseudonymous. These identities provide a consistent 247 | record of an online actor not directly tied to an offline identity. To implement 248 | pseudonymity, the data that represents a Social Identity is owned by an anonymous control 249 | key, which allows a user to provide cryptographic proof of ownership. A person may share one 250 | Social Identity across multiple contexts, such as family, business, and gaming, or create 251 | multiple identities to keep different facets of life separate. Each Social Identity is tied 252 | to a separate uncorrelated control key and stored in a user's digital wallet. 253 | 254 | \begin{figure} 255 | \includegraphics[width=\linewidth]{figures/Social Identity Ownership Structure.png} 256 | \caption{Social Identity Ownership Structure} 257 | \label{fig:1} 258 | \end{figure} 259 | 260 | \subsection{User Agency and Delegation}\label{sec:user_ownership and_delegation} 261 | 262 | With most existing social networks, a user's access to their account can be suspended or 263 | revoked unilaterally by the site owner, based on any number of actual or perceived 264 | behaviors, resulting in the user's loss of access to their personal data and social graph. 265 | Even though the user populated their account with data and social connections, the site 266 | usually owns the account that the user created. A key goal of the protocol is for users to 267 | control and have agency over their data. Three techniques are used to ensure that people control 268 | their Social Identity: direct data control, rights delegation, and identity verification. 269 | 270 | \subsubsection{Direct Data Control} 271 | 272 | Many blockchain-based projects that employ smart contracts use a single contract instance to 273 | store multiple user's rights. While this approach works for simple use cases, such 274 | as nonupgradable smart contracts associating ERC-20\cite{erc20} token values with unique 275 | addresses, storing multiple users' data in a single smart contract means someone other than 276 | each user has the right to upgrade the common contract. Whoever has upgrade rights 277 | ultimately controls the contract, and therefore the functionality of the contract and the 278 | data it stores.\footnote{The first edition of this paper argued for giving users choice in 279 | how and when to upgrade their Social Identity as represented specifically by a blockchain 280 | smart contract. Further research and development led to the conclusion that creating a 281 | coherent public space would only be possible if the participants agreed to follow the same 282 | version (with allowances for forward and backward compatibility) of the protocol. The text 283 | has been updated to reinforce the important role that user opt-in still plays, but that it 284 | may be implemented using a variety of approaches.} Instead, the protocol guarantees that 285 | each user's control key retains sole control of their personal data and social graph. 286 | 287 | One major ramification of direct control is that the user should always have agency in the 288 | adoption of new system logic (for example, smart contract upgrades or blockchain core logic 289 | upgrades). At minimum, users require the ability to opt out of their association with a 290 | given consensus system. Ideally, consensus systems will enable democratic participation in 291 | the governance and adoption of logic related to this protocol; the precise mechanisms that 292 | help achieve this (DAOs, co-ops, etc.) are an area of active research within the technology 293 | community. This avoids the case of an outside party having unilateral rights to change the 294 | behavior of the system without the user's consent. An outside party in possession of 295 | unilateral access rights would be equivalent to the status quo, meaning that existing social 296 | network providers have the power to revoke user account access. For a Social Identity, no 297 | third party has this capability, within the constraints of the consensus system it is built on. 298 | 299 | The \say{design by contract} approach provides another extension to control: complete 300 | implementation change. Although we expect most users to use the same implementation, other 301 | implementations may arise to cover unique use cases since the protocol is designed to be 302 | interface first. 303 | 304 | \subsubsection{Rights Delegation} 305 | 306 | A Social Identity allows users to delegate certain rights to third parties to act on their 307 | behalf. This ability is accomplished by creating a system to delegate trust using the user's 308 | control key as owner and sole authority to grant new permissions. All granted permissions 309 | can be revoked in the same fashion. Both actions are simply protocol operations. 310 | 311 | The delegation of rights never removes the user's agency over their Social Identity. When 312 | delegating rights, it is also possible to limit third-party access to specific actions. 313 | Though third-party \say{bad actors} who receive rights may be able to take actions on the 314 | user's behalf until access is revoked, they cannot escalate their actions to ownership 315 | rights. 316 | 317 | Rights delegation also allows for cost shifting. Most blockchains, for example, have 318 | transaction processing costs associated with smart contract invocations. By allowing a third 319 | party to invoke actions on behalf of a user, the user---without sacrificing ownership---can 320 | benefit from the third party's payment of the transaction fee associated with the 321 | invocation. A simple example would be an ad-supported social networking client that pays the 322 | transaction fee for a user when posting a new image or video. 323 | 324 | This concept can also be extended to Social Identity creation by having the user sign a 325 | request with the private key from their digital wallet, authorizing a Social Identity to be 326 | created on their behalf. This signed request would be passed to a third party, who would 327 | then pay the fee to create a Social Identity, but with the user's control key as the 328 | owner. Such cost shifting is a key element to initial adoption, since it does not require 329 | users to own any cryptocurrency to create or use a Social Identity. 330 | 331 | \begin{figure} 332 | \includegraphics[width=\linewidth]{figures/Cost Shifting.png} 333 | \caption{Cost Shifting Example} 334 | \label{fig:2} 335 | \end{figure} 336 | 337 | \subsubsection{Identity Verification} 338 | 339 | Through rights delegation, some invocations of operations on the user's Social Identity may 340 | be made by third parties. To ensure that only authorized delegates make such calls, all 341 | operations that allow third-party delegate invocations require the third party to be in the 342 | user's authorized list of delegates and to have the sufficient permissions to invoke the 343 | intended action. 344 | 345 | Each action on the consensus system taken by an authorized third party can be traced back to 346 | the delegate, verifying the identity of the invoker. Delegates who engage in unauthorized 347 | activity can be identified and their permissions revoked. Actions previously taken by the 348 | abusing party can be refuted by the user. 349 | 350 | \subsection{Attributes}\label{sec:attributes} 351 | 352 | People using social media often choose to expose parts of their identity, or at least the 353 | identity that they inhabit on social media. Users can attach claims and metadata to their 354 | Social Identity. A set of attributes attached to an identity is often created as a profile: 355 | the most common metadata used on social media are display name and avatar, 356 | but can extend to claims about the user's real-world identity, such as name, age, or 357 | professional certifications. By using this mechanism, services may be created that verify a 358 | user's real identity, similar to Twitter's verified accounts, except open for all to use rather 359 | than only those who Twitter has \say{determined to be an account of public 360 | interest.}\cite{twitter_verified_accounts} 361 | 362 | \subsection{Portability}\label{sec:portability} 363 | 364 | When users control their data and it is stored on the consensus system, portability manifests 365 | differently than the traditional export/import paradigm. Data is shared with services 366 | instead of stored in services. People can use more than one service at a time while 367 | continuing to synchronize data between services. While public data is readable by anyone, 368 | private data is controlled through providing a plaintext copy of the data or providing 369 | decryption keys to the service. 370 | 371 | As a paradigm for portability, sharing requires the ability of a user to revoke access to a 372 | service that the user no longer desires to use. Two types of data fall outside the 373 | protocol's protections: plaintext copies and public data. When a user shares data with a 374 | service, technical controls in the protocol can no longer protect the user's data. Instead, 375 | control of that copy of the data is governed by the terms of service and the applicable laws 376 | governing the service. Depending on jurisdiction or other factors, the European Union 377 | General Data Protection Regulation,\cite{gdpr2016} California Consumer Privacy 378 | Act,\cite{ccpa2018} Lei Geral de Proteção de Dados,\cite{lgpd2019} and similar regulations 379 | may provide coverage, but they are outside the scope of the protocol. By definition, public 380 | data is accessible to all and is also governed by local law. 381 | 382 | Unlike previously shared data, user control of the creation and sharing of new data is 383 | absolute. The user can stop any undesired plaintext sharing and public data publishing. If 384 | the user has shared a decryption key with a service, the user must change their encryption 385 | key to disable a service's access to new private data. 386 | 387 | \section{Social Graph}\label{sec:social_graph} 388 | 389 | DSNP provides for the decentralized creation and management of a global mapping of all users 390 | and how they are related. This global mapping is commonly known as a social graph. 391 | Relationships are first-order primitives in the protocol, and they represent connections 392 | between users in a social graph. The two most common relationship types in social networks 393 | are \say{Friend} and \say{Follow.} These relationships represent connections between Social 394 | Identities, and can be public or private. Public relationships can be seen by anyone, while 395 | private relationships allow user control over who can view them. 396 | 397 | \subsection{Relationship Types}\label{sec:relationship_types} 398 | 399 | Users, represented by Social Identities, are the vertices in the social graph, and 400 | relationships are the edges. These relationships can be directed, such as in a Follow 401 | relationship, or undirected, such as in a Friend relationship. Twitter is an 402 | example of the directed Follow model. A public Follow relationship is created by the 403 | follower, but it does not require the permission of the followed.\footnote{Twitter allows for 404 | various tweaks to this simplistic model; blocking and privacy options, for example.} The 405 | reciprocal relationship can also exist, but it is not required. The follower controls both 406 | the formation and removal of the relationship. Facebook and LinkedIn are examples of 407 | networks that have an undirected Friend model. This requires the permission of both users to 408 | form the relationship, but either can remove it. DSNP uses Follow-based, directed edges in 409 | its social graph. The undirected Friend relationship, along with other relationship types, 410 | can use this directed approach as a building block for more complex relationship 411 | types. Access to encrypted, private posts requires permission from the user being followed 412 | in order to obtain the appropriate decryption keys, and closely resembles the process of 413 | creating a Friend relationship. 414 | 415 | \subsection{Graph Change Events}\label{sec:graph_change_events} 416 | 417 | The protocol models the creation or removal of a Follow relationship as a Graph Change 418 | Event.\footnote{Since this paper was originally published, the specification has endorsed 419 | handling of graph changes by updating shared state in aggregated form via the User Data 420 | operations. However, from a systems reasoning point of view, viewing changes to the social 421 | graph as discrete events is still relevant.} The sequence of these events represents the 422 | current state of the social graph rooted at each Social Identity. The event structure allows 423 | some data to be either public or private, even though all events on a public consensus 424 | system are by necessity public. A mechanism is also provided for sharing private event data 425 | with trusted parties. 426 | 427 | \subsubsection{Structure} 428 | 429 | To create a Follow relationship, the aspiring follower creates a Graph Change Event, with 430 | themselves as the Actor, the Social Identity they want to follow as the Object, and follow 431 | as the Action. The Graph Change Event is then published via a protocol operation on the 432 | user's Social Identity, making it visible on the consensus system. 433 | 434 | \begin{samepage} 435 | Graph Change Events have four major components\footnote{Actor and Object terms are borrowed from the Activity Streams 2.0 Vocabulary\cite{activitypub}}: 436 | 437 | \begin{description} 438 | \tightlist 439 | \item[Type:] 440 | Whether this is a public or private Graph Change Event. 441 | \item[Actor:] 442 | The Social Identity creating the event. In a public Follow relationship, this would be the follower. 443 | \item[Object:] 444 | The Social Identity that is being linked to the event. In a public Follow relationship, this would be the user being followed or unfollowed. 445 | \item[Action:] 446 | The action being taken. In a public Follow relationship, the options are follow and unfollow. 447 | \end{description} 448 | \end{samepage} 449 | 450 | \begin{figure} 451 | \includegraphics[width=\linewidth]{figures/Graph Change Events.png} 452 | \caption{Graph Change Events} 453 | \label{fig:3} 454 | \end{figure} 455 | 456 | A series of Graph Change Events are depicted in Figure \ref{fig:3}, along with the 457 | resulting state on the consensus system (notice that the unfollowed friends are no longer 458 | present). 459 | 460 | \subsubsection{Privacy} 461 | 462 | Graph Change Events always have unencrypted Type and Actor values. Graph Change Events of 463 | type public also have unencrypted \say{Object} and \say{Action} values. Graph Change Events 464 | of type private encrypt the values for \say{Object} and Action. This means that, despite the 465 | Graph Change Event being published to the consensus system, a key is required to interpret 466 | the encrypted values. A user generates a symmetric encryption key for encrypting the private 467 | Graph Change Events data.\footnote{The specification now utilizes asymmetric key pairs to 468 | generate one-off symmetric keys via a key agreement algorithm. This provides improved 469 | security and allows for additional use cases while minimizing key management overhead.} 470 | The user can store this encryption key in their wallet or on chain 471 | (see the \say{Key Storage} section). While private Graph Change Events do not allow outside 472 | observers to read who is being followed, it is still possible to see that the Social 473 | Identity expressed in the Actor field is actively publishing a particular type of event, 474 | which may still convey some level of valuable metadata information to a third party. 475 | 476 | \subsubsection{Validation} 477 | 478 | Graph Change Events are only partially validated when published to the consensus 479 | system. Type and Actor are validated as part of the publishing process. However, since 480 | Object and Action may be encrypted and unreadable by the consensus system logic, they are 481 | validated by the consumer of the Graph Change Event message. Private Graph Change Events can 482 | be validated only by those who can decrypt the data.\footnote{There may be ways for Social 483 | Identity addresses to be deterministic. This would provide ways for a user to follow users 484 | who have not yet joined, but might later join, the network.}$^{,}$\footnote{It might be 485 | possible to create Graph Change Events where the Object is not a Social Identity. 486 | Shifting validation to the event consumer would make context available for validation that 487 | would be unavailable within the constraints of consensus system transaction processing.} 488 | 489 | \subsubsection{Sharing} 490 | 491 | While public Graph Change Events are fully understandable by everyone, without additional 492 | action, only the Actor user has the ability to interpret their private Graph Change 493 | Events. Users may wish to share their graph with other users, user agents, or third-party 494 | online tools. Sharing is a conceptually simple process, but like many self-sovereign 495 | schemes, ceasing sharing is substantially more complicated. 496 | 497 | To share their list of private Graph Change Events with another party, the user can simply 498 | communicate their symmetric key through a secure direct channel. Doing so allows the other 499 | party to read the data, but does not allow them to modify it. The key is used for data 500 | encryption, but does not allow signing new Graph Change Events from that Actor.\footnote{The 501 | third party would also have to be a delegate with the appropriate permissions on the 502 | user’s Social Identity, in addition to having the symmetric key, in order to post a valid 503 | Graph Change Event.} This simple approach, however, is complicated by the need to be able 504 | to cease sharing with a third party. 505 | 506 | \subsubsection{Cease Sharing} 507 | 508 | To stop sharing private Graph Change Events with a third party, the symmetric key used to 509 | encrypt data on the Graph Change Event is rotated to a new value. No existing Graph Change 510 | Events are changed, but new Graph Change Events will use the new key to encrypt their 511 | private data. While the third party can continue to read the data from before the key 512 | rotation,\footnote{It is impossible to prove that something has been forgotten, thus access 513 | to old data can be enforced only by the delegate, not the user.} they cannot observe new 514 | changes to the graph, including unfollow Actions of Graph Change Event events for Objects 515 | they previously saw. The ability to revoke access to new Graph Change Events, much like the 516 | ability to revoke access to actions on their Social Identity, ensures that users maintain 517 | control of their graph data and its accessibility across various networks and tools. 518 | 519 | \subsubsection{Key Storage} 520 | 521 | \begin{figure} 522 | \includegraphics[width=\linewidth]{figures/Key Storage and Retrieval.png} 523 | \caption{Key Storage and Retrieval} 524 | \label{fig:4} 525 | \end{figure} 526 | 527 | To maintain portability, the keys used to encrypt private Graph Change Events need to be 528 | stored such that they are accessible from multiple devices. These keys can be serialized and 529 | encrypted and stored on the consensus system. The wallet has a few options for encrypting 530 | data, such as using the private key to deterministically generate a key useful for 531 | encryption\footnote{Used in MetaMask.\cite{metamask_doc}} and EIP-2844.\cite{eip2844} Each 532 | key is then able to be retrieved and decrypted by the wallet as needed. 533 | 534 | \section{Messaging}\label{sec:messaging} 535 | 536 | DSNP addresses messaging as a first-order concept so users can communicate with each other 537 | through a social graph. Posts, replies, reactions/likes, and direct messages are all 538 | examples of different message types today in social networks. To enable messaging, several 539 | key components are needed: 540 | 541 | \begin{samepage} 542 | \begin{description} 543 | \tightlist 544 | \item[Announcement:] 545 | A structure representing that a message exists 546 | \item[Announcement Metadata:] 547 | Key metadata embedded in an announcement allowing 548 | message verification and simple correlation of related messages 549 | \item[Content:] 550 | Detailed data containing the message text, additional metadata, and media links 551 | \end{description} 552 | \end{samepage} 553 | 554 | Combined, these components allow for a minimal model of most current social network 555 | messaging use cases, including broadcast and directed messaging types, as well as public and 556 | private messaging types. They may also be adapted to Layer 2 strategies to manage scale and 557 | cost. An example of this is Batch Message Announcements, as described in Appendix 558 | \ref{app:batch_message_announcements}. 559 | 560 | \subsection{Announcements}\label{sec:announcements} 561 | 562 | Announcements allow users to become aware of messages in different ways, depending on the 563 | type of message. Email uses SMTP to communicate between persistent nodes. Existing 564 | balkanized social networks perform this task by directly updating their internal systems. 565 | In a decentralized network without unique persistent nodes, however, the difficulty in 566 | making Announcements is twofold. First, the route to the receiver is not fixed; a user may 567 | be in multiple locations or using multiple devices. Second, the receiver may have only 568 | intermittent connectivity, so the network needs to maintain Announcements until the receiver 569 | is available. In addition, in the social media case, users expect that messages sent today 570 | will persist for followers added in the future, indefinitely. 571 | 572 | These constraints lead to a system of Announcements that are anchored to the consensus 573 | system. This system allows message recipients to replay messages as necessary or to monitor 574 | the system for incremental Announcements as they are created. To accomplish this task, 575 | Announcements include a minimal set of essential metadata that can be used to quickly filter 576 | messages needed for a given user. 577 | 578 | \subsection{Announcement Metadata}\label{sec:announcement_metadata} 579 | 580 | The protocol models a flexible Announcement data structure. All Announcements have at least 581 | four key attributes, but the format allows extensions to this data set to accomplish 582 | additional use cases. The four key attributes are: 583 | 584 | \begin{samepage} 585 | \begin{itemize} 586 | \tightlist 587 | \item 588 | Message Type 589 | \item 590 | Social Identity that is the source of the message 591 | \item 592 | URI of the content 593 | \item 594 | Hash of the content located by the content URI 595 | \end{itemize} 596 | \end{samepage} 597 | 598 | \begin{figure} 599 | \includegraphics[width=\linewidth]{figures/Announcement Metadata Structure.png} 600 | \caption{Announcement Metadata Structure} 601 | \label{fig:5} 602 | \end{figure} 603 | 604 | \begin{samepage} 605 | These key attributes allow Announcements to answer four key questions: 606 | 607 | \begin{enumerate} 608 | \tightlist 609 | \item 610 | What type of message is this? 611 | \item 612 | Who sent this message? 613 | \item 614 | Where is the content located? 615 | \item 616 | Is the content I am seeing exactly what was originally sent? 617 | \end{enumerate} 618 | \end{samepage} 619 | 620 | The four key attributes defined as metadata on each Announcement answer this set of 621 | questions for all Announcement types, and help prove the validity and authenticity of the 622 | related data. 623 | 624 | \subsubsection{What type of message is this?} 625 | 626 | Messages are modeled as events on the consensus system. Each Message Type is represented by 627 | a different event. The simplest is a Broadcast message, which has only the four key 628 | attributes already identified for an Announcement. Message Types may define additional 629 | attributes needed for their specific use case. 630 | 631 | \subsubsection{Who sent this message?} 632 | 633 | As described in the section on Social Identity, the user has the ability to authorize third 634 | parties to take actions on their behalf via the protocol. This means that a valid message 635 | must come from the user's Social Identity, but that the operation may be invoked by the user 636 | or an authorized third party. This allows more flexible use cases, such as delayed sending 637 | and cost shifting. When verifying a message sent in this manner, the consensus system 638 | security mechanism combined with the implementation logic can be used to ensure that only an 639 | authorized party sent the author's message. While authenticating authorship is expected to 640 | be primarily the domain of aggregators or other intermediaries, it is important that any 641 | message recipient be able to directly and independently authenticate message authorship in 642 | order to ensure portability and system integrity. 643 | 644 | \subsubsection{Where is the content located?} 645 | 646 | Content hosting is assumed, by default, to be the responsibility of the sender. It is, 647 | however, possible for the sender to delegate this responsibility to a third party. The only 648 | criteria for content hosting is that the data should be persistently available and have 649 | unrestricted access for retrieval. The Announcement contains a URI of the content location, 650 | enabling recipients to retrieve the content. The URI is expected to most often be an 651 | HTTPS\footnote{Why not HTTP? Serving HTTP content to HTTPS websites will fail in most 652 | browsers, but serving HTTPS content to an HTTP website will still work.} URL, allowing 653 | direct access to the referenced content, but any other protocol that is generally accessible 654 | may be substituted. Examples include Swarm or IPFS, with the caveat that protocols not 655 | supported by a recipient's user agent may limit interoperability. 656 | 657 | \subsubsection{Is the content I am seeing exactly what was originally sent?} 658 | 659 | The Announcement contains a Hash of the content referenced by the content URI. When the 660 | content is retrieved, the retrieved content can be hashed using the same algorithm and 661 | compared with the Hash in the Announcement. Matching Hashes indicate that the content is 662 | valid. To ensure unique hashes between Social Identities, the contents of the message must 663 | include an author property that matches the announcing identity. Content retrieved from a 664 | proxy or cache can also be validated, even when from a different URI, as long as the content 665 | is not transformed by such mechanisms. 666 | 667 | \subsection{Content}\label{sec:content} 668 | 669 | After a user has received a message Announcement and retrieved and authenticated the 670 | contents of a message, the content must still be interpreted. DSNP is adapting the W3C 671 | Recommendation on Activity Streams\cite{activitypub} to represent content data and 672 | metadata. Only minimal changes to the standard are needed to achieve integration with the 673 | consensus system-related use cases, and the expected changes may be compatible with existing 674 | tools. In addition, this may make it possible to bridge the unified graph emanating from the 675 | protocol and other Activity Stream implementations, as a result of common data models for 676 | content. 677 | 678 | Required changes to Activity Streams include enhancements to implement additional data for 679 | certain elements. An example is the Link model in Activity Streams for linking to images. 680 | While content can be authenticated through a chain of hashes or signatures back from 681 | Announcement to the trust of the consensus system, complete validation would require that 682 | the chain of hashes or signatures continue to the images or other data linked in the 683 | content. \say{Link} is augmented with a hash that can be used to easily verify that the 684 | linked content has not changed. 685 | 686 | \subsection{Broadcast and Directed Messaging}\label{sec:broadcast_and_directed_messaging} 687 | 688 | As previously described, the Message Type specifies the behavior and ancillary attributes of 689 | a message. Four key Message Types are defined here, though additional types may be created: 690 | 691 | \begin{samepage} 692 | \begin{description} 693 | \tightlist 694 | \item[Broadcast:] 695 | A message with no recipient 696 | \item[Reply:] 697 | A message with a referent or source message 698 | \item[Direct:] 699 | A message with a public recipient 700 | \item[Dead Drop:] 701 | A message with a private recipient 702 | \end{description} 703 | \end{samepage} 704 | 705 | \subsubsection{Broadcast} 706 | 707 | A Broadcast message is an Announcement with no recipient. Users primarily discover these 708 | messages by following the author and monitoring for messages with the author as the 709 | sender. Such messages may also be aggregated into public feeds and presented by 710 | recommendation algorithms. This form of message is analogous to public social media posts. 711 | 712 | \subsubsection{Reply} 713 | 714 | A Reply message is just like a Broadcast Announcement, but with a referent (\say{In Reply 715 | To}) message ID. A Reply message Announcement depends on the fact that content Hashes are 716 | unique for any content and Social Identity combination. As mentioned before, the content 717 | needs to include a matching author to validate. Each message may then generate its Hash 718 | before the Announcement is made and can therefore be referred to in an unambiguous 719 | fashion. A Reply Announcement uses this value as the referent message ID. A Reply message 720 | can reference a Broadcast Announcement or another Reply Announcement. This form of message 721 | is analogous to a comment on a public post on a Facebook page. Replies do not need to have 722 | complex content and can be used to represent reactions such as likes or upvotes. 723 | 724 | The need for this additional piece of information at the Announcement level instead of in 725 | content metadata is driven by discoverability. Users are often interested in replies to 726 | messages they have already discovered or are otherwise made aware of from Social Identities 727 | they do not follow. By placing the reference message in the Announcement, users can discover 728 | entire subtrees of content related to messages they have already received. Without such a 729 | mechanism, they would need to monitor all messages on the chain, retrieve the content URL, 730 | and examine it for relevance. At any scale, such actions are prohibitively inefficient. 731 | 732 | \begin{figure} 733 | \includegraphics[width=\linewidth]{figures/Message Types and Replies.png} 734 | \caption{Message Types and Replies} 735 | \label{fig:6} 736 | \end{figure} 737 | 738 | \subsubsection{Direct} 739 | 740 | A Direct message is sent to a specific Social Identity. Both the sender and the receiver are 741 | public, although the contents of the message would usually be encrypted. This message is 742 | analogous to an invitation to connect on LinkedIn. One of the ways users discover relevant 743 | message Announcements is by looking for Direct messages sent to their Social 744 | Identity. Friend requests or other cases where a recipient might not otherwise know to look 745 | for message Announcements from the message sender can use Direct messages to establish 746 | communications. 747 | 748 | \subsubsection{Dead Drop} 749 | 750 | A Dead Drop message is an Announcement that uses a special mechanism, called a Dead Drop 751 | Identifier (DDID), to indicate the recipient of the message, instead of a Social Identity. 752 | The intention is to provide end-to-end encryption and metadata privacy by concealing the 753 | intended recipient, in order to avoid revealing the receiver's private social graph 754 | relationships through metadata analysis. This is analogous to a Twitter direct message, 755 | where outside parties can neither read the message nor even determine that the two parties 756 | are communicating with each other. DSNP extends this protection, preventing service 757 | providers from reading message contents or knowing who is communicating. 758 | 759 | Dead Drop Announcements must be addressed with care. The intended recipient needs to know 760 | that the Announcement is for them, but the network must not. One option for a user to 761 | discover a message intended for them with an encrypted recipient field is to attempt to 762 | decrypt every encrypted message on the network. The Whisper protocol from the Ethereum 763 | Foundation uses this model.\footnote{\say{Topics} provide a small amount of difficulty 764 | reduction, but only at a privacy loss.\cite{whisper-how}} As referenced for Reply 765 | Announcements, this option is prohibitively inefficient at scale. 766 | 767 | The protocol uses a novel Dead Drop ID system similar to the dead drops that are a staple 768 | of classic spycraft. For example, Alice places a message under a bench in the park. Anyone 769 | who stumbles upon the message would be unable to identify the intended recipient. Bob, 770 | however, knows the dead-drop location and can privately discover, retrieve, and read the 771 | message. 772 | 773 | Classic dead drops have a major logistical issue: The dead-drop location must be known to 774 | both the sending and receiving parties, but not to anyone else. This means the two parties 775 | must have an initial means of communicating before they establish the dead drop. No matter 776 | how secure the dead-drop mechanism is on its own, it relies on the security of the initial 777 | means of communication. Unlike the physical realm, public key cryptography provides a 778 | means to independently derive a common shared secret without prior private 779 | communication.\cite{diffie-hellman1976} Dead Drop Announcements leverage this shared 780 | secret to algorithmically create unique Dead Drop Identifiers that cannot be traced to the 781 | intended recipient. 782 | 783 | The identifiers are unique based on each sender-receiver, so each user has a different Dead 784 | Drop Identifier for sending a message to the other. This is analogous to Alice passing 785 | messages to Bob by leaving them under a park bench, and Bob passing messages to Alice by 786 | leaving them in a planter outside the hardware store: Two private, simplex channels with 787 | recipient privacy create a single, duplex channel with recipient privacy. At the event 788 | level, an observer can see that Alice and Bob are both sending messages, but cannot 789 | determine that they are sending messages to each other. If Alice and Bob each run their own 790 | consensus system node for retrieving content, or use nodes not run by a bad actor, they 791 | should also not be susceptible to information retrieval attacks, though timing attacks 792 | exploiting correlation between their activities are not prevented. 793 | 794 | \begin{figure} 795 | \includegraphics[width=\linewidth]{figures/DDID Flow For Alice with Two Associates.png} 796 | \caption{DDID Flow For Alice with Two Associates} 797 | \label{fig:7} 798 | \end{figure} 799 | 800 | While Dead Drop Identifiers can be derived without a separate secure communication channel, 801 | there must be some trigger for two users to start listening to each others' DDIDs. This 802 | intent may be communicated out of band, but may also be triggered implicitly or explicitly 803 | by on-chain actions. For example, user agents can choose to monitor DDIDs for all public 804 | followers of a Social Identity, whether perpetually or for a specific period of time after a 805 | follow notification. Alternatively, a Direct message Announcement could be sent from one 806 | user to the other with encrypted content expressing the desire to communicate with DDIDs, 807 | causing both to derive and monitor the relevant DDID values. 808 | 809 | \subsubsection{Other Message Types} 810 | 811 | The Announcement Message Types are extensible and are a flexible mechanism for adding new 812 | features to the core messaging capabilities of the protocol. For example, spam scoring 813 | services can express a spam score about Broadcast messages by extending Reply messages with 814 | a new Message Type and including scoring data in the Announcement or content. The same 815 | mechanism can be used for other services, such as fact checking, reputation scoring, or 816 | moderation, to add arbitrary metadata to an existing message. 817 | 818 | A Message Type may also be constructed to refer to a group of Announcements. This type 819 | enables \say{batching} or Layer 2 Announcements to reach the consensus system in a 820 | cost-efficient structure, while still preserving the authenticity of messages. A simple 821 | Batch Message Announcement structure is described in Appendix 822 | \ref{app:batch_message_announcements}. 823 | 824 | Another Message Type common to social media is a Reaction type. Reactions are similar to 825 | Reply Announcements, but with different metadata attached. A Reaction might have a sentiment 826 | value of positive, neutral, or negative, as well as a suggested rendering. The sentiment 827 | allows for simple cross-client display of reactions, while a suggested rendering can be used 828 | to expand the range of emotion for supporting clients. 829 | 830 | \section{Batch Message Announcements}\label{app:batch_message_announcements} 831 | 832 | A Batch Announcement is an extension of the Broadcast Announcement, and has the same 833 | set of data. It exists to allow the \say{batching} of all Announcement Message 834 | Types. Batch Announcements allow the publication of more than one message 835 | Announcement with a single on-chain Announcement. These Batch Messages introduce a 836 | new service role called a Batch Announcer, which collects message Announcements and 837 | batches them together. They have some trade-offs versus other Message Types, but 838 | allow substantial scaling increases and cost reductions. 839 | 840 | \begin{figure}[h] 841 | \includegraphics[width=\linewidth]{figures/Batch Message Structure.png} 842 | \caption{Batch Message Structure} 843 | \label{fig:9} 844 | \end{figure} 845 | 846 | A Batch Announcement has a different Message Type than a Broadcast Announcement, but 847 | otherwise has the same structure. However, the URI for a Batch Announcement always 848 | refers to a Batch Message file, the content of which has a specific file format, and 849 | is an ordered list of other Announcements. Each of the included Announcements has 850 | its complete set of Announcement metadata, including Message Type, Social Identity 851 | source, content URI, content Hash, and any type-specific Metadata (for example, a 852 | Reply Announcement would also have a referent message ID). Each Announcement also 853 | contains the Social Identity address of the sender and a signature of the URI 854 | content, replacing the signature that would have been used when posting to the 855 | consensus system. The Announcements included in the Batch Message file are not 856 | broadcast directly to the consensus system. However, since each message in the Batch 857 | Message file has a Hash, Social Identity, and signature, and the Batch Announcement 858 | has a Hash of the Batch Message file, authenticity still traces from each individual 859 | user message back to the chain, using techniques such as EIP -1271,\cite{eip1271} 860 | BLS12-377,\cite{el2020} or other similar approaches. 861 | 862 | \begin{figure} 863 | \includegraphics[width=\linewidth]{figures/Example Batch Process.png} 864 | \caption{Example Batch Process} 865 | \label{fig:10} 866 | \end{figure} 867 | 868 | This approach has a number of trade-offs. Benefits include lower cost and better 869 | scaling while maintaining authenticity. Drawbacks include increased complexity and 870 | the off-chain nature of messages referenced by Batch Messages. Increased complexity 871 | comes from the additional indirection used by Batch Messages. However, as volume 872 | increases, most clients will use dedicated content indexing services, which should 873 | have no issue with indexing Batch Messages. Potential latency comes from Batch 874 | Announcers only periodically posting Batch Announcements. The off-ledger nature of 875 | referenced messages can be mitigated by Indexers and other consensus system watchers 876 | replicating or caching Batch Message files. While a file can be removed, the 877 | existence of the Batch Message is listed on the chain, providing evidence that a 878 | file previously existed and allowing any file copy to be verified for authenticity 879 | against the listed Hash. 880 | 881 | Batch Messages are another example of the flexibility and extensibility of the 882 | protocol, enabling implementation on cost-sensitive consensus systems including 883 | sidechain or other Layer 2 blockchain solutions. Users have the option to publish 884 | Announcements directly or through an Announcement service. Batch Announcements work 885 | in cooperation with, not as a replacement for, other Message Types, while providing 886 | orders-of-magnitude scaling increases and cost reductions. 887 | 888 | \section{Conclusion}\label{sec:conclusion} 889 | 890 | This paper has proposed a protocol for creating a unified, universally accessible, 891 | decentralized social graph and an associated ecosystem of software services and 892 | applications. A modern social media company is highly complex, with many different 893 | components requiring a wide variety of deep expertise. From technical components such as 894 | software clients, caching services, and recommendation engines,\cite{hashemi2017} to more 895 | business-oriented concerns such as moderation, advertising sales, and regulatory compliance, 896 | each piece is a critical component of the network. This protocol enables coordination 897 | between services to build the complex ecosystem required to sustain modern social media 898 | without the liabilities of centralization. The next step is to create a comprehensive 899 | protocol specification leveraging the significant technical work already completed. 900 | 901 | Creating a complete system with so many components can be difficult when all functionality 902 | must occur inside a single organization. By unbundling the social network, an entire 903 | ecosystem can be created to operate at global scale and allow a diverse 904 | array of experts to address the pressing challenges created by malicious actors in the 905 | network. With a public broadcast model of protocol events, new services can be created to 906 | provide simple interfaces and data layers to create and consume data. These SaaS (Software 907 | as a Service) tools can provide an infrastructure layer that clients can leverage in unique 908 | combinations for different use cases. Figure 8 illustrates a hypothetical ecosystem of 909 | independent components that leverage the protocol to create a complete social networking 910 | system. 911 | 912 | \begin{figure} 913 | \includegraphics[width=\linewidth]{figures/SaaS Ecosystem.png} 914 | \caption{SaaS Ecosystem} 915 | \label{fig:8} 916 | \end{figure} 917 | 918 | A diversity of approaches, leveraging the interoperability of common data formats and 919 | discovery, minimize the effort to create new experiences. Graph indexing services can take 920 | on the load of parsing and storing graph events from the consensus system to provide easy 921 | access to graph data, including mechanisms to handle encrypted events. Content indexing 922 | services can enable content feed building, message threading, search results, trending 923 | topics, or caching, and, since all Announcements provide the information needed to 924 | authenticate the content, can combine trust and convenience. Content moderation and fact 925 | checking can be provided by multiple separate services for different use cases or interest 926 | groups, enabling more reliable, comprehensive, and transparent moderation. Given the open 927 | nature of the network, developers can offer different revenue models that can exist side by 928 | side, such as advertising, subscription, or direct payment, while allowing all experiences 929 | to interoperate directly. 930 | 931 | The protocol allows for the same underlying information to be available to everyone 932 | independent of intermediaries. Separating responsibilities encourages competition while 933 | better aligning incentives with user interest. The range of possibilities is difficult to 934 | predict, but by ensuring user data control and decentralizing the interaction model, the 935 | protocol allows for an entire ecosystem of participants to innovate and flourish. 936 | 937 | \nocite{0xwhitepaper} 938 | \nocite{al-dahhan2019} 939 | \nocite{al-dahhan2019} 940 | \nocite{ateniese2006a} 941 | \nocite{bünz2020} 942 | \nocite{cheng2020} 943 | \nocite{diebold2017} 944 | \nocite{eip1078} 945 | \nocite{eip173} 946 | \nocite{eip712} 947 | \nocite{ethereumyellow} 948 | \nocite{ge2019} 949 | \nocite{gnosissafe} 950 | \nocite{green2018} 951 | \nocite{henry2018} 952 | \nocite{json-web-encryption} 953 | \nocite{nacl} 954 | \nocite{nakamoto} 955 | \nocite{omara2020} 956 | \nocite{openzeppelin} 957 | \nocite{pirk} 958 | \nocite{raikwar2019} 959 | \nocite{swarm} 960 | \nocite{ugander2011} 961 | \nocite{unilogin} 962 | \nocite{whisper} 963 | \nocite{williams2019} 964 | 965 | \printbibliography 966 | 967 | \end{document} 968 | --------------------------------------------------------------------------------