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
- [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
- 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"
- 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?
- 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
