import{_ as e,c as i,o as t,a9 as a}from"./chunks/framework.D8PMdl4T.js";const p=JSON.parse('{"title":"Fedi v2","description":"","frontmatter":{"public":"true","slug":"fedi-v2","title":"Fedi v2","prev":false,"next":false},"headers":[],"relativePath":"garden/fedi-v2/index.md","filePath":"garden/fedi-v2/index.md","lastUpdated":1717655952000}'),l={name:"garden/fedi-v2/index.md"},s=a('<h1 id="fedi-v2" tabindex="-1">Fedi v2 <a class="header-anchor" href="#fedi-v2" aria-label="Permalink to &quot;Fedi v2&quot;">​</a></h1><blockquote><p>Referenced by: <a href="/garden/social-media/">Social Media</a></p></blockquote><p>My take on a theoretical successor to federated <a href="/garden/social-media/">Social Media</a></p><h2 id="inspiration" tabindex="-1">Inspiration <a class="header-anchor" href="#inspiration" aria-label="Permalink to &quot;Inspiration&quot;">​</a></h2><ul><li><a href="https://raphael.lullis.net/a-plan-for-social-media-less-fedi-more-webby/" target="_blank" rel="noreferrer">A Plan for Social Media - Rethinking Federation</a><ul><li>This article doesn&#39;t address many implementation details: <ul><li>If the server is a relay, can content not be viewed anonymously?</li><li>How to handle storing large amounts of data on every client?</li><li>Don&#39;t you still need to associate with a server for people to direct their messages to?</li></ul></li></ul></li><li><a href="https://mull.net/mastodon" target="_blank" rel="noreferrer">Single-user Mastodon Instance is a Bad Idea</a><ul><li>Focuses on the non-feasibility of self hosting, contributing to <a href="/garden/fediverse/">Federated Social Media</a> not actually having all the upsides it should theoretically have by virtue of being <a href="/garden/decentralized/">Decentralized</a></li></ul></li><li>The <a href="/garden/commune/">Commune</a> community</li><li>Existing protocols: <ul><li><a href="https://nostr.com" target="_blank" rel="noreferrer">Nostr</a></li><li><a href="https://atproto.com" target="_blank" rel="noreferrer">ATProto</a></li></ul></li><li>A lot of these ideas are learned lessons from the usenet days</li></ul><p><a href="/garden/weird/">Weird</a> may eventually move in the direction of implementing something like this</p><ul><li><a href="https://github.com/commune-os/weird/discussions/32" target="_blank" rel="noreferrer">Next Gen Federation on Iroh: Graph Data &amp; Linked Documents Layers</a></li></ul><h2 id="identity" tabindex="-1">Identity <a class="header-anchor" href="#identity" aria-label="Permalink to &quot;Identity&quot;">​</a></h2><ul><li><a href="/garden/federated-identity/">Federated Identity</a></li><li>Private and public keys anyone can create and store how they want <ul><li>Fully free to create and store with no server dependencies</li></ul></li><li>Profile information <ul><li>Sent as a signed message through all the relays</li><li>How would you trust a username? <ul><li><a href="https://spritely.institute/static/papers/petnames.html" target="_blank" rel="noreferrer">Petnames</a> could be used to display human readable names via contacts or decentralized &quot;naming hubs&quot;</li><li>In most conversations online, you can trust their display name and add them as a contact as that display name <ul><li>You only need to verify they are the same person you interacted with previously</li><li>You only need to trust people you want to send money to or otherwise &quot;important identities&quot;</li><li>For important identities, you can trust your contacts forming a chain of trust, or a authoritative naming hub <ul><li>E.g. a white house ran naming hub that verifies the identities of the president and people of Congress</li><li>People typically wouldn&#39;t reach out to a naming hub, as it&#39;s not typically necessary</li></ul></li><li>Contacts supercede naming hubs, so if a naming hub is breached, anyone I&#39;ve previously added as a contact is still the source of truth <ul><li>This only fails if the private key itself was breached</li></ul></li><li>I&#39;m just thepaperpilot, my display name. For most online communication, this is sufficient <ul><li>My website can have a nameserver saying this publickey is the same as the site owner</li><li>If I write a paper at a scientific journal, they can say the author of x paper is my publickey</li></ul></li></ul></li></ul></li></ul></li><li>How to handle losing your private key <ul><li>If you do have a naming hub you can verify with, they can say the identity has a new publickey</li><li>Contacts can &quot;vouch&quot; for a identity having a new publickey</li><li>Clients can decide to trust the new publickey based on contacts and naming hubs saying to</li><li>Also applies to stolen or compromised keys</li></ul></li><li>I believe <a href="https://iroh.computer" target="_blank" rel="noreferrer">Iroh</a> works this way</li></ul><h2 id="servers" tabindex="-1">Servers <a class="header-anchor" href="#servers" aria-label="Permalink to &quot;Servers&quot;">​</a></h2><ul><li>Act as relays, merely storing messages and sending them to any clients or servers that have subscribed</li><li>May decide to publicly display messages its received <ul><li>These servers are how discovery would work</li><li>Different servers may offer unique displays, filters, etc.</li></ul></li><li>Users can send their content to any server - no authentication or account required, as the identity suffices <ul><li>Even replies can work this way - no need to know from where a given message originated</li></ul></li><li>Private servers could require some password when sending messages or subscribing to things <ul><li>Useful for a school or other entity that wants an internal social network</li></ul></li><li>Different ways to subscribe to a server&#39;s messages <ul><li>All messages the relay hears about (new relays essentially subscribe like this to some existing relay)</li><li>All messages from a specific poster ID</li><li>Any replies to a message created with a specific poster ID</li><li>Shallow subscriptions, to lighten the load when subscribing to communities</li></ul></li></ul><h2 id="content" tabindex="-1">Content <a class="header-anchor" href="#content" aria-label="Permalink to &quot;Content&quot;">​</a></h2><ul><li>Protocol should dictate how to convey text, image, audio, video, and binary content</li><li>Protocol should include reacting to content with arbitrary text, including a URL <ul><li>Upvotes and downvotes are implemented with this system</li></ul></li><li>Each message contains fields for the poster&#39;s ID (public key) and a signature that verifies the content was made by that poster <ul><li>That signature serves as an ID for the message itself <ul><li>Anything can be replied to using the ID as the &quot;parent&quot; property in a new post</li></ul></li></ul></li><li>Edits are handled as replies with some flag to indicate it&#39;s updating the parent messages&#39; content <ul><li>Naturally, this reply would only be respected if it matches the same creator ID</li><li>Servers should replace the original message entirely with this one and indicate its an edited message <ul><li>Some servers will inevitably keep a full history though</li></ul></li></ul></li><li>Groups/communities are just specially flagged messages <ul><li>Posting to a community is just replying to that message</li><li>Subscribing to a community is just subscribing to that message</li><li>The original message creator effectively owns the group</li></ul></li></ul><h2 id="moderation" tabindex="-1">Moderation <a class="header-anchor" href="#moderation" aria-label="Permalink to &quot;Moderation&quot;">​</a></h2><ul><li>In general, edits and delete requests are made by replying with a specially flagged message</li><li>Edit and deletion messages are ignored unless they have the correct public key and signature <ul><li>Parent messages form a hierarchy of permission - if someone replies to your message, you can send a delete request for that message</li><li>Relay owners cannot fully delete messages, but can choose to stop relaying replies etc. of messages as the server owner wishes</li></ul></li><li>Posts can be publicly reported with a specially flagged reply <ul><li>How to make anonymous reports?</li></ul></li><li>Users can send deletion or edit messages even without a matching public key, and clients (or relays) can choose to respect those messages if that public key is whitelisted as a moderator <ul><li>Messages (and by extension, groups) can have replies granting or removing permission to other public IDs at that hierarchy level</li><li>People can setup accounts with their desired heuristic for sending delete messages, such as looking at public reports or analyzing the content with AI <ul><li>This way clients can effectively customize their preferred moderation</li></ul></li></ul></li><li>Clients can also choose to add additional rules for hiding content, such as any reports by followed users</li><li>Perhaps delete messages pull double duty as public reports in and of themselves?</li></ul><h2 id="problems-to-solve" tabindex="-1">Problems to solve <a class="header-anchor" href="#problems-to-solve" aria-label="Permalink to &quot;Problems to solve&quot;">​</a></h2><ul><li>No anonymity <ul><li>All upvotes, downvotes, etc. are linked to your public key</li><li>Perhaps a client could generate new keypairs for every action for anonymity, but then it&#39;d be hard to determine if such an account and action was a genuine user or a bot</li></ul></li><li>Servers could probably determine the identity of clients sending their messages to them <ul><li>A client that only ever sends messages with a specific public key is unlikely to be a server</li><li>A client that doesn&#39;t subscribe to all messages is unlikely to be a server</li></ul></li><li>Illegal material will likely be placed on the hard drive at least temporarily <ul><li>Messages will be downloaded and, even if you follow a moderator bot that looks for illegal material, there&#39;s likely to be a delay between receiving the initial message and receiving the bots delete message</li></ul></li><li>You have to download all spam messages <ul><li>For redundancy, you&#39;d likely subscribe to multiple relay servers</li><li>You cannot trust several relay servers to have identical rules on not relaying messages that don&#39;t pass whatever moderation heuristic</li><li>Therefore, the filtering out of spam has to be done by the client, after downloading it all</li></ul></li></ul>',17),o=[s];function r(n,d,u,h,c,m){return t(),i("div",null,o)}const g=e(l,[["render",r]]);export{p as __pageData,g as default};