Devlog - Decentralized Social Media
As I announced in my last blog post, I'm working on a standard/protocol for a decentralized social media platform designed for people who want good privacy controls for hidden accounts, as opposed to the poor options available on Bluesky and Mastadon (as well as any other ActivityPub or AT Protocol servers).
That doesn't mean these platforms don't have a lot of good stuff going for them. They have a lot of great ideas, they just are designing platforms for mass viral spread of speech, rather than the more quiet, personal, possibly even intimate communications we might be more used to on platforms like Instagram and Facebook. We want to be able to restrict who can see our content, even after we've posted it. This is where my idea comes in, as I'm trying to give that control to users, while still maintaining that decentralized model.
Server-to-Server communication
The biggest reason why the existing protocols are no good for private accounts, is that they share your stuff around with other servers. This is useful when it comes to public accounts and small servers. If someone has an account on a small server that usually doesn't get much traffic, but then suddenly one of their users makes a viral post reaching millions of users, they're going to be innandated with an unexpected spike in traffic, which has the potential to take down the server. Take ActivityPub's solution to this -- the protocol I'm more familiar with.
ActivityPub works so that anytime a user from a different server wants to see that viral post, they don't get it themselves, but instead ask their own home server to retrieve it and send it to them. That home server will then save a copy of it, so that they don't need to ask that small server for it again later. This way, a server only needs to handle traffic from at most, all of their own users, plus from each other SERVER on the network, but not all of the USERS from those other servers. The idea is that it lightens the load for smaller players, lowering the bar for entry to host your own server.
For users with private accounts, this means trouble though. If you want to remove one of your followers, you'll need to remove their name from the list of people who are allowed to see your post -- for every single one of your posts. This easy enough to program into the user client after you press a button. The trouble comes with the fact that you also need to update the list on every copy of those posts that were saved on other servers. Servers that might not want to delete your post. You have no guarantee that you can fully remove that person from seeing your old posts.
Keep content localized
My solution to that problem is to keep posts saved only on your home server, and not allow servers to create duplicates. This would normally run the risk of over flooding a server when viral posts happen, but since this system is designed against the idea of parasocial relations, you really shouldn't have long follow lists, and explore feeds wouldn't be a thing either. The point is to communicate with your friends, and that's it. Servers might need to enforce this a bit if they're smaller, forcing you to keep your following/follower lists no greater than 100 or 200. Some might pick lower or higher numbers. I haven't done much thinking on any of the specifics for that yet, but really most people who would be attracted to this kind of thing probably don't want to be following 500 of their closest friends with this thing.
Account resolution
Beyond keeping things decentralized by allowing users to pick different servers to host their content, we also want a way for them to switch servers if the one they're on starts bothering them, or intentionally screwing them over. That's where my new idea involving CNAME records on DNS servers comes in. I've yet to come up with a catchy name for this yet, so I'm just referring to these DNS domains, and the people who run them as "Subdomain providers".
Here's how it works: When you make your account on the platform, you also sign up with a subdomain provider -- an entity that has control of a domain, and is willing to give you a subdomain. For instance, a (fake) example provider might be Awesome Potato. They might own the (fake) domain awesomepotato.net. You choose to create an account name alice with them. In turn, your subdomain is now alice.awesomepotato.net. You tell Awesome Potato to have your subdomain point to your content server (the server that hosts your social media posts). Let's say you use the (fake) InstaCafe content server, with your profile being located at the URL alice09.insta.cafe. Awesome Potato will fill out the CNAME record of your registered domain to point to this InstaCafe location. Notice how your InstaCafe account is referenced by using a subdomain, rather than something like insta.cafe/alice09. This is on purpose, as DNS CNAME can only be made to point to domains and subdomains, but not specific resources on a domain. Also notice that you don't need to have matching usernames on your subdomain provider as your content server. They're two separate entities, and all you're doing is making one of them point at the other.
Switching Content Servers
If you ever became frustrated for whatever reason with your existing server, you would simply tell Awesome Potato to point to your new account that you've made, over at alice.funblog.xyz (this is also fake, don't go to these links, I don't own them). If you wish, you could request to export all your old user data from your InstaCafe server, and then import it to your FunBlog account, so that your old posts stick around too. Though if InstaCafe is being intentionally malicious, they might refuse to give you an export of your data.
Taking your followers with you
The entire point of this convoluted system is that now, you've switched accounts, but you've retained 100% of your followers, since the AwesomePotato link will send all your friends to your new account, without them needing to click anything. This is really big, because it DRAMATICALLY reduces switching costs between servers. You don't have to worry about convincing your friends to go follow your new account somewhere else.
Security Concerns
A slight downside to this unfortunately is that it puts a lot of pressure on that subdomain provider (like Awesome Potato). If you lose your password, or get hacked, you're entirely locked out, and now your friends might be following some totally random new account that they made the subdomain point to. I don't think these risks are too big to accept, but they are slightly larger than traditional social media, since now there's two attack surfaces per account, instead of just one.
Wrap up
So that's mostly what I've got so far developed. I'm currently looking into some server software so I can try to get a proof-of-concept running for a content server. I also need to build a user client after that, which is likely going to be the hardest to do, since I don't know really anything about frontend or graphics stuff. I'd love it if anyone was curious about the project and might want to contribute in whatever small ways they could. But also just hearing input about my ideas would be nice as well. Always feel free to email me, I've got a contact link at the top of my blog, or just email me at rseeber@proton.me. I'd love to hear any thoughts you have!