pages/site/garden/fedi-v2/index.md

117 lines
8.3 KiB
Markdown
Raw Normal View History

2024-06-04 03:59:20 +00:00
---
public: "true"
slug: "fedi-v2"
title: "Fedi v2"
2024-06-06 04:25:48 +00:00
prev: false
next: false
2024-06-04 03:59:20 +00:00
---
# Fedi v2
> Referenced by: [Social Media](/garden/social-media/index.md), [Weird](/garden/weird/index.md)
2024-06-04 03:59:20 +00:00
2024-06-14 03:54:30 +00:00
A placeholder name for a theoretical new federated network that is client-centric, in contrast to the server-centric [Fediverse](/garden/fediverse/index.md)
There are further discussions about actually implementing all this within the [Weird](/garden/weird/index.md) community
2024-06-04 03:59:20 +00:00
2024-06-06 04:25:48 +00:00
## Inspiration
2024-06-04 03:59:20 +00:00
- [A Plan for Social Media - Rethinking Federation](https://raphael.lullis.net/a-plan-for-social-media-less-fedi-more-webby/)
- This article doesn't address many implementation details:
- If the server is a relay, can content not be viewed anonymously?
- How to handle storing large amounts of data on every client?
- Don't you still need to associate with a server for people to direct their messages to?
- [Single-user Mastodon Instance is a Bad Idea](https://mull.net/mastodon)
- Focuses on the non-feasibility of self hosting, contributing to [Federated Social Media](/garden/fediverse/index.md) not actually having all the upsides it should theoretically have by virtue of being [Decentralized](/garden/decentralized/index.md)
- The [Commune](/garden/commune/index.md) community
- Existing protocols:
- [Nostr](https://nostr.com)
2024-06-14 03:54:30 +00:00
- Currently suffers a culture problem by being associated with alt right and crypto users, making broad adoption more difficult
2024-06-04 03:59:20 +00:00
- [ATProto](https://atproto.com)
2024-06-14 03:54:30 +00:00
- Focused on a few large instances, to be run by large corporations. Still requires associating your identity with a server you don't own
2024-06-04 03:59:20 +00:00
- A lot of these ideas are learned lessons from the usenet days
2024-06-06 06:39:12 +00:00
## Identity
- [Federated Identity](/garden/federated-identity/index.md)
2024-06-04 03:59:20 +00:00
- Private and public keys anyone can create and store how they want
- Fully free to create and store with no server dependencies
- Profile information
- Sent as a signed message through all the relays
- How would you trust a username?
- [Petnames](https://spritely.institute/static/papers/petnames.html) could be used to display human readable names via contacts or decentralized "naming hubs"
2024-06-06 04:25:48 +00:00
- In most conversations online, you can trust their display name and add them as a contact as that display name
- You only need to verify they are the same person you interacted with previously
- You only need to trust people you want to send money to or otherwise "important identities"
- For important identities, you can trust your contacts forming a chain of trust, or a authoritative naming hub
- E.g. a white house ran naming hub that verifies the identities of the president and people of Congress
- People typically wouldn't reach out to a naming hub, as it's not typically necessary
- 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
- This only fails if the private key itself was breached
- I'm just thepaperpilot, my display name. For most online communication, this is sufficient
- My website can have a nameserver saying this publickey is the same as the site owner
- If I write a paper at a scientific journal, they can say the author of x paper is my publickey
- How to handle losing your private key
- If you do have a naming hub you can verify with, they can say the identity has a new publickey
- Contacts can "vouch" for a identity having a new publickey
- Clients can decide to trust the new publickey based on contacts and naming hubs saying to
- Also applies to stolen or compromised keys
2024-06-04 03:59:20 +00:00
2024-06-06 04:25:48 +00:00
## Servers
2024-06-04 03:59:20 +00:00
- Act as relays, merely storing messages and sending them to any clients or servers that have subscribed
- May decide to publicly display messages its received
- These servers are how discovery would work
- Different servers may offer unique displays, filters, etc.
- Users can send their content to any server - no authentication or account required, as the identity suffices
- Even replies can work this way - no need to know from where a given message originated
- Private servers could require some password when sending messages or subscribing to things
- Useful for a school or other entity that wants an internal social network
- Different ways to subscribe to a server's messages
- All messages the relay hears about (new relays essentially subscribe like this to some existing relay)
- All messages from a specific poster ID
- Any replies to a message created with a specific poster ID
- Shallow subscriptions, to lighten the load when subscribing to communities
2024-06-06 04:25:48 +00:00
## Content
2024-06-04 03:59:20 +00:00
- Protocol should dictate how to convey text, image, audio, video, and binary content
- Protocol should include reacting to content with arbitrary text, including a URL
- Upvotes and downvotes are implemented with this system
- Each message contains fields for the poster's ID (public key) and a signature that verifies the content was made by that poster
- That signature serves as an ID for the message itself
- Anything can be replied to using the ID as the "parent" property in a new post
- Edits are handled as replies with some flag to indicate it's updating the parent messages' content
- Naturally, this reply would only be respected if it matches the same creator ID
- Servers should replace the original message entirely with this one and indicate its an edited message
- Some servers will inevitably keep a full history though
- Groups/communities are just specially flagged messages
- Posting to a community is just replying to that message
- Subscribing to a community is just subscribing to that message
- The original message creator effectively owns the group
2024-06-14 03:54:30 +00:00
- [IndieWeb](/garden/the-small-web/index.md) pages could publish these messages as well, effectively serving as clients within the network
- Perhaps use a bit to actually send those messages to other relays within the network
2024-06-04 03:59:20 +00:00
2024-06-06 04:25:48 +00:00
## Moderation
2024-06-04 03:59:20 +00:00
- In general, edits and delete requests are made by replying with a specially flagged message
- Edit and deletion messages are ignored unless they have the correct public key and signature
- Parent messages form a hierarchy of permission - if someone replies to your message, you can send a delete request for that message
- Relay owners cannot fully delete messages, but can choose to stop relaying replies etc. of messages as the server owner wishes
- Posts can be publicly reported with a specially flagged reply
- How to make anonymous reports?
- 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
- Messages (and by extension, groups) can have replies granting or removing permission to other public IDs at that hierarchy level
- People can setup accounts with their desired heuristic for sending delete messages, such as looking at public reports or analyzing the content with AI
- This way clients can effectively customize their preferred moderation
- Clients can also choose to add additional rules for hiding content, such as any reports by followed users
- Perhaps delete messages pull double duty as public reports in and of themselves?
2024-06-06 04:25:48 +00:00
## Problems to solve
2024-06-04 03:59:20 +00:00
- No anonymity
- All upvotes, downvotes, etc. are linked to your public key
- Perhaps a client could generate new keypairs for every action for anonymity, but then it'd be hard to determine if such an account and action was a genuine user or a bot
- Servers could probably determine the identity of clients sending their messages to them
- A client that only ever sends messages with a specific public key is unlikely to be a server
- A client that doesn't subscribe to all messages is unlikely to be a server
2024-06-14 03:54:30 +00:00
- Perhaps clients and servers can be identified as such, and subscribing to new messages is something you only do to servers, not clients
2024-06-04 03:59:20 +00:00
- Illegal material will likely be placed on the hard drive at least temporarily
- Messages will be downloaded and, even if you follow a moderator bot that looks for illegal material, there's likely to be a delay between receiving the initial message and receiving the bots delete message
- You have to download all spam messages
- For redundancy, you'd likely subscribe to multiple relay servers
- You cannot trust several relay servers to have identical rules on not relaying messages that don't pass whatever moderation heuristic
- Therefore, the filtering out of spam has to be done by the client, after downloading it all