thepaperpilot
dda6a24ea0
All checks were successful
Build and Deploy / build-and-deploy (push) Successful in 1m1s
8.3 KiB
8.3 KiB
| public | slug | title | prev | next |
|---|---|---|---|---|
| true | fedi-v2 | Fedi v2 | false | false |
Fedi v2
Referenced by: Social Media, Weird
A placeholder name for a theoretical new federated network that is client-centric, in contrast to the server-centric Fediverse
There are further discussions about actually implementing all this within the Weird community
Inspiration
- A Plan for Social Media - Rethinking Federation
- 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?
- This article doesn't address many implementation details:
- Single-user Mastodon Instance is a Bad Idea
- Focuses on the non-feasibility of self hosting, contributing to Federated Social Media not actually having all the upsides it should theoretically have by virtue of being Decentralized
- The Commune community
- Existing protocols:
- A lot of these ideas are learned lessons from the usenet days
Identity
- Federated Identity
- 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 could be used to display human readable names via contacts or decentralized "naming hubs"
- 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
Servers
- 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
Content
- 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
- That signature serves as an ID for the message itself
- 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
- IndieWeb 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
Moderation
- 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?
Problems to solve
- 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
- Perhaps clients and servers can be identified as such, and subscribing to new messages is something you only do to servers, not clients
- 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