CINXE.COM

<!DOCTYPE html> <html lang="en"> <head> <meta content="text/html; charset=utf-8" http-equiv="content-type"/> <title>Bluesky and the AT Protocol: Usable Decentralized Social Media</title>  <meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport"/> <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" rel="stylesheet" type="text/css"/> <link href="/static/browse/0.3.4/css/ar5iv.0.7.9.min.css" rel="stylesheet" type="text/css"/> <link href="/static/browse/0.3.4/css/ar5iv-fonts.0.7.9.min.css" rel="stylesheet" type="text/css"/> <link href="/static/browse/0.3.4/css/latexml_styles.css" rel="stylesheet" type="text/css"/> <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/js/bootstrap.bundle.min.js"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/html2canvas/1.3.3/html2canvas.min.js"></script> <script src="/static/browse/0.3.4/js/addons_new.js"></script> <script src="/static/browse/0.3.4/js/feedbackOverlay.js"></script> <meta content="social networks; decentralization; federation" lang="en" name="keywords"/> <base href="/html/2402.03239v2/"/></head> <body> <nav class="ltx_page_navbar"> <nav class="ltx_TOC"> <ol class="ltx_toclist"> <li class="ltx_tocentry ltx_tocentry_section"><a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S1" title="In Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">1 </span>Introduction</span></a></li> <li class="ltx_tocentry ltx_tocentry_section"> <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S2" title="In Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">2 </span>The Bluesky Social App</span></a> <ol class="ltx_toclist ltx_toclist_section"> <li class="ltx_tocentry ltx_tocentry_subsection"><a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S2.SS1" title="In 2. The Bluesky Social App ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">2.1 </span>Moderation Features</span></a></li> <li class="ltx_tocentry ltx_tocentry_subsection"><a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S2.SS2" title="In 2. The Bluesky Social App ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">2.2 </span>User Handles</span></a></li> <li class="ltx_tocentry ltx_tocentry_subsection"><a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S2.SS3" title="In 2. The Bluesky Social App ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">2.3 </span>Custom Feeds and Algorithmic Choice</span></a></li> </ol> </li> <li class="ltx_tocentry ltx_tocentry_section"> <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3" title="In Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">3 </span>The AT Protocol Architecture</span></a> <ol class="ltx_toclist ltx_toclist_section"> <li class="ltx_tocentry ltx_tocentry_subsection"><a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.SS1" title="In 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">3.1 </span>User Data Repositories</span></a></li> <li class="ltx_tocentry ltx_tocentry_subsection"><a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.SS2" title="In 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">3.2 </span>Personal Data Servers (PDS)</span></a></li> <li class="ltx_tocentry ltx_tocentry_subsection"> <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.SS3" title="In 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">3.3 </span>Indexing Infrastructure</span></a> <ol class="ltx_toclist ltx_toclist_subsection"> <li class="ltx_tocentry ltx_tocentry_subsubsection"><a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.SS3.SSS1" title="In 3.3. Indexing Infrastructure ‣ 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">3.3.1 </span>The Relay</span></a></li> <li class="ltx_tocentry ltx_tocentry_subsubsection"><a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.SS3.SSS2" title="In 3.3. Indexing Infrastructure ‣ 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">3.3.2 </span>The App View</span></a></li> </ol> </li> <li class="ltx_tocentry ltx_tocentry_subsection"><a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.SS4" title="In 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">3.4 </span>Labelers and Feed Generators</span></a></li> <li class="ltx_tocentry ltx_tocentry_subsection"> <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.SS5" title="In 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">3.5 </span>User Identity</span></a> <ol class="ltx_toclist ltx_toclist_subsection"> <li class="ltx_tocentry ltx_tocentry_subsubsection"><a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.SS5.SSS1" title="In 3.5. User Identity ‣ 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">3.5.1 </span>Resolving DID documents</span></a></li> <li class="ltx_tocentry ltx_tocentry_subsubsection"><a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.SS5.SSS2" title="In 3.5. User Identity ‣ 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">3.5.2 </span>The did:plc DID method</span></a></li> <li class="ltx_tocentry ltx_tocentry_subsubsection"><a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.SS5.SSS3" title="In 3.5. User Identity ‣ 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">3.5.3 </span>Authentication</span></a></li> </ol> </li> </ol> </li> <li class="ltx_tocentry ltx_tocentry_section"> <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S4" title="In Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">4 </span>Related Work</span></a> <ol class="ltx_toclist ltx_toclist_section"> <li class="ltx_tocentry ltx_tocentry_subsection"><a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S4.SS1" title="In 4. Related Work ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">4.1 </span>Scuttlebutt</span></a></li> <li class="ltx_tocentry ltx_tocentry_subsection"><a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S4.SS2" title="In 4. Related Work ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">4.2 </span>Nostr</span></a></li> <li class="ltx_tocentry ltx_tocentry_subsection"><a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S4.SS3" title="In 4. Related Work ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">4.3 </span>Farcaster and blockchain-based systems</span></a></li> <li class="ltx_tocentry ltx_tocentry_subsection"><a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S4.SS4" title="In 4. Related Work ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">4.4 </span>ActivityPub and Mastodon</span></a></li> </ol> </li> <li class="ltx_tocentry ltx_tocentry_section"><a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S5" title="In Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_title"><span class="ltx_tag ltx_tag_ref">5 </span>Conclusions</span></a></li> </ol></nav> </nav> <div class="ltx_page_main"> <div class="ltx_page_content"> <article class="ltx_document ltx_authors_1line ltx_leqno"> <h1 class="ltx_title ltx_title_document">Bluesky and the AT Protocol: Usable Decentralized Social Media</h1> <div class="ltx_authors"> <span class="ltx_creator ltx_role_author"> <span class="ltx_personname">Martin Kleppmann </span><span class="ltx_author_notes"> <span class="ltx_contact ltx_role_email"><a href="mailto:martin.kleppmann@cst.cam.ac.uk">martin.kleppmann@cst.cam.ac.uk</a> </span> <span class="ltx_contact ltx_role_orcid"><a class="ltx_ref" href="https://orcid.org/0000-0001-7252-6958" title="ORCID identifier">0000-0001-7252-6958</a></span> <span class="ltx_contact ltx_role_affiliation"><span class="ltx_text ltx_affiliation_institution" id="id1.1.id1">University of Cambridge</span><span class="ltx_text ltx_affiliation_city" id="id2.2.id2">Cambridge</span><span class="ltx_text ltx_affiliation_country" id="id3.3.id3">UK</span> </span></span></span> <span class="ltx_author_before">, </span><span class="ltx_creator ltx_role_author"> <span class="ltx_personname">Paul Frazee </span><span class="ltx_author_notes"> <span class="ltx_contact ltx_role_email"><a href="mailto:paul@blueskyweb.xyz">paul@blueskyweb.xyz</a> </span> <span class="ltx_contact ltx_role_orcid"><a class="ltx_ref" href="https://orcid.org/0009-0005-6762-4357" title="ORCID identifier">0009-0005-6762-4357</a></span> <span class="ltx_contact ltx_role_affiliation"><span class="ltx_text ltx_affiliation_institution" id="id4.1.id1">Bluesky Social PBC</span><span class="ltx_text ltx_affiliation_city" id="id5.2.id2">Seattle</span><span class="ltx_text ltx_affiliation_state" id="id6.3.id3">WA</span><span class="ltx_text ltx_affiliation_country" id="id7.4.id4">USA</span> </span></span></span> <span class="ltx_author_before">, </span><span class="ltx_creator ltx_role_author"> <span class="ltx_personname">Jake Gold </span><span class="ltx_author_notes"> <span class="ltx_contact ltx_role_email"><a href="mailto:jake@blueskyweb.xyz">jake@blueskyweb.xyz</a> </span> <span class="ltx_contact ltx_role_orcid"><a class="ltx_ref" href="https://orcid.org/0009-0009-1717-4967" title="ORCID identifier">0009-0009-1717-4967</a></span> <span class="ltx_contact ltx_role_affiliation"><span class="ltx_text ltx_affiliation_institution" id="id8.1.id1">Bluesky Social PBC</span><span class="ltx_text ltx_affiliation_city" id="id9.2.id2">Mountain View</span><span class="ltx_text ltx_affiliation_state" id="id10.3.id3">CA</span><span class="ltx_text ltx_affiliation_country" id="id11.4.id4">USA</span> </span></span></span> <span class="ltx_author_before">, </span><span class="ltx_creator ltx_role_author"> <span class="ltx_personname">Jay Graber </span><span class="ltx_author_notes"> <span class="ltx_contact ltx_role_email"><a href="mailto:jay@blueskyweb.xyz">jay@blueskyweb.xyz</a> </span> <span class="ltx_contact ltx_role_orcid"><a class="ltx_ref" href="https://orcid.org/0009-0003-1273-3308" title="ORCID identifier">0009-0003-1273-3308</a></span> <span class="ltx_contact ltx_role_affiliation"><span class="ltx_text ltx_affiliation_institution" id="id12.1.id1">Bluesky Social PBC</span><span class="ltx_text ltx_affiliation_city" id="id13.2.id2">Seattle</span><span class="ltx_text ltx_affiliation_state" id="id14.3.id3">WA</span><span class="ltx_text ltx_affiliation_country" id="id15.4.id4">USA</span> </span></span></span> <span class="ltx_author_before">, </span><span class="ltx_creator ltx_role_author"> <span class="ltx_personname">Daniel Holmgren </span><span class="ltx_author_notes"> <span class="ltx_contact ltx_role_email"><a href="mailto:daniel@blueskyweb.xyz">daniel@blueskyweb.xyz</a> </span> <span class="ltx_contact ltx_role_orcid"><a class="ltx_ref" href="https://orcid.org/0009-0007-4538-1707" title="ORCID identifier">0009-0007-4538-1707</a></span> <span class="ltx_contact ltx_role_affiliation"><span class="ltx_text ltx_affiliation_institution" id="id16.1.id1">Bluesky Social PBC</span><span class="ltx_text ltx_affiliation_city" id="id17.2.id2">Springfield</span><span class="ltx_text ltx_affiliation_state" id="id18.3.id3">MO</span><span class="ltx_text ltx_affiliation_country" id="id19.4.id4">USA</span> </span></span></span> <span class="ltx_author_before">, </span><span class="ltx_creator ltx_role_author"> <span class="ltx_personname">Devin Ivy </span><span class="ltx_author_notes"> <span class="ltx_contact ltx_role_email"><a href="mailto:devin@blueskyweb.xyz">devin@blueskyweb.xyz</a> </span> <span class="ltx_contact ltx_role_orcid"><a class="ltx_ref" href="https://orcid.org/0009-0008-4240-8676" title="ORCID identifier">0009-0008-4240-8676</a></span> <span class="ltx_contact ltx_role_affiliation"><span class="ltx_text ltx_affiliation_institution" id="id20.1.id1">Bluesky Social PBC</span><span class="ltx_text ltx_affiliation_city" id="id21.2.id2">Cambridge</span><span class="ltx_text ltx_affiliation_state" id="id22.3.id3">MA</span><span class="ltx_text ltx_affiliation_country" id="id23.4.id4">USA</span> </span></span></span> <span class="ltx_author_before">, </span><span class="ltx_creator ltx_role_author"> <span class="ltx_personname">Jeromy Johnson </span><span class="ltx_author_notes"> <span class="ltx_contact ltx_role_email"><a href="mailto:why@blueskyweb.xyz">why@blueskyweb.xyz</a> </span> <span class="ltx_contact ltx_role_orcid"><a class="ltx_ref" href="https://orcid.org/0009-0004-3161-9890" title="ORCID identifier">0009-0004-3161-9890</a></span> <span class="ltx_contact ltx_role_affiliation"><span class="ltx_text ltx_affiliation_institution" id="id24.1.id1">Bluesky Social PBC</span><span class="ltx_text ltx_affiliation_city" id="id25.2.id2">Seattle</span><span class="ltx_text ltx_affiliation_state" id="id26.3.id3">WA</span><span class="ltx_text ltx_affiliation_country" id="id27.4.id4">USA</span> </span></span></span> <span class="ltx_author_before">, </span><span class="ltx_creator ltx_role_author"> <span class="ltx_personname">Bryan Newbold </span><span class="ltx_author_notes"> <span class="ltx_contact ltx_role_email"><a href="mailto:bryan@blueskyweb.xyz">bryan@blueskyweb.xyz</a> </span> <span class="ltx_contact ltx_role_orcid"><a class="ltx_ref" href="https://orcid.org/0000-0002-8593-9468" title="ORCID identifier">0000-0002-8593-9468</a></span> <span class="ltx_contact ltx_role_affiliation"><span class="ltx_text ltx_affiliation_institution" id="id28.1.id1">Bluesky Social PBC</span><span class="ltx_text ltx_affiliation_city" id="id29.2.id2">Seattle</span><span class="ltx_text ltx_affiliation_state" id="id30.3.id3">WA</span><span class="ltx_text ltx_affiliation_country" id="id31.4.id4">USA</span> </span></span></span> <span class="ltx_author_before"> and </span><span class="ltx_creator ltx_role_author"> <span class="ltx_personname">Jaz Volpert </span><span class="ltx_author_notes"> <span class="ltx_contact ltx_role_email"><a href="mailto:jaz@blueskyweb.xyz">jaz@blueskyweb.xyz</a> </span> <span class="ltx_contact ltx_role_orcid"><a class="ltx_ref" href="https://orcid.org/0009-0009-2935-6020" title="ORCID identifier">0009-0009-2935-6020</a></span> <span class="ltx_contact ltx_role_affiliation"><span class="ltx_text ltx_affiliation_institution" id="id32.1.id1">Bluesky Social PBC</span><span class="ltx_text ltx_affiliation_city" id="id33.2.id2">San Francisco</span><span class="ltx_text ltx_affiliation_state" id="id34.3.id3">CA</span><span class="ltx_text ltx_affiliation_country" id="id35.4.id4">USA</span> </span></span></span> </div> <div class="ltx_dates">(2024)</div> <div class="ltx_abstract"> <h6 class="ltx_title ltx_title_abstract">Abstract.</h6> <p class="ltx_p" id="id36.id1">Bluesky is a new social network built upon the AT Protocol, a decentralized foundation for public social media. It was launched in private beta in February 2023, and has grown to over 10 million registered users by October 2024. In this paper we introduce the architecture of Bluesky and the AT Protocol, and explain how the technical design of Bluesky is informed by our goals: to enable decentralization by having multiple interoperable providers for every part of the system; to make it easy for users to switch providers; to give users agency over the content they see; and to provide a simple user experience that does not burden users with complexity arising from the system’s decentralized nature. The system’s openness allows anybody to contribute to content moderation and community management, and we invite the research community to use Bluesky as a dataset and testing ground for new approaches in social media moderation.</p> </div> <div class="ltx_keywords">social networks; decentralization; federation </div> <span class="ltx_note ltx_note_frontmatter ltx_role_journalyear" id="id1"><sup class="ltx_note_mark">†</sup><span class="ltx_note_outer"><span class="ltx_note_content"><sup class="ltx_note_mark">†</sup><span class="ltx_note_type">journalyear: </span>2024</span></span></span><span class="ltx_note ltx_note_frontmatter ltx_role_copyright" id="id2"><sup class="ltx_note_mark">†</sup><span class="ltx_note_outer"><span class="ltx_note_content"><sup class="ltx_note_mark">†</sup><span class="ltx_note_type">copyright: </span>cc</span></span></span><span class="ltx_note ltx_note_frontmatter ltx_role_conference" id="id3"><sup class="ltx_note_mark">†</sup><span class="ltx_note_outer"><span class="ltx_note_content"><sup class="ltx_note_mark">†</sup><span class="ltx_note_type">conference: </span>Proceedings of the ACM Conext-2024 Workshop on the Decentralization of the Internet; December 9–12, 2024; Los Angeles, CA, USA</span></span></span><span class="ltx_note ltx_note_frontmatter ltx_role_booktitle" id="id4"><sup class="ltx_note_mark">†</sup><span class="ltx_note_outer"><span class="ltx_note_content"><sup class="ltx_note_mark">†</sup><span class="ltx_note_type">booktitle: </span>Proceedings of the ACM Conext-2024 Workshop on the Decentralization of the Internet (DIN ’24), December 9–12, 2024, Los Angeles, CA, USA</span></span></span><span class="ltx_note ltx_note_frontmatter ltx_role_doi" id="id5"><sup class="ltx_note_mark">†</sup><span class="ltx_note_outer"><span class="ltx_note_content"><sup class="ltx_note_mark">†</sup><span class="ltx_note_type">doi: </span>10.1145/3694809.3700740</span></span></span><span class="ltx_note ltx_note_frontmatter ltx_role_isbn" id="id6"><sup class="ltx_note_mark">†</sup><span class="ltx_note_outer"><span class="ltx_note_content"><sup class="ltx_note_mark">†</sup><span class="ltx_note_type">isbn: </span>979-8-4007-1252-4/24/12</span></span></span><span class="ltx_note ltx_note_frontmatter ltx_role_ccs" id="id7"><sup class="ltx_note_mark">†</sup><span class="ltx_note_outer"><span class="ltx_note_content"><sup class="ltx_note_mark">†</sup><span class="ltx_note_type">ccs: </span>Information systems Social networking sites</span></span></span><span class="ltx_note ltx_note_frontmatter ltx_role_ccs" id="id8"><sup class="ltx_note_mark">†</sup><span class="ltx_note_outer"><span class="ltx_note_content"><sup class="ltx_note_mark">†</sup><span class="ltx_note_type">ccs: </span>Social and professional topics Centralization / decentralization</span></span></span><span class="ltx_note ltx_note_frontmatter ltx_role_ccs" id="id9"><sup class="ltx_note_mark">†</sup><span class="ltx_note_outer"><span class="ltx_note_content"><sup class="ltx_note_mark">†</sup><span class="ltx_note_type">ccs: </span>Networks Social media networks</span></span></span> <div class="ltx_pagination ltx_role_newpage"></div> <section class="ltx_section" id="S1"> <h2 class="ltx_title ltx_title_section"> <span class="ltx_tag ltx_tag_section">1. </span>Introduction</h2> <div class="ltx_para" id="S1.p1"> <p class="ltx_p" id="S1.p1.1">Over the last two decades, social media has evolved into a “digital town square” and a cornerstone of civic life <cite class="ltx_cite ltx_citemacro_citep">(Barabas et al<span class="ltx_text">.</span>, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib6" title="">2017</a>)</cite>. When a social media service is under the full control of a single corporation, it may change its policies on the whim of its leaders <cite class="ltx_cite ltx_citemacro_citep">(Yeung, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib62" title="">2023</a>)</cite>. Its operations are opaque (e.g. regarding which content is recommended to users), and its users lack agency over their user experience. As a result, there has been increasing interest in decentralized social networks, of which the <em class="ltx_emph ltx_font_italic" id="S1.p1.1.1">fediverse</em> around the ActivityPub protocol <cite class="ltx_cite ltx_citemacro_citep">(Lemmer-Webber et al<span class="ltx_text">.</span>, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib37" title="">2018</a>)</cite> and the Mastodon software <cite class="ltx_cite ltx_citemacro_citep">(Mastodon gGmbH, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib42" title="">2024</a>)</cite> is perhaps the best known.</p> </div> <div class="ltx_para" id="S1.p2"> <p class="ltx_p" id="S1.p2.1">However, decentralization also introduces new challenges. For example, in the case of Mastodon, a user needs to choose a server when creating an account. This choice is significant because the server name becomes part of the username; migrating to another server implies changing username, and preserving one’s followers during such a migration requires the cooperation of the old server. If a server is shut down without warning, accounts on that server cannot be recovered – a particular risk with volunteer-run servers. In principle, a user can host their own server, but only a small fraction of social media users have both the technical skills and the inclination to do so.</p> </div> <div class="ltx_para" id="S1.p3"> <p class="ltx_p" id="S1.p3.1">The distinction between servers in Mastodon introduces complexity for users that does not exist in centralized services. For example, a user viewing a thread of replies in the web interface of one server may see a different set of replies compared to viewing the same thread on another server, because a server only shows those replies that it knows about <cite class="ltx_cite ltx_citemacro_citep">(Adida, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib3" title="">2022</a>)</cite>. As another example, when viewing the web profile of an account on another server, clicking the “follow” button does not simply follow that account; instead, the user needs to enter the hostname of their own server and be redirected to a URL on their home server before they can follow the account. In our opinion, it is undesirable to burden users with such complexity arising from the federated architecture.</p> </div> <div class="ltx_para" id="S1.p4"> <p class="ltx_p" id="S1.p4.1">In this paper we introduce the <em class="ltx_emph ltx_font_italic" id="S1.p4.1.1">AT Protocol</em> (atproto), a decentralized foundation for social networking, and <em class="ltx_emph ltx_font_italic" id="S1.p4.1.2">Bluesky</em>, a Twitter-style microblogging app built upon it. A core design goal of atproto and Bluesky is to enable a user experience of the same or better quality as centralized services, while being open and decentralized on a technical level. The AT Protocol is designed such that for every part of the system there can be multiple competing operators providing interoperable services, making it easy to switch providers.</p> </div> <div class="ltx_para" id="S1.p5"> <p class="ltx_p" id="S1.p5.1">Decentralization alone is not able to solve some of the thorniest problems of social media, such as misinformation, harassment, and hate speech <cite class="ltx_cite ltx_citemacro_citep">(Roth and Lai, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib49" title="">2023</a>)</cite>. However, by opening up the internals of a service to the public, decentralization can enable a marketplace of approaches to these problems <cite class="ltx_cite ltx_citemacro_citep">(Masnick, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib41" title="">2019</a>)</cite>. For example, Bluesky allows anybody to run moderation services that make subjective decisions of selecting desirable content or flagging undesirable content, and users can choose which moderation services they want to subscribe to. Moderation services are decoupled from hosting providers, making it easy for users to switch moderation services until they find ones that match their preferences. We hope that this architectural openness enables communities to develop their own approaches to managing problematic content, independently of what hosting providers implement <cite class="ltx_cite ltx_citemacro_citep">(Masnick, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib41" title="">2019</a>)</cite>.</p> </div> <div class="ltx_para" id="S1.p6"> <p class="ltx_p" id="S1.p6.1">For example, researchers wanting to identify disinformation campaigns can easily get access to all content being posted, the social graph, and user profiles on Bluesky. If they are able construct an algorithm to label suspected disinformation, they can publish their labels in real time, and users who wish to see those labels can enable them in their client. One goal of this paper is to bring Bluesky and the AT Protocol to the attention of researchers working on such algorithms, and to invite them to use the rapidly growing dataset of Bluesky content as a basis for their work.</p> </div> </section> <section class="ltx_section" id="S2"> <h2 class="ltx_title ltx_title_section"> <span class="ltx_tag ltx_tag_section">2. </span>The Bluesky Social App</h2> <div class="ltx_para" id="S2.p1"> <p class="ltx_p" id="S2.p1.1">Bluesky is a microblogging application in the style of Twitter/X. The “official” client app is available on iOS, Android, and the web; several independently developed client apps are also available, such as Graysky <cite class="ltx_cite ltx_citemacro_citep">(Newman, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib46" title="">2024</a>)</cite> and deck.blue <cite class="ltx_cite ltx_citemacro_citep">(Filho, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib26" title="">2024</a>)</cite>. Users can make public posts containing up to 300 characters of text, up to four images, and short-form video. They can interact with posts by replying, reposting, or liking, and they can follow other users. By default users have two feeds: one showing posts by followed accounts in reverse chronological order, and one recommending popular content across the network. Users can also choose from many alternative feeds that show content on various topics, as explained below.</p> </div> <div class="ltx_para" id="S2.p2"> <p class="ltx_p" id="S2.p2.1">Bluesky launched an invite-only beta in February 2023, and has grown to over 10 million registered users in the following 20 months. Bluesky Social PBC (a public-benefit corporation) develops the official client app and operates the core services; the client and several server-side components are open source, dual-licensed under the MIT and Apache 2.0 licenses <cite class="ltx_cite ltx_citemacro_citep">(Bluesky Social PBC, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib18" title="">2024d</a>)</cite>. The protocols they use are defined by open specifications <cite class="ltx_cite ltx_citemacro_citep">(Bluesky Social PBC, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib16" title="">2024b</a>)</cite>. Several parts of the system, such as feed generators and alternative clients <cite class="ltx_cite ltx_citemacro_citep">(Bluesky Social PBC, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib15" title="">2024a</a>)</cite> are developed and operated by independent third parties.</p> </div> <section class="ltx_subsection" id="S2.SS1"> <h3 class="ltx_title ltx_title_subsection"> <span class="ltx_tag ltx_tag_subsection">2.1. </span>Moderation Features</h3> <div class="ltx_para" id="S2.SS1.p1"> <p class="ltx_p" id="S2.SS1.p1.1">Bluesky currently has the following moderation mechanisms (additional mechanisms are under discussion <cite class="ltx_cite ltx_citemacro_citep">(Bluesky Social PBC, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib12" title="">2023f</a>)</cite>):</p> <dl class="ltx_description" id="S2.I1"> <dt class="ltx_item" id="S2.I1.ix1"><span class="ltx_tag ltx_tag_item"><span class="ltx_text ltx_font_bold" id="S2.I1.ix1.1.1.1">Content filtering:: </span></span></dt> <dd class="ltx_item"> <div class="ltx_para" id="S2.I1.ix1.p1"> <p class="ltx_p" id="S2.I1.ix1.p1.1">Automated systems label potentially problematic content (such as spam, or images of a sexual or violent nature), and the app’s preferences allow users to choose whether to show or hide content in each of these categories in their feeds. Some filters are always applied regardless of user preferences.</p> </div> </dd> <dt class="ltx_item" id="S2.I1.ix2"><span class="ltx_tag ltx_tag_item"><span class="ltx_text ltx_font_bold" id="S2.I1.ix2.1.1.1">Mute:: </span></span></dt> <dd class="ltx_item"> <div class="ltx_para" id="S2.I1.ix2.p1"> <p class="ltx_p" id="S2.I1.ix2.p1.1">A user can mute specific accounts or threads, which hides the muted content from their own feeds and notifications. The content continues to be visible to other users, and the target does not know that they were muted. A user can also publish a mutelist of accounts, and other users can subscribe to that list, which has the same effect as if they individually muted all of the accounts on the list.</p> </div> </dd> <dt class="ltx_item" id="S2.I1.ix3"><span class="ltx_tag ltx_tag_item"><span class="ltx_text ltx_font_bold" id="S2.I1.ix3.1.1.1">Block:: </span></span></dt> <dd class="ltx_item"> <div class="ltx_para" id="S2.I1.ix3.p1"> <p class="ltx_p" id="S2.I1.ix3.p1.1">One user can block another, which prevents all future interactions (such as mentions, replies, or reposts) between those accounts in addition to bidirectional muting. Similarly to mutelists, a user can also publish a list of accounts, and other users can block all accounts on that list by subscribing to it.</p> </div> </dd> <dt class="ltx_item" id="S2.I1.ix4"><span class="ltx_tag ltx_tag_item"><span class="ltx_text ltx_font_bold" id="S2.I1.ix4.1.1.1">Interaction gating:: </span></span></dt> <dd class="ltx_item"> <div class="ltx_para" id="S2.I1.ix4.p1"> <p class="ltx_p" id="S2.I1.ix4.p1.1">A user who makes a post can restrict who is allowed to reply to it (anyone, anyone they follow, anyone mentioned in the post, and/or anyone on a particular list of accounts) <cite class="ltx_cite ltx_citemacro_citep">(Bluesky Social PBC, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib9" title="">2023c</a>)</cite>. The original poster can also hide replies to be accessible but not shown by default.</p> </div> </dd> <dt class="ltx_item" id="S2.I1.ix5"><span class="ltx_tag ltx_tag_item"><span class="ltx_text ltx_font_bold" id="S2.I1.ix5.1.1.1">Quote detachment:: </span></span></dt> <dd class="ltx_item"> <div class="ltx_para" id="S2.I1.ix5.p1"> <p class="ltx_p" id="S2.I1.ix5.p1.1">When a post is quoted by another user’s post, the author of the original post can detach it from the quote post. This reduces the risk of harassment through dog-piling.</p> </div> </dd> <dt class="ltx_item" id="S2.I1.ix6"><span class="ltx_tag ltx_tag_item"><span class="ltx_text ltx_font_bold" id="S2.I1.ix6.1.1.1">Takedown:: </span></span></dt> <dd class="ltx_item"> <div class="ltx_para" id="S2.I1.ix6.p1"> <p class="ltx_p" id="S2.I1.ix6.p1.1">Users can report content that violates the terms of service to moderation services. Operators of the services described in Section <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3" title="3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_tag">3</span></a> can take down violating media, posts, or accounts.</p> </div> </dd> <dt class="ltx_item" id="S2.I1.ix7"><span class="ltx_tag ltx_tag_item"><span class="ltx_text ltx_font_bold" id="S2.I1.ix7.1.1.1">Custom feeds:: </span></span></dt> <dd class="ltx_item"> <div class="ltx_para" id="S2.I1.ix7.p1"> <p class="ltx_p" id="S2.I1.ix7.p1.1">While the aforementioned mechanisms provide negative moderation (helping users avoid content they do not want to see), feed generators (see Section <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S2.SS3" title="2.3. Custom Feeds and Algorithmic Choice ‣ 2. The Bluesky Social App ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_tag">2.3</span></a>) can actively select high-quality content.</p> </div> </dd> </dl> </div> </section> <section class="ltx_subsection" id="S2.SS2"> <h3 class="ltx_title ltx_title_subsection"> <span class="ltx_tag ltx_tag_subsection">2.2. </span>User Handles</h3> <div class="ltx_para" id="S2.SS2.p1"> <p class="ltx_p" id="S2.SS2.p1.1">Like on Twitter/X, a Bluesky user has two names: the <em class="ltx_emph ltx_font_italic" id="S2.SS2.p1.1.1">display name</em> can be almost any string, and the <em class="ltx_emph ltx_font_italic" id="S2.SS2.p1.1.2">handle</em> needs to uniquely identify a user. A handle, prefixed with an @ sign, is used to mention another user in a post.</p> </div> <div class="ltx_para" id="S2.SS2.p2"> <p class="ltx_p" id="S2.SS2.p2.1">The need for handles to be unique creates challenges in decentralized systems, since it requires an authority that determines which handle is assigned to which user. Mastodon’s approach is to include the server name in the handle, which makes it difficult to move to another server. An alternative would be to use a blockchain-based naming system, such as the Ethereum Name System (ENS) <cite class="ltx_cite ltx_citemacro_citep">(ENS Labs Limited, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib20" title="">2024</a>)</cite>; this has the disadvantage of requiring the user to buy cryptocurrency in order to create an account, which we wanted to avoid.</p> </div> <div class="ltx_para" id="S2.SS2.p3"> <p class="ltx_p" id="S2.SS2.p3.1">Instead, Bluesky and atproto use DNS domain names as handles. Users can sign up for a subdomain of <span class="ltx_text ltx_font_typewriter" id="S2.SS2.p3.1.1">.bsky.social</span> for free. If a user already owns a domain name, they can claim it as their Bluesky handle by adding a DNS record or by hosting a file under a <span class="ltx_text ltx_font_typewriter" id="S2.SS2.p3.1.2">/.well-known/</span> HTTPS URL on that domain <cite class="ltx_cite ltx_citemacro_citep">(Liu, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib40" title="">2023</a>)</cite>. Users can also buy a new domain name within Bluesky, via a partnership with a domain registrar <cite class="ltx_cite ltx_citemacro_citep">(Bluesky Social PBC, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib13" title="">2023g</a>)</cite>. Domain names have several advantages:</p> <ul class="ltx_itemize" id="S2.I2"> <li class="ltx_item" id="S2.I2.i1" style="list-style-type:none;"> <span class="ltx_tag ltx_tag_item">•</span> <div class="ltx_para" id="S2.I2.i1.p1"> <p class="ltx_p" id="S2.I2.i1.p1.1">We leverage the existing infrastructure of ICANN, registrars, and name servers, including for example the dispute resolution procedures for trademarks.</p> </div> </li> <li class="ltx_item" id="S2.I2.i2" style="list-style-type:none;"> <span class="ltx_tag ltx_tag_item">•</span> <div class="ltx_para" id="S2.I2.i2.p1"> <p class="ltx_p" id="S2.I2.i2.p1.1">Domain names are a well-known concept even among non-technical users, and they are short and simple.</p> </div> </li> <li class="ltx_item" id="S2.I2.i3" style="list-style-type:none;"> <span class="ltx_tag ltx_tag_item">•</span> <div class="ltx_para" id="S2.I2.i3.p1"> <p class="ltx_p" id="S2.I2.i3.p1.1">A user can move to a different server without changing their handle (see Section <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.SS5" title="3.5. User Identity ‣ 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_tag">3.5</span></a>).</p> </div> </li> <li class="ltx_item" id="S2.I2.i4" style="list-style-type:none;"> <span class="ltx_tag ltx_tag_item">•</span> <div class="ltx_para" id="S2.I2.i4.p1"> <p class="ltx_p" id="S2.I2.i4.p1.1">Users do not need to host their own server to use their own domain name; they only need to maintain a DNS record.</p> </div> </li> <li class="ltx_item" id="S2.I2.i5" style="list-style-type:none;"> <span class="ltx_tag ltx_tag_item">•</span> <div class="ltx_para" id="S2.I2.i5.p1"> <p class="ltx_p" id="S2.I2.i5.p1.1">For organizations and people that already have a well-known domain name, using that name makes it easy for users to check that their Bluesky account is genuine. For example, the New York Times’ handle is <span class="ltx_text ltx_font_typewriter" id="S2.I2.i5.p1.1.1">@nytimes.com</span>.</p> </div> </li> <li class="ltx_item" id="S2.I2.i6" style="list-style-type:none;"> <span class="ltx_tag ltx_tag_item">•</span> <div class="ltx_para" id="S2.I2.i6.p1"> <p class="ltx_p" id="S2.I2.i6.p1.1">An organization can allow its staff to demonstrate their affiliation by granting them subdomains of the organization’s main domain name (comparable to institutional email addresses). For example, a journalist’s handle may indicate that they are at a particular news organization.</p> </div> </li> <li class="ltx_item" id="S2.I2.i7" style="list-style-type:none;"> <span class="ltx_tag ltx_tag_item">•</span> <div class="ltx_para" id="S2.I2.i7.p1"> <p class="ltx_p" id="S2.I2.i7.p1.1">Offering free subdomains costs very little.</p> </div> </li> </ul> </div> </section> <section class="ltx_subsection" id="S2.SS3"> <h3 class="ltx_title ltx_title_subsection"> <span class="ltx_tag ltx_tag_subsection">2.3. </span>Custom Feeds and Algorithmic Choice</h3> <div class="ltx_para" id="S2.SS3.p1"> <p class="ltx_p" id="S2.SS3.p1.1">Several decentralized social networks offer only a reverse-chronological feed of posts from accounts the user is following – a backlash against the opaque recommendation algorithms used by mainstream social networks. For example, Mastodon advertises itself as having “no algorithms or ads to waste your time” <cite class="ltx_cite ltx_citemacro_citep">(Mastodon gGmbH, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib42" title="">2024</a>)</cite>.</p> </div> <div class="ltx_para" id="S2.SS3.p2"> <p class="ltx_p" id="S2.SS3.p2.1">Our belief is that the problem lies not with algorithms <em class="ltx_emph ltx_font_italic" id="S2.SS3.p2.1.1">per se</em>, but rather with centrally controlled, opaque algorithms that remove user agency and prioritize user engagement over all else, e.g. by promoting controversial posts. Good recommendation algorithms can help users discover content that is relevant to them and find new accounts to follow – especially important for new users who are not yet following many accounts. They are also helpful for surfacing content on a particular topic, whereas following a user means seeing all of their posts, which might be on a mixture of topics, not all necessarily interesting to all followers. Our goal is to offer an open and diverse marketplace of algorithms in which communities can adapt the system to suit their needs, and users have more agency over how they spend their time and attention <cite class="ltx_cite ltx_citemacro_citep">(Graber, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib28" title="">2023</a>)</cite>.</p> </div> <div class="ltx_para" id="S2.SS3.p3"> <p class="ltx_p" id="S2.SS3.p3.1">Bluesky Social PBC offers a selection of feed algorithms of its own, and also allows anybody to create their own feed generator <cite class="ltx_cite ltx_citemacro_citep">(Bluesky Social PBC, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib7" title="">2023a</a>)</cite>. Tens of thousands of custom feeds have already been created. A feed generator can use arbitrary criteria to select its content. For example, it may use a manually curated list of accounts, and select posts from those accounts that contain a particular hashtag or emoji character. Use of machine learning algorithms is equally possible. </p> </div> </section> </section> <section class="ltx_section" id="S3"> <h2 class="ltx_title ltx_title_section"> <span class="ltx_tag ltx_tag_section">3. </span>The AT Protocol Architecture</h2> <div class="ltx_para" id="S3.p1"> <p class="ltx_p" id="S3.p1.1">Bluesky is the social app with the features explained in Section <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S2" title="2. The Bluesky Social App ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_tag">2</span></a>, while the AT Protocol is the underlying decentralized foundation. We maintain this separation because the AT Protocol is designed to support multiple <em class="ltx_emph ltx_font_italic" id="S3.p1.1.1">social modes</em>, not just Bluesky. For example, besides a Twitter-style microblogging app, atproto could also be used to implement Reddit-style forums, long-form blogs with comments, or domain-specific social applications such as link sharing or book reviews. The same user identity, social graph, and user data storage servers can be shared between all of these apps.</p> </div> <div class="ltx_para" id="S3.p2"> <p class="ltx_p" id="S3.p2.1">A social mode is defined by a <em class="ltx_emph ltx_font_italic" id="S3.p2.1.1">lexicon</em>, which specifies the schema of the data and the request endpoints involved <cite class="ltx_cite ltx_citemacro_citep">(Bluesky Social PBC, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib16" title="">2024b</a>)</cite>. Several lexicons are currently used: for example, the <span class="ltx_text ltx_font_typewriter" id="S3.p2.1.2">com.atproto</span> lexicon defines the core AT Protocol concepts such as user identity (Section <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.SS5" title="3.5. User Identity ‣ 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_tag">3.5</span></a>), the <span class="ltx_text ltx_font_typewriter" id="S3.p2.1.3">app.bsky</span> lexicon defines the microblogging mode, and the <span class="ltx_text ltx_font_typewriter" id="S3.p2.1.4">tools.ozone</span> lexicon supports moderation actions <cite class="ltx_cite ltx_citemacro_citep">(Bluesky Social PBC, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib17" title="">2024c</a>)</cite>. Anyone can define a new lexicon, allowing new social modes to coexist alongside the Bluesky social app on a shared infrastructure. The purpose of a lexicon is to provide documentation, to allow code generation and type-checking in applications, and to facilitate schema evolution for long-term compatibility and interoperability.</p> </div> <div class="ltx_para" id="S3.p3"> <p class="ltx_p" id="S3.p3.1">The biggest constraint for new social modes is that atproto is currently designed for content that users want to make public. In particular, Bluesky user profiles, posts, follows, and likes are all public. Blocking actions are also currently public; we are investigating mechanisms for making these private <cite class="ltx_cite ltx_citemacro_citep">(Bluesky Social PBC, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib14" title="">2023h</a>; Newbold, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib43" title="">2023</a>)</cite>. Only a small amount of user state is currently private: muted accounts and threads, notifications and their unread status, and user preferences such as content filtering settings. Private communications (direct messages) are currently handled by a centralized service run by Bluesky Social PBC; we plan to decentralize this component in the future.</p> </div> <figure class="ltx_figure" id="S3.F1"> <div class="ltx_flex_figure"> <div class="ltx_flex_cell ltx_flex_size_1"><img alt="Refer to caption" class="ltx_graphics ltx_centering ltx_figure_panel ltx_img_landscape" height="443" id="S3.F1.g1" src="x1.png" width="830"/></div> <div class="ltx_flex_break"></div> <div class="ltx_flex_cell ltx_flex_size_1"><span class="ltx_ERROR ltx_centering ltx_figure_panel undefined" id="S3.F1.1">\Description</span></div> <div class="ltx_flex_break"></div> <div class="ltx_flex_cell ltx_flex_size_1"> <p class="ltx_p ltx_figure_panel ltx_align_center" id="S3.F1.2">Client apps send posts, likes, etc. to the user’s home PDS. A stream of records from each PDS is consumed by the Relay, and aggregated to form the firehose. The firehose is consumed by the Bluesky App View as well as labelers and feed generators. PDSes read from the App View to obtain threads of replies, like counts, etc. Bluesky Social PBC currently hosts several PDSes, the Relay, the App View, and some of the labelers and feed generators. The Bluesky App View also pulls data from external labelers and feed generators. Other providers can set up alternative PDSes, aggregators, and app views if they wish (including app views for social modes other than microblogging).</p> </div> </div> <figcaption class="ltx_caption ltx_centering"><span class="ltx_tag ltx_tag_figure">Figure 1. </span>The main services involved in providing Bluesky, and data flows between them. Icons from Flaticon.com.</figcaption> </figure> <section class="ltx_subsection" id="S3.SS1"> <h3 class="ltx_title ltx_title_subsection"> <span class="ltx_tag ltx_tag_subsection">3.1. </span>User Data Repositories</h3> <div class="ltx_para" id="S3.SS1.p1"> <p class="ltx_p" id="S3.SS1.p1.1">All data that a user wishes to publish is added to their <em class="ltx_emph ltx_font_italic" id="S3.SS1.p1.1.1">repository</em>, which stores a collection of <em class="ltx_emph ltx_font_italic" id="S3.SS1.p1.1.2">records</em>. Whenever a user performs some action – making a post, liking another user’s post, following another user, etc. – that action becomes a record in their repository. Records are encoded in DAG-CBOR <cite class="ltx_cite ltx_citemacro_citep">(Protocol Labs, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib48" title="">2021</a>)</cite>, a restricted form of CBOR <cite class="ltx_cite ltx_citemacro_citep">(Bormann and Hoffman, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib19" title="">2020</a>)</cite>, a compact binary data format. The schema of records is defined by the lexicon, and a repository may contain a mixture of records from several different lexicons, representing user actions in different social modes. Media files (e.g. images) are stored outside of the user’s repository, but referenced by their CID <cite class="ltx_cite ltx_citemacro_citep">(IPFS Documentation, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib34" title="">2022</a>)</cite> (essentially a cryptographic hash) from a record in the repository. Similarly, a reference to a record in another repository (e.g. identifying a post being liked) also includes its CID.</p> </div> <div class="ltx_para" id="S3.SS1.p2"> <p class="ltx_p" id="S3.SS1.p2.1">Each user account has one repository, and it contains all of the actions they have ever performed, minus any records they have explicitly deleted. A <em class="ltx_emph ltx_font_italic" id="S3.SS1.p2.1.1">Personal Data Server (PDS)</em> hosts the user’s repository and makes it publicly available as a web service; we discuss PDSes in more detail in Section <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.SS2" title="3.2. Personal Data Servers (PDS) ‣ 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_tag">3.2</span></a>.</p> </div> <div class="ltx_para" id="S3.SS1.p3"> <p class="ltx_p" id="S3.SS1.p3.5">A user only updates their own repository; for example, if user <math alttext="A" class="ltx_Math" display="inline" id="S3.SS1.p3.1.m1.1"><semantics id="S3.SS1.p3.1.m1.1a"><mi id="S3.SS1.p3.1.m1.1.1" xref="S3.SS1.p3.1.m1.1.1.cmml">A</mi><annotation-xml encoding="MathML-Content" id="S3.SS1.p3.1.m1.1b"><ci id="S3.SS1.p3.1.m1.1.1.cmml" xref="S3.SS1.p3.1.m1.1.1">𝐴</ci></annotation-xml><annotation encoding="application/x-tex" id="S3.SS1.p3.1.m1.1c">A</annotation><annotation encoding="application/x-llamapun" id="S3.SS1.p3.1.m1.1d">italic_A</annotation></semantics></math> follows user <math alttext="B" class="ltx_Math" display="inline" id="S3.SS1.p3.2.m2.1"><semantics id="S3.SS1.p3.2.m2.1a"><mi id="S3.SS1.p3.2.m2.1.1" xref="S3.SS1.p3.2.m2.1.1.cmml">B</mi><annotation-xml encoding="MathML-Content" id="S3.SS1.p3.2.m2.1b"><ci id="S3.SS1.p3.2.m2.1.1.cmml" xref="S3.SS1.p3.2.m2.1.1">𝐵</ci></annotation-xml><annotation encoding="application/x-tex" id="S3.SS1.p3.2.m2.1c">B</annotation><annotation encoding="application/x-llamapun" id="S3.SS1.p3.2.m2.1d">italic_B</annotation></semantics></math>, this results only in a follow record in user <math alttext="A" class="ltx_Math" display="inline" id="S3.SS1.p3.3.m3.1"><semantics id="S3.SS1.p3.3.m3.1a"><mi id="S3.SS1.p3.3.m3.1.1" xref="S3.SS1.p3.3.m3.1.1.cmml">A</mi><annotation-xml encoding="MathML-Content" id="S3.SS1.p3.3.m3.1b"><ci id="S3.SS1.p3.3.m3.1.1.cmml" xref="S3.SS1.p3.3.m3.1.1">𝐴</ci></annotation-xml><annotation encoding="application/x-tex" id="S3.SS1.p3.3.m3.1c">A</annotation><annotation encoding="application/x-llamapun" id="S3.SS1.p3.3.m3.1d">italic_A</annotation></semantics></math>’s repository, and no change to <math alttext="B" class="ltx_Math" display="inline" id="S3.SS1.p3.4.m4.1"><semantics id="S3.SS1.p3.4.m4.1a"><mi id="S3.SS1.p3.4.m4.1.1" xref="S3.SS1.p3.4.m4.1.1.cmml">B</mi><annotation-xml encoding="MathML-Content" id="S3.SS1.p3.4.m4.1b"><ci id="S3.SS1.p3.4.m4.1.1.cmml" xref="S3.SS1.p3.4.m4.1.1">𝐵</ci></annotation-xml><annotation encoding="application/x-tex" id="S3.SS1.p3.4.m4.1c">B</annotation><annotation encoding="application/x-llamapun" id="S3.SS1.p3.4.m4.1d">italic_B</annotation></semantics></math>’s repository. To find all followers of user <math alttext="B" class="ltx_Math" display="inline" id="S3.SS1.p3.5.m5.1"><semantics id="S3.SS1.p3.5.m5.1a"><mi id="S3.SS1.p3.5.m5.1.1" xref="S3.SS1.p3.5.m5.1.1.cmml">B</mi><annotation-xml encoding="MathML-Content" id="S3.SS1.p3.5.m5.1b"><ci id="S3.SS1.p3.5.m5.1.1.cmml" xref="S3.SS1.p3.5.m5.1.1">𝐵</ci></annotation-xml><annotation encoding="application/x-tex" id="S3.SS1.p3.5.m5.1c">B</annotation><annotation encoding="application/x-llamapun" id="S3.SS1.p3.5.m5.1d">italic_B</annotation></semantics></math> requires indexing the content of all repositories. This design decision is similar to the way hyperlinks work on the web: it is easy to find all the outbound links from a web page at a given URL, but to find all the inbound links to a page requires an index of the entire web, which is maintained by web search engines.</p> </div> <div class="ltx_para" id="S3.SS1.p4"> <p class="ltx_p" id="S3.SS1.p4.1">The <em class="ltx_emph ltx_font_italic" id="S3.SS1.p4.1.1">AT</em> in atproto stands for <em class="ltx_emph ltx_font_italic" id="S3.SS1.p4.1.2">Authenticated Transfer</em>, which reflects the fact that repositories are cryptographically authenticated. The records in a repository are organized into a <em class="ltx_emph ltx_font_italic" id="S3.SS1.p4.1.3">Merkle Search Tree</em> (MST), a type of Merkle tree that remains balanced, even as records are inserted or deleted in arbitrary order <cite class="ltx_cite ltx_citemacro_citep">(Auvolat and Taïani, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib4" title="">2019</a>)</cite>. After every change to a repository, the root hash of the MST is signed; the public verification key for this signature is part of the user identity described in Section <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.SS5" title="3.5. User Identity ‣ 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_tag">3.5</span></a>. This enables an efficient cryptographic proof that a given record appears within a given user’s repository. Moreover, when a user updates or deletes a record, the MST enables a proof that the old record no longer appears in the repository.</p> </div> </section> <section class="ltx_subsection" id="S3.SS2"> <h3 class="ltx_title ltx_title_subsection"> <span class="ltx_tag ltx_tag_subsection">3.2. </span>Personal Data Servers (PDS)</h3> <div class="ltx_para" id="S3.SS2.p1"> <p class="ltx_p" id="S3.SS2.p1.1">A PDS stores repositories and associated media files, and allows anybody to query the data it hosts via a HTTP API. Moreover, a PDS provides a real-time stream of updates for the repositories it hosts via a WebSocket. Indexers (see Section <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.SS3" title="3.3. Indexing Infrastructure ‣ 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_tag">3.3</span></a>) subscribe to this stream in order to find out about new or deleted records (posts, likes, follows, etc.) with low latency. This architecture is illustrated in Figure <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.F1" title="Figure 1 ‣ 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_tag">1</span></a>.</p> </div> <div class="ltx_para" id="S3.SS2.p2"> <p class="ltx_p" id="S3.SS2.p2.1">Hosting a PDS for a small number of users requires only small computing resources, even if those users have a large number of followers. Users who wish to self-host their own PDS can therefore do so on a cheap virtual machine in the cloud, or even on a Raspberry Pi connected to their home internet router. However, we expect that most users will sign up for an account on a shared PDS run by a professional hosting provider – either Bluesky Social PBC, or another company.</p> </div> <div class="ltx_para" id="S3.SS2.p3"> <p class="ltx_p" id="S3.SS2.p3.1">Compared to choosing a Mastodon server, the user’s choice of PDS hosting provider is fairly inconsequential. The PDS URL is internal to the system, and is not normally visible to users. It makes no difference whether two users are on the same PDS or different PDSes, since interaction between users goes via the indexing infrastructure in any case. A user can migrate from one PDS to another by copying their repository and media files to the new PDS, and pointing their account at the new PDS URL (Section <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.SS5" title="3.5. User Identity ‣ 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_tag">3.5</span></a>). Even if a PDS shuts down without warning, users can upload a backup of their repository to a new PDS, and thus recover their account without losing any of their posts or their social graph.</p> </div> <div class="ltx_para" id="S3.SS2.p4"> <p class="ltx_p" id="S3.SS2.p4.1">PDS operators generally perform some basic moderation by deleting any illegal content hosted on their servers. However, PDS-level moderation is much less important than server-level moderation in Mastodon, because in atproto, the primary moderation role is taken on by separate actors in the system – the labelers and feed generators (see Section <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.SS4" title="3.4. Labelers and Feed Generators ‣ 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_tag">3.4</span></a>). This allows different sets of people to offer server hosting and moderation services, respectively; we believe this separation is valuable since operating a server and moderating a community require largely disjoint sets of skills <cite class="ltx_cite ltx_citemacro_citep">(Roth and Lai, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib49" title="">2023</a>)</cite>.</p> </div> </section> <section class="ltx_subsection" id="S3.SS3"> <h3 class="ltx_title ltx_title_subsection"> <span class="ltx_tag ltx_tag_subsection">3.3. </span>Indexing Infrastructure</h3> <div class="ltx_para" id="S3.SS3.p1"> <p class="ltx_p" id="S3.SS3.p1.1">On the web, websites are crawled and indexed by search engines, which then provide web-wide search and discovery features that the websites alone cannot provide. The AT Protocol is inspired by this architecture: the repositories hosted by PDSes are analogous to websites, and the indexing infrastructure is analogous to a search engine. User repositories are primary data (the “source of truth”), and the indexes are derived from the content of the repositories.</p> </div> <div class="ltx_para" id="S3.SS3.p2"> <p class="ltx_p" id="S3.SS3.p2.1">At the time of writing, most of Bluesky’s indexing infrastructure is operated by Bluesky Social PBC (indicated by a shaded area in Figure <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.F1" title="Figure 1 ‣ 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_tag">1</span></a>). However, the company does not have any privileged access: since repositories are public, anybody can crawl and index them using the same protocols as our systems use. If Bluesky Social PBC were to violate users’ expectations – for example, by censoring (omitting from the index) accounts that users wish to see – other parties would be free to provide their own indexes that do not perform this censorship. Client apps could switch to reading from a different index, or even use a combination of multiple indexes.</p> </div> <div class="ltx_para" id="S3.SS3.p3"> <p class="ltx_p" id="S3.SS3.p3.1">In July 2024 (when Bluesky had 6 million users), it was possible to maintain a real-time copy of all user repositories on a single server for US$153 per month <cite class="ltx_cite ltx_citemacro_citep">(Newbold, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib44" title="">2024a</a>)</cite> – expensive for a hobby project, but easily affordable by many organizations. This figure includes repository storage and the inbound bandwidth for fetching records from PDSes, but not the computational resources to build and serve summary indexes from that data.</p> </div> <div class="ltx_para" id="S3.SS3.p4"> <p class="ltx_p" id="S3.SS3.p4.1">Due to the higher cost, we expect that there will be fewer hobbyist indexers than self-hosted PDSes. Nevertheless, as Bluesky grows, there are likely to be multiple professionally-run indexers for various purposes. For example, a company that performs sentiment analysis on social media activity about brands could easily create a whole-network index that provides insights to their clients. Web search engines can incorporate Bluesky activity into their indexes, and archivists such as the Internet Archive can preserve the activity for posterity.</p> </div> <div class="ltx_para" id="S3.SS3.p5"> <p class="ltx_p" id="S3.SS3.p5.1">The indexing infrastructure operated by Bluesky Social PBC is illustrated in Figure <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.F1" title="Figure 1 ‣ 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_tag">1</span></a>. It is composed of multiple services that have integration points for external services.</p> </div> <section class="ltx_subsubsection" id="S3.SS3.SSS1"> <h4 class="ltx_title ltx_title_subsubsection"> <span class="ltx_tag ltx_tag_subsubsection">3.3.1. </span>The Relay</h4> <div class="ltx_para" id="S3.SS3.SSS1.p1"> <p class="ltx_p" id="S3.SS3.SSS1.p1.1">The first component is the <em class="ltx_emph ltx_font_italic" id="S3.SS3.SSS1.p1.1.1">Relay</em>, which crawls the user repositories on all known PDSes and consumes the streams of updates that they produce. The Relay checks the signatures and Merkle tree proofs on updates, and maintains its own replica of each repository. From this information, the Relay creates the <em class="ltx_emph ltx_font_italic" id="S3.SS3.SSS1.p1.1.2">firehose</em>: an aggregated stream of updates that notifies subscribers whenever records are added or deleted in any of the known repositories. Normally the WebSocket connection to PDSes provides the relay with low-latency notifications of repository changes, but in case of network interruptions the relay can also periodically re-crawl repositories and compare them to its local replica to determine what records have been added or deleted.</p> </div> <div class="ltx_para" id="S3.SS3.SSS1.p2"> <p class="ltx_p" id="S3.SS3.SSS1.p2.1">The firehose is publicly available. Consuming the firehose is an easier way of building an index over the whole network, compared to directly subscribing to the source PDSes, since the Relay performs some initial data cleaning (discarding malformed updates, filtering out illegal content and high-volume spam). The firehose includes Merkle proofs and signatures along with records, allowing subscribers to check that they are authentic.</p> </div> <div class="ltx_para" id="S3.SS3.SSS1.p3"> <p class="ltx_p" id="S3.SS3.SSS1.p3.1">The Relay does not interpret or index the records in repositories, but simply stores and forwards them. Any developers wanting to create a new social mode on top of atproto can define a new lexicon with new record types, and these records can be stored in existing repositories and aggregated in the firehose without requiring any changes to the Relay.</p> </div> <figure class="ltx_figure" id="S3.F2"> <div class="ltx_flex_figure"> <div class="ltx_flex_cell ltx_flex_size_1"><img alt="Refer to caption" class="ltx_graphics ltx_centering ltx_figure_panel ltx_img_landscape" height="150" id="S3.F2.g1" src="x2.png" width="830"/></div> <div class="ltx_flex_break"></div> <div class="ltx_flex_cell ltx_flex_size_1"><span class="ltx_ERROR ltx_centering ltx_figure_panel undefined" id="S3.F2.1">\Description</span></div> <div class="ltx_flex_break"></div> <div class="ltx_flex_cell ltx_flex_size_1"> <p class="ltx_p ltx_figure_panel ltx_align_center" id="S3.F2.2">Handle (e.g. nytimes.com) resolves to DID via DNS TXT record or HTTPS request. DID resolves to DID document via did:web or did:plc directory server.</p> </div> </div> <figcaption class="ltx_caption ltx_centering"><span class="ltx_tag ltx_tag_figure">Figure 2. </span>A handle resolves to a DID, and a DID resolves to a DID document, which in turn references the handle, DID, and the user’s public key. Icons from Flaticon.com.</figcaption> </figure> </section> <section class="ltx_subsubsection" id="S3.SS3.SSS2"> <h4 class="ltx_title ltx_title_subsubsection"> <span class="ltx_tag ltx_tag_subsubsection">3.3.2. </span>The App View</h4> <div class="ltx_para" id="S3.SS3.SSS2.p1"> <p class="ltx_p" id="S3.SS3.SSS2.p1.1">The App View is a service that consumes the firehose, and processes the records that are relevant to the Bluesky social app (records in the <span class="ltx_text ltx_font_typewriter" id="S3.SS3.SSS2.p1.1.1">com.atproto</span> and <span class="ltx_text ltx_font_typewriter" id="S3.SS3.SSS2.p1.1.2">app.bsky</span> lexicons). For example, the App View counts the number of likes on every post, and it collates the thread of replies to each post. The App View also maintains the set of followers for each user, and constructs the timeline containing the posts by the accounts that each user is following. It then offers a web service through which this information can be queried. When a record contains references to images, the App View fetches those files from the original PDS, resizes them if necessary to reduce the file size, and makes them available via a content delivery network (CDN).</p> </div> <div class="ltx_para" id="S3.SS3.SSS2.p2"> <p class="ltx_p" id="S3.SS3.SSS2.p2.1">To display this information in the user’s client app, the client queries the user’s own PDS, which then fetches the necessary data from an App View. The App View is also responsible for enforcing moderation controls: for example, if one user has blocked another, and one of the users’ repositories contains a record of an interaction that should not have been allowed due to the block, then the App View drops that interaction so that nobody can see it in the client apps. This behavior is consistent with how blocking works on Twitter/X <cite class="ltx_cite ltx_citemacro_citep">(X Help Center, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib61" title="">[n. d.]</a>)</cite>, and it is also the reason why blocks are public records in Bluesky: every protocol-conforming App View needs to know who is blocking who in order to enforce the block <cite class="ltx_cite ltx_citemacro_citep">(Bluesky Social PBC, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib14" title="">2023h</a>; Newbold, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib43" title="">2023</a>)</cite>. If users are unhappy with the moderation rules applied by the App View operated by Bluesky Social PBC, it is always possible for third parties to operate alternative App Views that index the same firehose and present the data in a different way.</p> </div> <div class="ltx_para" id="S3.SS3.SSS2.p3"> <p class="ltx_p" id="S3.SS3.SSS2.p3.1">Other social modes built upon atproto require their own App View services to interpret and index the records in users’ repositories as required. The PDSes and relay can be reused.</p> </div> </section> </section> <section class="ltx_subsection" id="S3.SS4"> <h3 class="ltx_title ltx_title_subsection"> <span class="ltx_tag ltx_tag_subsection">3.4. </span>Labelers and Feed Generators</h3> <div class="ltx_para" id="S3.SS4.p1"> <p class="ltx_p" id="S3.SS4.p1.1">Relay and App View aim to provide a mostly “unopinionated” service: they compute indexes over repositories in a neutral way, without attempting to rank or classify content. However, a good user experience also requires “opinionated” judgements for the purposes of content filtering (e.g. detecting sexually explicit images or spam) and curation (e.g. selecting posts on a particular topic).</p> </div> <div class="ltx_para" id="S3.SS4.p2"> <p class="ltx_p" id="S3.SS4.p2.1">The AT Protocol separates out the “opinionated” aspects of the system into separate services: <em class="ltx_emph ltx_font_italic" id="S3.SS4.p2.1.1">labelers</em> and <em class="ltx_emph ltx_font_italic" id="S3.SS4.p2.1.2">feed generators</em>. These services typically take the firehose as their input. Labelers produce a stream of judgements about content (e.g. “this post is spam”), whereas feed generators return a list of post IDs they have selected for inclusion in a custom feed. Users can choose in their client app which feeds and which labelers they want to use. The output of labelers is consumed by App Views or PDSes in order to apply content filtering <cite class="ltx_cite ltx_citemacro_citep">(Bluesky Social PBC, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib10" title="">2023d</a>)</cite>. For a feed generator, an App View expands the post IDs into full posts before sending them to the client app of users who have subscribed to that feed.</p> </div> <div class="ltx_para" id="S3.SS4.p3"> <p class="ltx_p" id="S3.SS4.p3.1">Having labeler and feed generator services that are separate from App Views has several advantages:</p> <ul class="ltx_itemize" id="S3.I1"> <li class="ltx_item" id="S3.I1.i1" style="list-style-type:none;"> <span class="ltx_tag ltx_tag_item">•</span> <div class="ltx_para" id="S3.I1.i1.p1"> <p class="ltx_p" id="S3.I1.i1.p1.1">Anyone can run such services, which enables a pluralistic ecosystem in which different parties may make different judgements about the same piece of content. Users, as well as the operators of App Views and PDSes, can decide whose judgements they want to trust, and it is easy for them to switch to alternative labeling and feed generation services if their current providers fail to meet their expectations.</p> </div> </li> <li class="ltx_item" id="S3.I1.i2" style="list-style-type:none;"> <span class="ltx_tag ltx_tag_item">•</span> <div class="ltx_para" id="S3.I1.i2.p1"> <p class="ltx_p" id="S3.I1.i2.p1.1">It becomes easier to set up alternative App View providers: since any App View can consume the publicly available output from labelers and feed generators, there is less pressure for each App View to develop its own content filtering infrastructure. Having alternative App Views is important for a healthy, decentralized marketplace.</p> </div> </li> </ul> </div> <div class="ltx_para" id="S3.SS4.p4"> <p class="ltx_p" id="S3.SS4.p4.1">Feed generators can be implemented using our starter kit <cite class="ltx_cite ltx_citemacro_citep">(Bluesky Social PBC, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib8" title="">2023b</a>)</cite>, or using a third-party service such as Skyfeed <cite class="ltx_cite ltx_citemacro_citep">(Bluesky Social PBC, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib11" title="">2023e</a>)</cite>.</p> </div> </section> <section class="ltx_subsection" id="S3.SS5"> <h3 class="ltx_title ltx_title_subsection"> <span class="ltx_tag ltx_tag_subsection">3.5. </span>User Identity</h3> <div class="ltx_para" id="S3.SS5.p1"> <p class="ltx_p" id="S3.SS5.p1.1">The DNS-based user identity in atproto is decoupled from hosting and indexing. Anybody owning a domain name can issue subdomains as atproto handles, and this does not require running a PDS or any other service besides DNS.</p> </div> <div class="ltx_para" id="S3.SS5.p2"> <p class="ltx_p" id="S3.SS5.p2.4">Handles can change, but every Bluesky/atproto account also has an immutable, unique identifier: a <em class="ltx_emph ltx_font_italic" id="S3.SS5.p2.4.1">decentralized ID</em> or <em class="ltx_emph ltx_font_italic" id="S3.SS5.p2.4.2">DID</em>, which is a URI starting with the prefix “<span class="ltx_text ltx_font_typewriter" id="S3.SS5.p2.4.3">did:</span>”. For example, when a record in user <math alttext="A" class="ltx_Math" display="inline" id="S3.SS5.p2.1.m1.1"><semantics id="S3.SS5.p2.1.m1.1a"><mi id="S3.SS5.p2.1.m1.1.1" xref="S3.SS5.p2.1.m1.1.1.cmml">A</mi><annotation-xml encoding="MathML-Content" id="S3.SS5.p2.1.m1.1b"><ci id="S3.SS5.p2.1.m1.1.1.cmml" xref="S3.SS5.p2.1.m1.1.1">𝐴</ci></annotation-xml><annotation encoding="application/x-tex" id="S3.SS5.p2.1.m1.1c">A</annotation><annotation encoding="application/x-llamapun" id="S3.SS5.p2.1.m1.1d">italic_A</annotation></semantics></math>’s repository indicates that <math alttext="A" class="ltx_Math" display="inline" id="S3.SS5.p2.2.m2.1"><semantics id="S3.SS5.p2.2.m2.1a"><mi id="S3.SS5.p2.2.m2.1.1" xref="S3.SS5.p2.2.m2.1.1.cmml">A</mi><annotation-xml encoding="MathML-Content" id="S3.SS5.p2.2.m2.1b"><ci id="S3.SS5.p2.2.m2.1.1.cmml" xref="S3.SS5.p2.2.m2.1.1">𝐴</ci></annotation-xml><annotation encoding="application/x-tex" id="S3.SS5.p2.2.m2.1c">A</annotation><annotation encoding="application/x-llamapun" id="S3.SS5.p2.2.m2.1d">italic_A</annotation></semantics></math> is following <math alttext="B" class="ltx_Math" display="inline" id="S3.SS5.p2.3.m3.1"><semantics id="S3.SS5.p2.3.m3.1a"><mi id="S3.SS5.p2.3.m3.1.1" xref="S3.SS5.p2.3.m3.1.1.cmml">B</mi><annotation-xml encoding="MathML-Content" id="S3.SS5.p2.3.m3.1b"><ci id="S3.SS5.p2.3.m3.1.1.cmml" xref="S3.SS5.p2.3.m3.1.1">𝐵</ci></annotation-xml><annotation encoding="application/x-tex" id="S3.SS5.p2.3.m3.1c">B</annotation><annotation encoding="application/x-llamapun" id="S3.SS5.p2.3.m3.1d">italic_B</annotation></semantics></math>, that record contains <math alttext="B" class="ltx_Math" display="inline" id="S3.SS5.p2.4.m4.1"><semantics id="S3.SS5.p2.4.m4.1a"><mi id="S3.SS5.p2.4.m4.1.1" xref="S3.SS5.p2.4.m4.1.1.cmml">B</mi><annotation-xml encoding="MathML-Content" id="S3.SS5.p2.4.m4.1b"><ci id="S3.SS5.p2.4.m4.1.1.cmml" xref="S3.SS5.p2.4.m4.1.1">𝐵</ci></annotation-xml><annotation encoding="application/x-tex" id="S3.SS5.p2.4.m4.1c">B</annotation><annotation encoding="application/x-llamapun" id="S3.SS5.p2.4.m4.1d">italic_B</annotation></semantics></math>’s DID; this allows a user to change their handle without affecting their social graph. DIDs are a recent W3C standard <cite class="ltx_cite ltx_citemacro_citep">(Sporny et al<span class="ltx_text">.</span>, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib52" title="">2022</a>)</cite>.</p> </div> <div class="ltx_para" id="S3.SS5.p3"> <p class="ltx_p" id="S3.SS5.p3.1">Moreover, we want a user to be able to migrate to a different PDS without changing either their DID or their handle. DIDs provide a mechanism for <em class="ltx_emph ltx_font_italic" id="S3.SS5.p3.1.1">resolving</em> a DID into a <em class="ltx_emph ltx_font_italic" id="S3.SS5.p3.1.2">DID document</em>, a JSON document containing information about the user identified by that DID, as illustrated in Figure <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.F2" title="Figure 2 ‣ 3.3.1. The Relay ‣ 3.3. Indexing Infrastructure ‣ 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_tag">2</span></a>. In atproto, a DID document specifies the handle of the user, the URL of their PDS, and the public key that is used to sign the Merkle tree root of their repository every time they add or delete a record. To change their handle or their PDS, the user needs to update their DID document to the new value.</p> </div> <div class="ltx_para" id="S3.SS5.p4"> <p class="ltx_p" id="S3.SS5.p4.1">To prove ownership of a handle, the user must have a bidirectional link between their DID and their domain name handle, as shown in Figure <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#S3.F2" title="Figure 2 ‣ 3.3.1. The Relay ‣ 3.3. Indexing Infrastructure ‣ 3. The AT Protocol Architecture ‣ Bluesky and the AT Protocol: Usable Decentralized Social Media"><span class="ltx_text ltx_ref_tag">2</span></a>:</p> <ul class="ltx_itemize" id="S3.I2"> <li class="ltx_item" id="S3.I2.i1" style="list-style-type:none;"> <span class="ltx_tag ltx_tag_item">•</span> <div class="ltx_para" id="S3.I2.i1.p1"> <p class="ltx_p" id="S3.I2.i1.p1.1">A link from the handle to the DID is established either by storing the DID in a DNS TXT record on that domain name, or by returning the DID in response to a HTTPS request to a <span class="ltx_text ltx_font_typewriter" id="S3.I2.i1.p1.1.1">/.well-known/</span> URL on that domain name <cite class="ltx_cite ltx_citemacro_citep">(Liu, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib40" title="">2023</a>)</cite>.</p> </div> </li> <li class="ltx_item" id="S3.I2.i2" style="list-style-type:none;"> <span class="ltx_tag ltx_tag_item">•</span> <div class="ltx_para" id="S3.I2.i2.p1"> <p class="ltx_p" id="S3.I2.i2.p1.1">A link from the DID to the handle is established by including the handle in the DID document that is returned when the DID is resolved.</p> </div> </li> </ul> <p class="ltx_p" id="S3.SS5.p4.2">The App View periodically checks these bidirectional links, and invalidates the handle if either is broken. Provided that the App View is honest and takes measures to protect against DNS poisoning attacks (perhaps using DNSSEC when available), this approach prevents users from impersonating domains that they do not own.</p> </div> <section class="ltx_subsubsection" id="S3.SS5.SSS1"> <h4 class="ltx_title ltx_title_subsubsection"> <span class="ltx_tag ltx_tag_subsubsection">3.5.1. </span>Resolving DID documents</h4> <div class="ltx_para" id="S3.SS5.SSS1.p1"> <p class="ltx_p" id="S3.SS5.SSS1.p1.1">The DID specification <cite class="ltx_cite ltx_citemacro_citep">(Sporny et al<span class="ltx_text">.</span>, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib52" title="">2022</a>)</cite> does not directly specify the mechanism for resolving a DID into a DID document. Rather, the first substring after <span class="ltx_text ltx_font_typewriter" id="S3.SS5.SSS1.p1.1.1">did:</span> in a DID indicates the <em class="ltx_emph ltx_font_italic" id="S3.SS5.SSS1.p1.1.2">DID method</em>, and the specification of the DID method defines the protocol for obtaining the DID document. Hundreds of DID methods have been defined <cite class="ltx_cite ltx_citemacro_citep">(Steele and Sporny, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib55" title="">2023</a>)</cite>, many of which are dependent on specific blockchains or other external systems. To avoid atproto implementations having to support so many resolution methods, our services currently only accept DIDs based on either <span class="ltx_text ltx_font_typewriter" id="S3.SS5.SSS1.p1.1.3">did:web</span> (defined by the the W3C Credentials Community Group <cite class="ltx_cite ltx_citemacro_citep">(Gribneau et al<span class="ltx_text">.</span>, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib29" title="">2023</a>)</cite>) or <span class="ltx_text ltx_font_typewriter" id="S3.SS5.SSS1.p1.1.4">did:plc</span> (defined by ourselves for atproto <cite class="ltx_cite ltx_citemacro_citep">(Holmgren et al<span class="ltx_text">.</span>, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib33" title="">2023</a>)</cite>). Support for more DID methods might be added in the future.</p> </div> <div class="ltx_para" id="S3.SS5.SSS1.p2"> <p class="ltx_p" id="S3.SS5.SSS1.p2.1">The <span class="ltx_text ltx_font_typewriter" id="S3.SS5.SSS1.p2.1.1">did:web</span> method is very simple: the part of the DID after <span class="ltx_text ltx_font_typewriter" id="S3.SS5.SSS1.p2.1.2">did:web:</span> is a domain name, and the DID document is resolved by making a HTTPS request to a <span class="ltx_text ltx_font_typewriter" id="S3.SS5.SSS1.p2.1.3">/.well-known/</span> URL on that domain name. The security of a <span class="ltx_text ltx_font_typewriter" id="S3.SS5.SSS1.p2.1.4">did:web</span> identity therefore assumes that the web hosting provider for that domain is trusted, and also relies on trusting the TLS certificate authorities that may authenticate the HTTPS request.</p> </div> <div class="ltx_para" id="S3.SS5.SSS1.p3"> <p class="ltx_p" id="S3.SS5.SSS1.p3.1"><span class="ltx_text ltx_font_typewriter" id="S3.SS5.SSS1.p3.1.1">did:web</span> identities are therefore similar to domain name handles, with the difference that the name cannot be changed, since a DID is an immutable identifier. This makes <span class="ltx_text ltx_font_typewriter" id="S3.SS5.SSS1.p3.1.2">did:web</span> appropriate for the identity of organizations that are already strongly linked to a particular domain name. For most users, <span class="ltx_text ltx_font_typewriter" id="S3.SS5.SSS1.p3.1.3">did:plc</span> is more appropriate, since it uses a domain name only as a handle that can be changed.</p> </div> </section> <section class="ltx_subsubsection" id="S3.SS5.SSS2"> <h4 class="ltx_title ltx_title_subsubsection"> <span class="ltx_tag ltx_tag_subsubsection">3.5.2. </span>The did:plc DID method</h4> <div class="ltx_para" id="S3.SS5.SSS2.p1"> <p class="ltx_p" id="S3.SS5.SSS2.p1.1">When a user creates an account on the Bluesky social app, they are by default assigned a DID of the form <span class="ltx_text ltx_font_typewriter" id="S3.SS5.SSS2.p1.1.1">did:plc:eclio37ymobqex2ncko63h4r</span>, where the string after the prefix <span class="ltx_text ltx_font_typewriter" id="S3.SS5.SSS2.p1.1.2">did:plc:</span> is the SHA256 hash of the initial DID document, truncated to 120 bits and encoded using base32 <cite class="ltx_cite ltx_citemacro_citep">(Holmgren et al<span class="ltx_text">.</span>, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib33" title="">2023</a>)</cite>. A DID of this form can be resolved to the corresponding DID document by querying a server at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://plc.directory/" title="">https://plc.directory/</a>, which is currently operated by Bluesky Social PBC; in the future we plan to establish a consortium of independent operators that collectively provide the PLC directory service.</p> </div> <div class="ltx_para" id="S3.SS5.SSS2.p2"> <p class="ltx_p" id="S3.SS5.SSS2.p2.1">The PLC directory server plays an authoritative role similar to the DNS root servers, but it is mostly untrusted because PLC DID documents are self-certifying. If the DID document has not changed since its initial creation, it is easy to verify that a DID has been correctly resolved to a DID document by recomputing its hash. To support changes to the DID document, the initial version of a user’s DID document contains a public key that is authorized to sign a new version of the DID document. Any new version of the DID document is only valid if it has been signed by the key in the previous version. The directory returns all DID document versions for a given DID, allowing anybody to check the chain of signatures.</p> </div> <div class="ltx_para" id="S3.SS5.SSS2.p3"> <p class="ltx_p" id="S3.SS5.SSS2.p3.1">If the directory server were to be malicious, it would not be able to modify any DID documents – it could only omit valid DID document versions from its responses, or fail to respond at all. Moreover, if there were to be a fork in DID document history such that two correctly signed successor versions for some DID document exist, the directory server could choose which one of these forks to serve. To mitigate such attacks, we anticipate that a future version of the PLC directory will use an append-only transparency log similar to certificate transparency <cite class="ltx_cite ltx_citemacro_citep">(Laurie, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib36" title="">2014</a>)</cite>.</p> </div> </section> <section class="ltx_subsubsection" id="S3.SS5.SSS3"> <h4 class="ltx_title ltx_title_subsubsection"> <span class="ltx_tag ltx_tag_subsubsection">3.5.3. </span>Authentication</h4> <div class="ltx_para" id="S3.SS5.SSS3.p1"> <p class="ltx_p" id="S3.SS5.SSS3.p1.1">In principle, the cryptographic keys for signing repository updates and DID document updates can be held directly on the user’s devices, e.g. using a cryptocurrency wallet, in order to minimize trust in servers. However, we believe that such manual key management is not appropriate for most users, since there is a significant risk of the keys being compromised or lost.</p> </div> <div class="ltx_para" id="S3.SS5.SSS3.p2"> <p class="ltx_p" id="S3.SS5.SSS3.p2.1">The Bluesky PDSes therefore hold these signing keys custodially on behalf of users, and users log in to their home PDS via username and password. This provides a familiar user experience to users, and enables standard features such as password reset by email. The AT Protocol does not make any assumptions about how PDSes authenticate their users; other PDS operators are free to use different methods, including user-managed keys.</p> </div> </section> </section> </section> <section class="ltx_section" id="S4"> <h2 class="ltx_title ltx_title_section"> <span class="ltx_tag ltx_tag_section">4. </span>Related Work</h2> <div class="ltx_para" id="S4.p1"> <p class="ltx_p" id="S4.p1.1">Several other decentralized social networks are in development. We believe that there is no single optimal design: different systems make different trade-offs, and are therefore suitable for different purposes. Bluesky and the AT Protocol aim to provide a good user experience by providing a global view over the whole network, making moderation a first-class concern, and having clients that are lightweight and easy to use. For example, conversation threads include all replies (unless removed by moderation), regardless of the server on which they were posted. To achieve this goal we rely on an indexing infrastructure that is more centralized than some other designs. However, we emphasize that there can be multiple competing indexers, and third-party client apps are free to show data from whichever indexers they wish.</p> </div> <div class="ltx_para" id="S4.p2"> <p class="ltx_p" id="S4.p2.1">In 2021 some of our team published a review of the decentralized social ecosystem <cite class="ltx_cite ltx_citemacro_citep">(Graber, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib27" title="">2021</a>)</cite>. In this section we summarize some recent developments that have happened since, and we refer to the review for a more comprehensive comparison of protocols and systems.</p> </div> <div class="ltx_para" id="S4.p3"> <p class="ltx_p" id="S4.p3.1">Many decentralized social networking projects have ideas in common. For example, the idea of using DNS domain names as usernames also appears in Nostr <cite class="ltx_cite ltx_citemacro_citep">(fiatjaf and Dilger, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib25" title="">2021</a>)</cite>. An atproto PDS has similarities to Git repository hosting (e.g. GitHub/Gitlab) or a Solid pod <cite class="ltx_cite ltx_citemacro_citep">(Solid Project, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib51" title="">2024</a>)</cite>.</p> </div> <section class="ltx_subsection" id="S4.SS1"> <h3 class="ltx_title ltx_title_subsection"> <span class="ltx_tag ltx_tag_subsection">4.1. </span>Scuttlebutt</h3> <div class="ltx_para" id="S4.SS1.p1"> <p class="ltx_p" id="S4.SS1.p1.1">Secure Scuttlebutt (SSB) is a peer-to-peer social networking protocol <cite class="ltx_cite ltx_citemacro_citep">(Scu, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib2" title="">2023</a>)</cite>; Manyverse <cite class="ltx_cite ltx_citemacro_citep">(The Manyverse Authors, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib58" title="">2024</a>)</cite> is a social application built upon the SSB protocol. It optionally uses relay servers called <em class="ltx_emph ltx_font_italic" id="S4.SS1.p1.1.1">pubs</em> to store messages from peers that are offline, and to enable user discovery. The client software downloads the feeds from accounts that the user is explicitly following, and from accounts followed by followed accounts (up to three hops by default). This can require significant amounts of storage and bandwidth on the client.</p> </div> <div class="ltx_para" id="S4.SS1.p2"> <p class="ltx_p" id="S4.SS1.p2.1">Any messages from users outside of the third-degree network are not shown, which effectively limits the set of people who can mention or reply to a user to the third-degree network. This deliberate design decision is intended to reduce moderation problems by prioritizing conversation between people who already know each other <cite class="ltx_cite ltx_citemacro_citep">(Staltz, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib54" title="">2023</a>)</cite>. In contrast, Bluesky/atproto are designed to allow anybody to talk to anybody else. This requires more explicit moderation to manage unwanted content, but we believe it also enables serendipity and is a prerequisite for any “digital town square”.</p> </div> <div class="ltx_para" id="S4.SS1.p3"> <p class="ltx_p" id="S4.SS1.p3.1">Since SSB is built upon append-only logs and gossip replication, it is not possible to delete content once it has been posted <cite class="ltx_cite ltx_citemacro_citep">(The Manyverse Authors, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib56" title="">2021</a>)</cite>. User identity is tied to a cryptographic key on the user’s device, requiring manual key management for moving to another device. Posting from multiple devices is not possible, as sharing the same key between devices can make an account unrecoverable <cite class="ltx_cite ltx_citemacro_citep">(The Manyverse Authors, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib57" title="">2022</a>)</cite>. A successor protocol to SSB, called PZP, is designed to address these issues <cite class="ltx_cite ltx_citemacro_citep">(Karlsson, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib35" title="">2024</a>)</cite>.</p> </div> </section> <section class="ltx_subsection" id="S4.SS2"> <h3 class="ltx_title ltx_title_subsection"> <span class="ltx_tag ltx_tag_subsection">4.2. </span>Nostr</h3> <div class="ltx_para" id="S4.SS2.p1"> <p class="ltx_p" id="S4.SS2.p1.1">Nostr also began as a revision of SSB, replacing the append-only logs with individual signed messages <cite class="ltx_cite ltx_citemacro_citep">(Henshaw-Plath, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib32" title="">2023</a>)</cite>. It leans more heavily on relay servers instead of peer-to-peer communication: clients publish and fetch messages on relays of their choice, and there is no federation among relays <cite class="ltx_cite ltx_citemacro_citep">(fiatjaf, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib24" title="">2024</a>)</cite>. The protocol is deliberately simple, and it prioritizes censorship resistance over moderation: relays can block users, but users can always move to a new relay, and use multiple relays at the same time. Communication (e.g. reply threads) is only possible between users who have at least one relay in common. Although some services index the whole Nostr network, these indexes are not used for user-to-user interaction. As a result, it is unpredictable who will see which message. The creator of Nostr writes: “there are no guarantees of anything […] to use Nostr one must embrace the inherent chaos” <cite class="ltx_cite ltx_citemacro_citep">(fiatjaf, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib23" title="">2023</a>)</cite>. Key management is manual in Nostr, and facilities for key rotation are still under discussion <cite class="ltx_cite ltx_citemacro_citep">(Ball et al<span class="ltx_text">.</span>, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib5" title="">2022</a>)</cite>.</p> </div> </section> <section class="ltx_subsection" id="S4.SS3"> <h3 class="ltx_title ltx_title_subsection"> <span class="ltx_tag ltx_tag_subsection">4.3. </span>Farcaster and blockchain-based systems</h3> <div class="ltx_para" id="S4.SS3.p1"> <p class="ltx_p" id="S4.SS3.p1.1">Farcaster <cite class="ltx_cite ltx_citemacro_citep">(Warpcast, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib60" title="">2024</a>)</cite> has some architectural similarities to Bluesky/atproto, although it was developed independently. It has storage servers called <em class="ltx_emph ltx_font_italic" id="S4.SS3.p1.1.1">hubs</em>, which store the state of the entire network similarly to an atproto Relay, and it has a concept of <em class="ltx_emph ltx_font_italic" id="S4.SS3.p1.1.2">hosted app servers</em> that are similar to our App View <cite class="ltx_cite ltx_citemacro_citep">(Srinivasan, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib53" title="">2023</a>)</cite>. Farcaster user IDs are similar to our DIDs, and they are mapped to public keys using a smart contract on the Ethereum Optimism blockchain that is functionally similar to our PLC directory. Usernames can be either ENS names <cite class="ltx_cite ltx_citemacro_citep">(ENS Labs Limited, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib20" title="">2024</a>)</cite>, or names within an off-chain namespace managed centrally by Farcaster, similarly to <span class="ltx_text ltx_font_typewriter" id="S4.SS3.p1.1.3">.bsky.social</span> subdomains in Bluesky <cite class="ltx_cite ltx_citemacro_citep">(Farcaster Team, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib22" title="">2024</a>)</cite>.</p> </div> <div class="ltx_para" id="S4.SS3.p2"> <p class="ltx_p" id="S4.SS3.p2.1">A difference is that Farcaster has no equivalent to atproto’s PDS; instead, client apps publish signed messages directly to a hub, and hubs synchronize messages using a convergent gossip protocol. Users must pay in cryptocurrency to register their public key, and for hub data storage (at the time of writing, Ethereum equivalent to $5 USD/year); when a user exceeds their storage allowance, old messages are deleted. Fees are currently collected centrally by the Farcaster team <cite class="ltx_cite ltx_citemacro_citep">(Heart et al<span class="ltx_text">.</span>, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib31" title="">2023</a>)</cite>. In contrast, the AT Protocol does not specify storage limitations, but leaves it to providers of PDS and indexing services to define their own business model and abuse-prevention policies. We also prefer to avoid a dependency on a cryptocurrency.</p> </div> <div class="ltx_para" id="S4.SS3.p3"> <p class="ltx_p" id="S4.SS3.p3.1">The Lens protocol <cite class="ltx_cite ltx_citemacro_citep">(Lens Protocol, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib39" title="">2024</a>)</cite> is more strongly blockchain-based than Farcaster: it even stores high-volume user actions such as posts and follows on Polygon, a proof-of-stake blockchain. DSNP takes a similar approach <cite class="ltx_cite ltx_citemacro_citep">(Project Liberty, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib47" title="">2020</a>)</cite>. Placing high-volume events directly on a blockchain incurs orders of magnitude higher per-user costs than atproto, and is likely to run into scalability limits as the number of users grows. Lens is adopting a layer-3 blockchain that provides better scalability and lower cost <cite class="ltx_cite ltx_citemacro_citep">(Lens Protocol, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib38" title="">2023</a>)</cite>, but weaker security properties. Linking social accounts to cryptocurrency wallets and NFTs enables users to monetize their content, but this is not a goal of atproto.</p> </div> </section> <section class="ltx_subsection" id="S4.SS4"> <h3 class="ltx_title ltx_title_subsection"> <span class="ltx_tag ltx_tag_subsection">4.4. </span>ActivityPub and Mastodon</h3> <div class="ltx_para" id="S4.SS4.p1"> <p class="ltx_p" id="S4.SS4.p1.1">ActivityPub <cite class="ltx_cite ltx_citemacro_citep">(Lemmer-Webber et al<span class="ltx_text">.</span>, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib37" title="">2018</a>)</cite> is a W3C standard for social networking, and Mastodon <cite class="ltx_cite ltx_citemacro_citep">(Mastodon gGmbH, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib42" title="">2024</a>)</cite> is its most popular implementation. Mastodon gives a lot of power to server administrators: for example, a server admin can choose to block another server, preventing all communication between users on those servers. There is a degree of lock-in to a server because moving to another server is intrusive: the username changes, moving posts to the new server currently requires an experimental command-line tool <cite class="ltx_cite ltx_citemacro_citep">(SilverWolf32 et al<span class="ltx_text">.</span>, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib50" title="">2019</a>; Tokyo Outsider, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib59" title="">2023</a>)</cite>, and other users’ replies to those posts are lost. If the old server is not reachable – for example, because its admin shut it down without warning or because its domain was seized <cite class="ltx_cite ltx_citemacro_citep">(Erin, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib21" title="">2024</a>)</cite> – the user’s social graph is lost. These risks can be mitigated by self-hosting; managed providers exist <cite class="ltx_cite ltx_citemacro_citep">(Grow your own services, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib30" title="">2024</a>)</cite>, but they still require some expertise and cost money. The AT Protocol separates the roles of moderation and hosting, and aims to make it easier to change providers without losing any data.</p> </div> <div class="ltx_para" id="S4.SS4.p2"> <p class="ltx_p" id="S4.SS4.p2.5">When user <math alttext="A" class="ltx_Math" display="inline" id="S4.SS4.p2.1.m1.1"><semantics id="S4.SS4.p2.1.m1.1a"><mi id="S4.SS4.p2.1.m1.1.1" xref="S4.SS4.p2.1.m1.1.1.cmml">A</mi><annotation-xml encoding="MathML-Content" id="S4.SS4.p2.1.m1.1b"><ci id="S4.SS4.p2.1.m1.1.1.cmml" xref="S4.SS4.p2.1.m1.1.1">𝐴</ci></annotation-xml><annotation encoding="application/x-tex" id="S4.SS4.p2.1.m1.1c">A</annotation><annotation encoding="application/x-llamapun" id="S4.SS4.p2.1.m1.1d">italic_A</annotation></semantics></math> follows user <math alttext="B" class="ltx_Math" display="inline" id="S4.SS4.p2.2.m2.1"><semantics id="S4.SS4.p2.2.m2.1a"><mi id="S4.SS4.p2.2.m2.1.1" xref="S4.SS4.p2.2.m2.1.1.cmml">B</mi><annotation-xml encoding="MathML-Content" id="S4.SS4.p2.2.m2.1b"><ci id="S4.SS4.p2.2.m2.1.1.cmml" xref="S4.SS4.p2.2.m2.1.1">𝐵</ci></annotation-xml><annotation encoding="application/x-tex" id="S4.SS4.p2.2.m2.1c">B</annotation><annotation encoding="application/x-llamapun" id="S4.SS4.p2.2.m2.1d">italic_B</annotation></semantics></math>, <math alttext="A" class="ltx_Math" display="inline" id="S4.SS4.p2.3.m3.1"><semantics id="S4.SS4.p2.3.m3.1a"><mi id="S4.SS4.p2.3.m3.1.1" xref="S4.SS4.p2.3.m3.1.1.cmml">A</mi><annotation-xml encoding="MathML-Content" id="S4.SS4.p2.3.m3.1b"><ci id="S4.SS4.p2.3.m3.1.1.cmml" xref="S4.SS4.p2.3.m3.1.1">𝐴</ci></annotation-xml><annotation encoding="application/x-tex" id="S4.SS4.p2.3.m3.1c">A</annotation><annotation encoding="application/x-llamapun" id="S4.SS4.p2.3.m3.1d">italic_A</annotation></semantics></math>’s server asks <math alttext="B" class="ltx_Math" display="inline" id="S4.SS4.p2.4.m4.1"><semantics id="S4.SS4.p2.4.m4.1a"><mi id="S4.SS4.p2.4.m4.1.1" xref="S4.SS4.p2.4.m4.1.1.cmml">B</mi><annotation-xml encoding="MathML-Content" id="S4.SS4.p2.4.m4.1b"><ci id="S4.SS4.p2.4.m4.1.1.cmml" xref="S4.SS4.p2.4.m4.1.1">𝐵</ci></annotation-xml><annotation encoding="application/x-tex" id="S4.SS4.p2.4.m4.1c">B</annotation><annotation encoding="application/x-llamapun" id="S4.SS4.p2.4.m4.1d">italic_B</annotation></semantics></math>’s server to send it notifications of <math alttext="B" class="ltx_Math" display="inline" id="S4.SS4.p2.5.m5.1"><semantics id="S4.SS4.p2.5.m5.1a"><mi id="S4.SS4.p2.5.m5.1.1" xref="S4.SS4.p2.5.m5.1.1.cmml">B</mi><annotation-xml encoding="MathML-Content" id="S4.SS4.p2.5.m5.1b"><ci id="S4.SS4.p2.5.m5.1.1.cmml" xref="S4.SS4.p2.5.m5.1.1">𝐵</ci></annotation-xml><annotation encoding="application/x-tex" id="S4.SS4.p2.5.m5.1c">B</annotation><annotation encoding="application/x-llamapun" id="S4.SS4.p2.5.m5.1d">italic_B</annotation></semantics></math>’s future posts via ActivityPub. This architecture has the advantage of not requiring a whole-network index. However, replies to a post notify the server of the original poster, but not necessarily every server that has a copy of the original post, leading to inconsistent reply threads on different servers. Notifications can be forwarded, but in the limit this leads to each server having a copy of the whole network, which would make it expensive to run a server. Viral posts can generate a lot of inbound requests to a server from people liking, replying, and boosting (reposting). In comparison, the Bluesky indexing infrastructure is also fairly expensive, but a PDS is cheap to run. Since users can choose their moderation preferences independently from their indexing provider (App View), we believe that the ecosystem can be healthy with a small number of indexing providers.</p> </div> </section> </section> <section class="ltx_section" id="S5"> <h2 class="ltx_title ltx_title_section"> <span class="ltx_tag ltx_tag_section">5. </span>Conclusions</h2> <div class="ltx_para" id="S5.p1"> <p class="ltx_p" id="S5.p1.1">Bluesky and the AT Protocol are a new approach to social media. Their architecture is based on the principle that every part of the system can be run by multiple competing providers, and users can switch providers with minimal friction (in particular, without changing username, and without losing any of their content or social graph). For example, anyone can write a client, host a PDS, index the network, or provide moderation services, and all of these services interoperate. Even though the majority of Bluesky services are currently operated by a single company, we nevertheless consider the system to be decentralized because it provides <em class="ltx_emph ltx_font_italic" id="S5.p1.1.1">credible exit</em> <cite class="ltx_cite ltx_citemacro_citep">(Newbold, <a class="ltx_ref" href="https://arxiv.org/html/2402.03239v2#bib.bib45" title="">2024b</a>)</cite>: if Bluesky Social PBC goes out of business or loses users’ trust, other providers can step in to provide an equivalent service using the same dataset and the same protocols.</p> </div> <div class="ltx_para" id="S5.p2"> <p class="ltx_p" id="S5.p2.1">While some decentralized systems prioritize censorship resistance, we believe that a good user experience requires explicitly addressing problematic content such as harassment and misinformation. We therefore make moderation a first-class concern that is handled separately from infrastructure hosting, and we provide strong mechanisms for users to control the content they see. Our open architecture allows a pluralistic system in which different users may choose different providers that uphold different values, while still allowing them to communicate and interoperate.</p> </div> </section> <section class="ltx_bibliography" id="bib"> <h2 class="ltx_title ltx_title_bibliography">References</h2> <ul class="ltx_biblist"> <li class="ltx_bibitem" id="bib.bib1"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">(1)</span> <span class="ltx_bibblock"> </span> </li> <li class="ltx_bibitem" id="bib.bib2"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Scu (2023)</span> <span class="ltx_bibblock"> 2023. </span> <span class="ltx_bibblock">Scuttlebutt Protocol Guide. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://ssbc.github.io/scuttlebutt-protocol-guide/" title="">https://ssbc.github.io/scuttlebutt-protocol-guide/</a> </span> </li> <li class="ltx_bibitem" id="bib.bib3"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Adida (2022)</span> <span class="ltx_bibblock"> Ben Adida. 2022. </span> <span class="ltx_bibblock">Don’t let federation make the experience suck. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://benlog.com/2022/12/28/dont-let-federation-make-the-experience-suck/" title="">https://benlog.com/2022/12/28/dont-let-federation-make-the-experience-suck/</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/W7CY-TF23" title="">https://perma.cc/W7CY-TF23</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib4"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Auvolat and Taïani (2019)</span> <span class="ltx_bibblock"> Alex Auvolat and François Taïani. 2019. </span> <span class="ltx_bibblock">Merkle Search Trees: Efficient State-Based CRDTs in Open Networks. In <em class="ltx_emph ltx_font_italic" id="bib.bib4.1.1">38th Symposium on Reliable Distributed Systems</em> <em class="ltx_emph ltx_font_italic" id="bib.bib4.2.2">(SRDS 2019)</em>. IEEE, 221–230. </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://doi.org/10.1109/srds47363.2019.00032" title="">https://doi.org/10.1109/srds47363.2019.00032</a> </span> </li> <li class="ltx_bibitem" id="bib.bib5"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Ball et al<span class="ltx_text" id="bib.bib5.2.2.1">.</span> (2022)</span> <span class="ltx_bibblock"> Cat Ball, fiatjaf, Kevin Smith, Vitor Pamplona, et al<span class="ltx_text" id="bib.bib5.3.1">.</span> 2022. </span> <span class="ltx_bibblock">Nostr issue #45: Key distribution, rotation, and recovery. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://github.com/nostr-protocol/nostr/issues/45" title="">https://github.com/nostr-protocol/nostr/issues/45</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/26TW-ME48" title="">https://perma.cc/26TW-ME48</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib6"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Barabas et al<span class="ltx_text" id="bib.bib6.2.2.1">.</span> (2017)</span> <span class="ltx_bibblock"> Chelsea Barabas, Neha Narula, and Ethan Zuckerman. 2017. </span> <span class="ltx_bibblock"><em class="ltx_emph ltx_font_italic" id="bib.bib6.3.1">Defending Internet Freedom through Decentralization: Back to the Future?</em> </span> <span class="ltx_bibblock">Technical Report. MIT Media Lab. </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://dci.mit.edu/decentralizedweb" title="">https://dci.mit.edu/decentralizedweb</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/Q8CJ-D44Y" title="">https://perma.cc/Q8CJ-D44Y</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib7"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Bluesky Social PBC (2023a)</span> <span class="ltx_bibblock"> Bluesky Social PBC. 2023a. </span> <span class="ltx_bibblock">Algorithmic Choice with Custom Feeds. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://blueskyweb.xyz/blog/7-27-2023-custom-feeds" title="">https://blueskyweb.xyz/blog/7-27-2023-custom-feeds</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/Z6U4-VMY8" title="">https://perma.cc/Z6U4-VMY8</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib8"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Bluesky Social PBC (2023b)</span> <span class="ltx_bibblock"> Bluesky Social PBC. 2023b. </span> <span class="ltx_bibblock">ATProto Feed Generator. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://github.com/bluesky-social/feed-generator" title="">https://github.com/bluesky-social/feed-generator</a> </span> </li> <li class="ltx_bibitem" id="bib.bib9"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Bluesky Social PBC (2023c)</span> <span class="ltx_bibblock"> Bluesky Social PBC. 2023c. </span> <span class="ltx_bibblock">Bluesky Proposal 0001: User Lists, Reply-Gating, and Thread Moderation. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://github.com/bluesky-social/proposals/tree/main/0001-user-lists-replygating-and-thread-moderation" title="">https://github.com/bluesky-social/proposals/tree/main/0001-user-lists-replygating-and-thread-moderation</a> </span> </li> <li class="ltx_bibitem" id="bib.bib10"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Bluesky Social PBC (2023d)</span> <span class="ltx_bibblock"> Bluesky Social PBC. 2023d. </span> <span class="ltx_bibblock">Bluesky Proposal 0002: Labeling and Moderation Controls. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://github.com/bluesky-social/proposals/tree/main/0002-labeling-and-moderation-controls" title="">https://github.com/bluesky-social/proposals/tree/main/0002-labeling-and-moderation-controls</a> </span> </li> <li class="ltx_bibitem" id="bib.bib11"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Bluesky Social PBC (2023e)</span> <span class="ltx_bibblock"> Bluesky Social PBC. 2023e. </span> <span class="ltx_bibblock">Featured Community Project: SkyFeed. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://atproto.com/blog/feature-skyfeed" title="">https://atproto.com/blog/feature-skyfeed</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/AYR8-AY5K" title="">https://perma.cc/AYR8-AY5K</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib12"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Bluesky Social PBC (2023f)</span> <span class="ltx_bibblock"> Bluesky Social PBC. 2023f. </span> <span class="ltx_bibblock">Moderation in a Public Commons. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://blueskyweb.xyz/blog/6-23-2023-moderation-proposals" title="">https://blueskyweb.xyz/blog/6-23-2023-moderation-proposals</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/XFX2-CCFJ" title="">https://perma.cc/XFX2-CCFJ</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib13"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Bluesky Social PBC (2023g)</span> <span class="ltx_bibblock"> Bluesky Social PBC. 2023g. </span> <span class="ltx_bibblock">Purchase and Manage Domains Directly Through Bluesky. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://blueskyweb.xyz/blog/7-05-2023-namecheap" title="">https://blueskyweb.xyz/blog/7-05-2023-namecheap</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/QUA7-L8QJ" title="">https://perma.cc/QUA7-L8QJ</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib14"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Bluesky Social PBC (2023h)</span> <span class="ltx_bibblock"> Bluesky Social PBC. 2023h. </span> <span class="ltx_bibblock">Why are blocks on Bluesky public? </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://atproto.com/blog/block-implementation" title="">https://atproto.com/blog/block-implementation</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/2ZQX-KTNJ" title="">https://perma.cc/2ZQX-KTNJ</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib15"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Bluesky Social PBC (2024a)</span> <span class="ltx_bibblock"> Bluesky Social PBC. 2024a. </span> <span class="ltx_bibblock">AT Protocol Community Projects. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://atproto.com/community/projects" title="">https://atproto.com/community/projects</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/X88A-9XM4" title="">https://perma.cc/X88A-9XM4</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib16"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Bluesky Social PBC (2024b)</span> <span class="ltx_bibblock"> Bluesky Social PBC. 2024b. </span> <span class="ltx_bibblock">AT Protocol Specification. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://atproto.com/specs/atp" title="">https://atproto.com/specs/atp</a> </span> </li> <li class="ltx_bibitem" id="bib.bib17"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Bluesky Social PBC (2024c)</span> <span class="ltx_bibblock"> Bluesky Social PBC. 2024c. </span> <span class="ltx_bibblock">atproto lexicons. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://github.com/bluesky-social/atproto/tree/main/lexicons" title="">https://github.com/bluesky-social/atproto/tree/main/lexicons</a> </span> </li> <li class="ltx_bibitem" id="bib.bib18"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Bluesky Social PBC (2024d)</span> <span class="ltx_bibblock"> Bluesky Social PBC. 2024d. </span> <span class="ltx_bibblock">GitHub repositories. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://github.com/bluesky-social" title="">https://github.com/bluesky-social</a> </span> </li> <li class="ltx_bibitem" id="bib.bib19"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Bormann and Hoffman (2020)</span> <span class="ltx_bibblock"> Carsten Bormann and Paul Hoffman. 2020. </span> <span class="ltx_bibblock">RFC 8949: Concise Binary Object Representation (CBOR). </span> <span class="ltx_bibblock">IETF Standards Track. </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://datatracker.ietf.org/doc/html/rfc8949" title="">https://datatracker.ietf.org/doc/html/rfc8949</a> </span> </li> <li class="ltx_bibitem" id="bib.bib20"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">ENS Labs Limited (2024)</span> <span class="ltx_bibblock"> ENS Labs Limited. 2024. </span> <span class="ltx_bibblock">Ethereum Name Service. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://ens.domains/" title="">https://ens.domains/</a> </span> </li> <li class="ltx_bibitem" id="bib.bib21"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Erin (2024)</span> <span class="ltx_bibblock"> Erin. 2024. </span> <span class="ltx_bibblock">queer.af domain suspended without warning. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://akko.erincandescent.net/notice/AenoDMPN0SdVXSq9ZY" title="">https://akko.erincandescent.net/notice/AenoDMPN0SdVXSq9ZY</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/SNZ5-SMYQ" title="">https://perma.cc/SNZ5-SMYQ</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib22"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Farcaster Team (2024)</span> <span class="ltx_bibblock"> Farcaster Team. 2024. </span> <span class="ltx_bibblock">Farcaster Architecture. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://docs.farcaster.xyz/learn/architecture/overview" title="">https://docs.farcaster.xyz/learn/architecture/overview</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/7PDP-ATTH" title="">https://perma.cc/7PDP-ATTH</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib23"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">fiatjaf (2023)</span> <span class="ltx_bibblock"> fiatjaf. 2023. </span> <span class="ltx_bibblock">A vision for content discovery and relay usage for basic social-networking in Nostr. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://fiatjaf.com/3f106d31.html" title="">https://fiatjaf.com/3f106d31.html</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/9N8B-DLXW" title="">https://perma.cc/9N8B-DLXW</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib24"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">fiatjaf (2024)</span> <span class="ltx_bibblock"> fiatjaf. 2024. </span> <span class="ltx_bibblock">nostr - Notes and Other Stuff Transmitted by Relays. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://github.com/nostr-protocol/nostr" title="">https://github.com/nostr-protocol/nostr</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/6YCW-VERW" title="">https://perma.cc/6YCW-VERW</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib25"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">fiatjaf and Dilger (2021)</span> <span class="ltx_bibblock"> fiatjaf and Michael Dilger. 2021. </span> <span class="ltx_bibblock">NIP-05: Mapping Nostr keys to DNS-based internet identifiers. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://github.com/nostr-protocol/nips/blob/master/05.md" title="">https://github.com/nostr-protocol/nips/blob/master/05.md</a> </span> </li> <li class="ltx_bibitem" id="bib.bib26"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Filho (2024)</span> <span class="ltx_bibblock"> Gildásio Filho. 2024. </span> <span class="ltx_bibblock">deck.blue. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://deck.blue/" title="">https://deck.blue/</a> </span> </li> <li class="ltx_bibitem" id="bib.bib27"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Graber (2021)</span> <span class="ltx_bibblock"> Jay Graber. 2021. </span> <span class="ltx_bibblock">Ecosystem Review. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://gitlab.com/bluesky-community1/decentralized-ecosystem" title="">https://gitlab.com/bluesky-community1/decentralized-ecosystem</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/RJ2Y-H6YT" title="">https://perma.cc/RJ2Y-H6YT</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib28"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Graber (2023)</span> <span class="ltx_bibblock"> Jay Graber. 2023. </span> <span class="ltx_bibblock">Algorithmic choice. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://blueskyweb.xyz/blog/3-30-2023-algorithmic-choice" title="">https://blueskyweb.xyz/blog/3-30-2023-algorithmic-choice</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/WQR6-5QJF" title="">https://perma.cc/WQR6-5QJF</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib29"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Gribneau et al<span class="ltx_text" id="bib.bib29.2.2.1">.</span> (2023)</span> <span class="ltx_bibblock"> Christian Gribneau, Michael Prorock, Orie Steele, Oliver Terbu, Mike Xu, and Dmitri Zagidulin. 2023. </span> <span class="ltx_bibblock">did:web Method Specification. </span> <span class="ltx_bibblock">W3C Credentials Community Group. </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://w3c-ccg.github.io/did-method-web/" title="">https://w3c-ccg.github.io/did-method-web/</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/WB8M-8ECW" title="">https://perma.cc/WB8M-8ECW</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib30"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Grow your own services (2024)</span> <span class="ltx_bibblock"> Grow your own services. 2024. </span> <span class="ltx_bibblock">Grow your own social network. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://growyourown.services/grow-your-own-social-network/" title="">https://growyourown.services/grow-your-own-social-network/</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/KS4A-RAEW" title="">https://perma.cc/KS4A-RAEW</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib31"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Heart et al<span class="ltx_text" id="bib.bib31.2.2.1">.</span> (2023)</span> <span class="ltx_bibblock"> Cassie Heart, horsefacts, and Varun Srinivasan. 2023. </span> <span class="ltx_bibblock">FIP-6: Flexible Storage. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://github.com/farcasterxyz/protocol/discussions/98" title="">https://github.com/farcasterxyz/protocol/discussions/98</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/9JT5-DR3V" title="">https://perma.cc/9JT5-DR3V</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib32"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Henshaw-Plath (2023)</span> <span class="ltx_bibblock"> Evan Henshaw-Plath. 2023. </span> <span class="ltx_bibblock">Pivoting Protocols, from SSB to Nostr. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://www.nos.social/blog/pivoting-from-ssb-to-nostr" title="">https://www.nos.social/blog/pivoting-from-ssb-to-nostr</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/9Y63-28YM" title="">https://perma.cc/9Y63-28YM</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib33"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Holmgren et al<span class="ltx_text" id="bib.bib33.2.2.1">.</span> (2023)</span> <span class="ltx_bibblock"> Daniel Holmgren, Bryan Newbold, Devin Ivy, and Jake Gold. 2023. </span> <span class="ltx_bibblock">DID PLC Method (did:plc). </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://github.com/did-method-plc/did-method-plc" title="">https://github.com/did-method-plc/did-method-plc</a> </span> </li> <li class="ltx_bibitem" id="bib.bib34"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">IPFS Documentation (2022)</span> <span class="ltx_bibblock"> IPFS Documentation. 2022. </span> <span class="ltx_bibblock">Content Identifiers (CIDs). </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://docs.ipfs.tech/concepts/content-addressing/" title="">https://docs.ipfs.tech/concepts/content-addressing/</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/65PP-ZRQW" title="">https://perma.cc/65PP-ZRQW</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib35"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Karlsson (2024)</span> <span class="ltx_bibblock"> Jacob Karlsson. 2024. </span> <span class="ltx_bibblock">Launch of the PZP protocol and the future of Manyverse. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://www.manyver.se/blog/2024-07-03" title="">https://www.manyver.se/blog/2024-07-03</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/45S3-S7FZ" title="">https://perma.cc/45S3-S7FZ</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib36"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Laurie (2014)</span> <span class="ltx_bibblock"> Ben Laurie. 2014. </span> <span class="ltx_bibblock">Certificate Transparency. </span> <span class="ltx_bibblock"><em class="ltx_emph ltx_font_italic" id="bib.bib36.1.1">ACM Queue</em> 12, 8 (Aug. 2014), 10–19. </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://doi.org/10.1145/2668152.2668154" title="">https://doi.org/10.1145/2668152.2668154</a> </span> </li> <li class="ltx_bibitem" id="bib.bib37"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Lemmer-Webber et al<span class="ltx_text" id="bib.bib37.2.2.1">.</span> (2018)</span> <span class="ltx_bibblock"> Christine Lemmer-Webber, Jessica Tallon, Erin Shepherd, Amy Guy, and Evan Prodromou. 2018. </span> <span class="ltx_bibblock">ActivityPub. </span> <span class="ltx_bibblock">W3C Recommendation. </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://www.w3.org/TR/2018/REC-activitypub-20180123/" title="">https://www.w3.org/TR/2018/REC-activitypub-20180123/</a> </span> </li> <li class="ltx_bibitem" id="bib.bib38"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Lens Protocol (2023)</span> <span class="ltx_bibblock"> Lens Protocol. 2023. </span> <span class="ltx_bibblock">Introducing Momoka to Scale Lens. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://mirror.xyz/lensprotocol.eth/3Hcl0dGE8AOYmnFolzqO6hJuueDHdsaCs3ols2ruc9E" title="">https://mirror.xyz/lensprotocol.eth/3Hcl0dGE8AOYmnFolzqO6hJuueDHdsaCs3ols2ruc9E</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/5SY9-PCP3" title="">https://perma.cc/5SY9-PCP3</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib39"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Lens Protocol (2024)</span> <span class="ltx_bibblock"> Lens Protocol. 2024. </span> <span class="ltx_bibblock">Lens Protocol Overview. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://github.com/lens-protocol/core" title="">https://github.com/lens-protocol/core</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/SFA7-7CQ6" title="">https://perma.cc/SFA7-7CQ6</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib40"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Liu (2023)</span> <span class="ltx_bibblock"> Emily Liu. 2023. </span> <span class="ltx_bibblock">How to set your domain as your handle. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://blueskyweb.xyz/blog/4-28-2023-domain-handle-tutorial" title="">https://blueskyweb.xyz/blog/4-28-2023-domain-handle-tutorial</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/4LNR-6YC5" title="">https://perma.cc/4LNR-6YC5</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib41"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Masnick (2019)</span> <span class="ltx_bibblock"> Mike Masnick. 2019. </span> <span class="ltx_bibblock"><em class="ltx_emph ltx_font_italic" id="bib.bib41.1.1">Protocols, Not Platforms: A Technological Approach to Free Speech</em>. </span> <span class="ltx_bibblock">Technical Report. Knight First Amendment Institute at Columbia University. </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://knightcolumbia.org/content/protocols-not-platforms-a-technological-approach-to-free-speech" title="">https://knightcolumbia.org/content/protocols-not-platforms-a-technological-approach-to-free-speech</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/2V36-FKV3" title="">https://perma.cc/2V36-FKV3</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib42"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Mastodon gGmbH (2024)</span> <span class="ltx_bibblock"> Mastodon gGmbH. 2024. </span> <span class="ltx_bibblock">Mastodon. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://joinmastodon.org/" title="">https://joinmastodon.org/</a> </span> </li> <li class="ltx_bibitem" id="bib.bib43"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Newbold (2023)</span> <span class="ltx_bibblock"> Bryan Newbold. 2023. </span> <span class="ltx_bibblock">Mechanisms for private “block” relationships between Bluesky accounts. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://github.com/bluesky-social/atproto/discussions/1131" title="">https://github.com/bluesky-social/atproto/discussions/1131</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/2FWX-NPAX" title="">https://perma.cc/2FWX-NPAX</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib44"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Newbold (2024a)</span> <span class="ltx_bibblock"> Bryan Newbold. 2024a. </span> <span class="ltx_bibblock">Notes on Running a Full-Network atproto Relay (July 2024). </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://whtwnd.com/bnewbold.net/3kwzl7tye6u2y" title="">https://whtwnd.com/bnewbold.net/3kwzl7tye6u2y</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/2FHU-D88M" title="">https://perma.cc/2FHU-D88M</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib45"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Newbold (2024b)</span> <span class="ltx_bibblock"> Bryan Newbold. 2024b. </span> <span class="ltx_bibblock">Progress on atproto Values and Value Proposition. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://bnewbold.net/2024/atproto_progress/" title="">https://bnewbold.net/2024/atproto_progress/</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/LC9R-Q6JY" title="">https://perma.cc/LC9R-Q6JY</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib46"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Newman (2024)</span> <span class="ltx_bibblock"> Samuel Newman. 2024. </span> <span class="ltx_bibblock">Graysky: Bluesky, like you’ve never seen it before. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://graysky.app/" title="">https://graysky.app/</a> </span> </li> <li class="ltx_bibitem" id="bib.bib47"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Project Liberty (2020)</span> <span class="ltx_bibblock"> Project Liberty. 2020. </span> <span class="ltx_bibblock">Decentralized Social Networking Protocol (DSNP). </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://dsnp.org/dsnp_whitepaper.pdf" title="">https://dsnp.org/dsnp_whitepaper.pdf</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/RD62-RCKA" title="">https://perma.cc/RD62-RCKA</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib48"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Protocol Labs (2021)</span> <span class="ltx_bibblock"> Protocol Labs. 2021. </span> <span class="ltx_bibblock">Specification: DAG-CBOR. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://ipld.io/specs/codecs/dag-cbor/spec/" title="">https://ipld.io/specs/codecs/dag-cbor/spec/</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/D7UV-EUFL" title="">https://perma.cc/D7UV-EUFL</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib49"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Roth and Lai (2023)</span> <span class="ltx_bibblock"> Yoel Roth and Samantha Lai. 2023. </span> <span class="ltx_bibblock">Collective Security in a Federated World. </span> <span class="ltx_bibblock">In <em class="ltx_emph ltx_font_italic" id="bib.bib49.1.1">Scaling Trust on the Web</em>. Atlantic Council, Chapter Annex 5. </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://www.atlanticcouncil.org/in-depth-research-reports/report/scaling-trust/" title="">https://www.atlanticcouncil.org/in-depth-research-reports/report/scaling-trust/</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/CT3R-DCF5" title="">https://perma.cc/CT3R-DCF5</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib50"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">SilverWolf32 et al<span class="ltx_text" id="bib.bib50.2.2.1">.</span> (2019)</span> <span class="ltx_bibblock"> SilverWolf32 et al<span class="ltx_text" id="bib.bib50.3.1">.</span> 2019. </span> <span class="ltx_bibblock">Mastodon issue #12423: Support Post Migration. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://github.com/mastodon/mastodon/issues/12423" title="">https://github.com/mastodon/mastodon/issues/12423</a> </span> </li> <li class="ltx_bibitem" id="bib.bib51"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Solid Project (2024)</span> <span class="ltx_bibblock"> Solid Project. 2024. </span> <span class="ltx_bibblock">Solid. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://solidproject.org/" title="">https://solidproject.org/</a> </span> </li> <li class="ltx_bibitem" id="bib.bib52"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Sporny et al<span class="ltx_text" id="bib.bib52.2.2.1">.</span> (2022)</span> <span class="ltx_bibblock"> Manu Sporny, Dave Longley, Markus Sabadello, Drummond Reed, Orie Steele, and Christopher Allen. 2022. </span> <span class="ltx_bibblock">Decentralized Identifiers (DIDs) v1.0: Core architecture, data model, and representations. </span> <span class="ltx_bibblock">W3C Recommendation. </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://www.w3.org/TR/did-core/" title="">https://www.w3.org/TR/did-core/</a> </span> </li> <li class="ltx_bibitem" id="bib.bib53"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Srinivasan (2023)</span> <span class="ltx_bibblock"> Varun Srinivasan. 2023. </span> <span class="ltx_bibblock">Farcaster: A Decentralized Social Network. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://github.com/farcasterxyz/protocol/blob/main/docs/OVERVIEW.md" title="">https://github.com/farcasterxyz/protocol/blob/main/docs/OVERVIEW.md</a> </span> </li> <li class="ltx_bibitem" id="bib.bib54"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Staltz (2023)</span> <span class="ltx_bibblock"> André Staltz. 2023. </span> <span class="ltx_bibblock">Manyverse Blog: May 2023 update. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://www.manyver.se/blog/2023-05-05" title="">https://www.manyver.se/blog/2023-05-05</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/9D7E-E8EH" title="">https://perma.cc/9D7E-E8EH</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib55"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Steele and Sporny (2023)</span> <span class="ltx_bibblock"> Orie Steele and Manu Sporny. 2023. </span> <span class="ltx_bibblock">DID Specification Registries: The interoperability registry for Decentralized Identifiers. </span> <span class="ltx_bibblock">W3C DID Working Group. </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://w3c.github.io/did-spec-registries/#did-methods" title="">https://w3c.github.io/did-spec-registries/#did-methods</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/LM4T-JTZ5" title="">https://perma.cc/LM4T-JTZ5</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib56"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">The Manyverse Authors (2021)</span> <span class="ltx_bibblock"> The Manyverse Authors. 2021. </span> <span class="ltx_bibblock">FAQ: How do I delete content? </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://www.manyver.se/faq/permanence" title="">https://www.manyver.se/faq/permanence</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/DSB4-6H78" title="">https://perma.cc/DSB4-6H78</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib57"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">The Manyverse Authors (2022)</span> <span class="ltx_bibblock"> The Manyverse Authors. 2022. </span> <span class="ltx_bibblock">FAQ: How can I use my account on many devices? </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://www.manyver.se/faq/account-on-many-devices" title="">https://www.manyver.se/faq/account-on-many-devices</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/5S9S-NA9U" title="">https://perma.cc/5S9S-NA9U</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib58"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">The Manyverse Authors (2024)</span> <span class="ltx_bibblock"> The Manyverse Authors. 2024. </span> <span class="ltx_bibblock">Manyverse. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://www.manyver.se/" title="">https://www.manyver.se/</a> </span> </li> <li class="ltx_bibitem" id="bib.bib59"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Tokyo Outsider (2023)</span> <span class="ltx_bibblock"> Tokyo Outsider. 2023. </span> <span class="ltx_bibblock">MastodonContentMover. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://mastodoncontentmover.github.io/" title="">https://mastodoncontentmover.github.io/</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/EGM8-RM8U" title="">https://perma.cc/EGM8-RM8U</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib60"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Warpcast (2024)</span> <span class="ltx_bibblock"> Warpcast. 2024. </span> <span class="ltx_bibblock">Farcaster: A protocol for decentralized social apps. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://www.farcaster.xyz/" title="">https://www.farcaster.xyz/</a> </span> </li> <li class="ltx_bibitem" id="bib.bib61"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">X Help Center ([n. d.])</span> <span class="ltx_bibblock"> X Help Center. [n. d.]. </span> <span class="ltx_bibblock">How to block accounts on X. </span> <span class="ltx_bibblock"> </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://help.twitter.com/en/using-x/blocking-and-unblocking-accounts" title="">https://help.twitter.com/en/using-x/blocking-and-unblocking-accounts</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/VZZ6-CSCM" title="">https://perma.cc/VZZ6-CSCM</a>. </span> </li> <li class="ltx_bibitem" id="bib.bib62"> <span class="ltx_tag ltx_role_refnum ltx_tag_bibitem">Yeung (2023)</span> <span class="ltx_bibblock"> Douglas Yeung. 2023. </span> <span class="ltx_bibblock">The ‘Digital Town Square’ Problem. </span> <span class="ltx_bibblock">The RAND Blog. </span> <span class="ltx_bibblock"> <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://www.rand.org/blog/2023/01/the-digital-town-square-problem.html" title="">https://www.rand.org/blog/2023/01/the-digital-town-square-problem.html</a> </span> <span class="ltx_bibblock">Archived at <a class="ltx_ref ltx_url ltx_font_typewriter" href="https://perma.cc/3GM7-3VPP" title="">https://perma.cc/3GM7-3VPP</a>. </span> </li> </ul> </section> </article> </div> <footer class="ltx_page_footer"> <div class="ltx_page_logo">Generated on Tue Oct 15 20:46:00 2024 by <a class="ltx_LaTeXML_logo" href="http://dlmf.nist.gov/LaTeXML/"><span style="letter-spacing:-0.2em; margin-right:0.1em;">L<span class="ltx_font_smallcaps" style="position:relative; bottom:2.2pt;">a</span>T<span class="ltx_font_smallcaps" style="font-size:120%;position:relative; bottom:-0.2ex;">e</span></span><span style="font-size:90%; position:relative; bottom:-0.2ex;">XML</span><img alt="Mascot Sammy" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAsAAAAOCAYAAAD5YeaVAAAAAXNSR0IArs4c6QAAAAZiS0dEAP8A/wD/oL2nkwAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9wKExQZLWTEaOUAAAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAdpJREFUKM9tkL+L2nAARz9fPZNCKFapUn8kyI0e4iRHSR1Kb8ng0lJw6FYHFwv2LwhOpcWxTjeUunYqOmqd6hEoRDhtDWdA8ApRYsSUCDHNt5ul13vz4w0vWCgUnnEc975arX6ORqN3VqtVZbfbTQC4uEHANM3jSqXymFI6yWazP2KxWAXAL9zCUa1Wy2tXVxheKA9YNoR8Pt+aTqe4FVVVvz05O6MBhqUIBGk8Hn8HAOVy+T+XLJfLS4ZhTiRJgqIoVBRFIoric47jPnmeB1mW/9rr9ZpSSn3Lsmir1fJZlqWlUonKsvwWwD8ymc/nXwVBeLjf7xEKhdBut9Hr9WgmkyGEkJwsy5eHG5vN5g0AKIoCAEgkEkin0wQAfN9/cXPdheu6P33fBwB4ngcAcByHJpPJl+fn54mD3Gg0NrquXxeLRQAAwzAYj8cwTZPwPH9/sVg8PXweDAauqqr2cDjEer1GJBLBZDJBs9mE4zjwfZ85lAGg2+06hmGgXq+j3+/DsixYlgVN03a9Xu8jgCNCyIegIAgx13Vfd7vdu+FweG8YRkjXdWy329+dTgeSJD3ieZ7RNO0VAXAPwDEAO5VKndi2fWrb9jWl9Esul6PZbDY9Go1OZ7PZ9z/lyuD3OozU2wAAAABJRU5ErkJggg=="/></a> </div></footer> </div> </body> </html>