2024-06-15 14:51:29 +00:00
|
|
|
|
import{_ as e,c as i,o as t,a5 as a}from"./chunks/framework.CK8QU5WH.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"}'),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>, <a href="/garden/the-indieweb/signature-blocks/">The IndieWeb/Signature Blocks</a>, <a href="/garden/weird/">Weird</a></p></blockquote><p>A placeholder name for a theoretical new federated network that is client-centric, in contrast to the server-centric <a href="/garden/fediverse/">Fediverse</a></p><p>There are further discussions about actually implementing all this within the <a href="/garden/weird/">Weird</a> community</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><ul><li>Currently suffers a culture problem by being associated with alt right and crypto users, making broad adoption more difficult</li></ul></li><li><a href="https://atproto.com" target="_blank" rel="noreferrer">ATProto</a><ul><li>Focused on a few large instances, to be run by large corporations. Still requires associating your identity with a server you don't own</li></ul></li></ul></li><li>A lot of these ideas are learned lessons from the usenet days</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 namin
|
