2024-06-18 17:38:35 +00:00
|
|
|
|
import{d as a}from"./chunks/git.data.BUKN53Ta.js";import{u as l,c as s,j as e,a as o,k as i,a5 as r,o as n}from"./chunks/framework.BIC8H_hJ.js";const u=e("h1",{class:"p-name"},"Fedi v2",-1),d=["innerHTML"],h=r('<hr><blockquote><p>Referenced by: <a href="/garden/social-media/">Social Media</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 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 sufficient <ul><li>My website can have a nameserver saying this publickey is the sa
|
