2024-06-11 02:38:24 +00:00
|
|
|
|
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 "Fedi v2""></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 "Inspiration""></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'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'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 & Linked Documents Layers</a></li></ul><h2 id="identity" tabindex="-1">Identity <a class="header-anchor" href="#identity" aria-label="Permalink to "Identity""></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 "naming hubs"</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 "important identities"</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't reach out to a naming hub, as it's not typically necessary</li></ul></li><li>Contacts supercede naming hubs, so if a naming hub is breached, anyone I'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'm just thepaperpilot, my display name. For most online communication, this is suffi
|
