95 lines
6.3 KiB
Markdown
95 lines
6.3 KiB
Markdown
|
---
|
||
|
|
public: "true"
|
||
|
|
slug: "fedi-v2"
|
||
|
|
title: "Fedi v2"
|
||
|
|
---
|
||
|
|
# Fedi v2
|
||
|
|
|
||
|
|
> Referenced by: [Social Media](/garden/social-media/index.md)
|
||
|
|
|
||
|
|
My take on a theoretical successor to federated [Social Media](/garden/social-media/index.md)
|
||
|
|
|
||
|
|
Inspiration:
|
||
|
|
- [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)
|
||
|
|
- [ATProto](https://atproto.com)
|
||
|
|
- A lot of these ideas are learned lessons from the usenet days
|
||
|
|
|
||
|
|
[Weird](/garden/weird/index.md) may eventually move in the direction of implementing something like this
|
||
|
|
- [Next Gen Federation on Iroh: Graph Data & Linked Documents Layers](https://github.com/commune-os/weird/discussions/32)
|
||
|
|
|
||
|
|
[Federated Identity](/garden/federated-identity/index.md)
|
||
|
|
- 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"
|
||
|
|
- I believe [Iroh](https://iroh.computer) works this way
|
||
|
|
|
||
|
|
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
|
||
|
|
- 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
|
||
|
|
|
||
|
|
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
|
||
|
|
- 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
|