Designing an Online Disccusion Board—A Thought Experiment

I’m a slow writer when it comes to this blog, and I’ve been working on it little by little since the last post. I promised in the last phost I would share how I would design an online discussion board (or link aggregator) service. A lot of things have changed since it’s been so long. I could go through and tweak some things, but I feel like leaving them gives a bit of character to the post and more accurately represents its place in time. With my excuses out of the way, here’s my design.

In order to describe this properly, I have to first list out the caveats, design goals, and design non-goals that I have in mind. For many, that last category might be the most surprising. Once those are described, I’ll flesh out how the service would work at a high level, and what a user of the service, a moderator for the service, and an operator of the service would see. I have kept technical details somewhat light. There are no specifics like API endpoints, tools, languages, or databases, unless important to the concept at hand. The specifics are left as implementation details, and there are many holes in the design itself–some purposeful, some not.

What makes this a thought experiment? Three things:

• This is mostly a thought experiment for the author, i.e., me, the person writing this. I saw how Reddit, Lemmy, Kbin, Tildes, Squabbles, etc. worked and decided that none of them quite work the way I would want them to.
• For the reader, i.e., you, the person reading this, I want you to think about how you would design one of these. You may not have a technical background, and that’s fine! What would you want to see as a user? How would you want to interact with it?
• Also for the reader, particularly those with more of a technical background, I want you to pick holes in my design. What looks cool? What looks wrong? Am I doing something inefficiently that would be done better another way? Am I overthinking or underthinking a problem? Think about these things, and let me know on Mastodon what you think.

Caveat Emptor, Caveats Galore

I’ll discuss actual design decisions as we move along, but some key caveats that I want to mention:

• I am not limiting myself to federated or centralized platforms, I’m choosing what I think would be best for a design.
• As an extension of that, I’m also not selecting any given protocol as something to start with.
• This is all my own personal opinion based on what I have seen with existing systems and my experience as an engineer.
• This is a 40,000-foot view design, and will leave out very important details that would need to be considered if this were going to be made reality. As such, there won’t be any images or visualizations, this is all just a description.
• I won’t say never, but it’s not likely that I will ever build this myself. You are free to use this design, but if you do please at least link back to this post in your README or something.

Now that that is out of the way, let’s get started.

Kicking a Goal, Missing the Keeper

What do we want to see? The end state of this design should be a link aggregator or discussion forum that allows the following things:

• Posting links in categorized “boards”
• Posting media like images and videos in categorized boards
• Posting text posts in categorized boards, like a forum
• Commenting on all of those things
• Scoring all of those things¹
• Allowing moderators to delete posts and comments
• Allowing moderators to automatically filter posts
• Allowing moderators to ban users from specific boards

That would be the bare minimum for an MVP (Minimum Viable Product) of this project. Additionally, I want to add some more interesting goals, as I think they’re necessary for a product like this:

• Servers should be interoperable in what we now call a “federated” way
• Federation should be hidden from users, so it doesn’t feel any different from a centralized system
• “Keeping the lights on” is a primary feature instead of an afterthought

That last one is interesting, because it means we need to think about how servers can be run sustainably and how we can convince users to contribute funds as well as how to distribute them. Before anyone raises any eyebrows: I’m not talking about cryptocurrencies. We’ll discuss why later.

Very importantly though, let’s list things that we either are avoiding, or are not constraints for us. That is, our non-goals:

• While we’re aiming for federation, we do not need to rely on existing federated protocols like ActivityPub or the AT protocol. ActivityPub is the protocol that powers a lot of the fediverse today, including both Mastodon and Lemmy. While ActivityPub is a reasonably well-defined protocol, there are some issues with it which means it may not be the best choice for a link aggregator. We’ll discuss the protocol for federation later, but suffice to say ActivityPub doesn’t quite fit the bill.
• We only want a link-aggregator-slash-online-discussion-board. There’s no reason for us to include support for microblogging (e.g., Twitter, Mastodon, Threads), photo sharing (e.g., Instagram, Snapchat, PixelFed), video sharing (e.g., YouTube, TikTok, PeerTube), social graphs (e.g., Facebook, Friendica), or any other form of social media. Having a single protocol that tries to support all possible types of social media results in either a bloated or an inefficient protocol, and there’s no reason for us to deal with that here.
• This is more of a discussion on how a link aggregator would work, so while the user interface is a critical component here, it’s not necessary for this discussion. Designing a UI is left as a thought experiment for the reader.

Now you know what assumptions I’m working with. You may have noticed some goals seem to be contradictory. There’s no good way to make these goals all agree, so I’ve made some compromises along the way.

Experience Points

Users are the most important aspect to the systems’ success, followed by moderators, followed by admins. I know this sounds counterintuitive, it feels like the admins should be the most important to most people who would probably be reading this blog, but think of it this way: a federated link aggregator with only two servers and only two users–the admins themselves–is not a particularly interesting service. A non-federated link aggregator with thousands or tens of thousands of users is far more interesting (see: old Reddit). A link aggregator, federated or not, without moderators quickly devolves into spam, porn, and off-topic posts and is no longer interesting for most people, who will leave.

While admins are critical to bringing up the system and maintaining the servers, without a user base to use the system, the servers are meaningless. Likewise, without moderators to keep out the problematic material, the user base who is there will leave, but without a user base, you don’t have moderators. So, in my mind, the users are the most important thing to design for, the moderators come second, and sorry server-owners, but as critical as you are, you are also the last consideration with designing the system.

Believe me, as someone self-hosting both Mastodon and Lemmy along with a bunch of other things, this hurts me as much as it does you.

Users Using

First, and most importantly, let’s talk about the user experience. There’s a lot to talk about here, but I’m going focus on four parts of the experience which are substantially different from how other platforms operate: signing up, scoring posts (“voting”), following communities, and user privacy.

Sign Me Up, Sign Me In, Sign Me Down, Sign Me Out

The biggest barrier to federated systems today, like it or not, is the onboarding process. “What’s a Server?” “Does that mean I need accounts on every server?” “That sounds hard.” “Can someone just impersonate me then?” “I don’t understand.” I’m sure anyone who’s signed up for an account on the Fediverse and talked about it with anyone has heard at least one of these questions, probably several, and probably others.

Yes, it’s basically just email. Yes, it’e easy to explain. But even so, most people don’t really “get it” even with an explanation, and the truth is that most people don’t want to get it. They want to go to a website, sign up, and start using the network. That’s it.

For several among us, that extra layer of gatekeeping is what maintains some perception of quality among the network, but the reality is that it just raises the barrier to entry for everyone. You’ll get the subset of people who are willing to jump through those hoops, but critically there’s no differentiation in the average quality of posts. You just get fewer of them.

Think of it this way: who’s more likely to write a bot that pulls gibberish from ChatGPT to respond to a message? It’s not a “low-quality poster”, and it’s not someone you necessarily disagree politically with. It’s a fairly competent developer who probably also has the skill set to spin up some form of federated server.

My solution is to hide the fact that it is a federated system from the end user. More technical or interested users will discover this naturally, as of course there will be documentation and discussions and arguments and what have you about the service. But your average social media user? They do not need to know, and they should not need to care.

It looks like this:

Alice visits CoolNewSocial.net on her box, this service’s equivalent of the Join Mastodon or Join Lemmy pages. What she sees, though, is the service’s homepage, like what you see on Reddit or an active Lemmy instance. There’s a “Sign Up” box on the page somewhere. She clicks that and signs up with a Passkey, a username, and her email address (perhaps her choice of Passkey provider generates a random email address for her). She’s logged in and off to the races!

Notice the lack of any consideration on Alice’s part about a “server.” It’s there, but hidden behind the scenes. Spoilers: it’s closer to what a distributed system looks like in a datacenter then it is to ActivityPub as we see it today.

You Only Get One Vote, Cast It Well

I think one of the biggest issues with Reddit and most other discussion forums today is the voting system. Community moderation is fantastic, but the upvote/downvote system is not granular enough. Most forums say an upvote should mean “This is interesting or adds to the discussion,” while a downvote is “this does not add to the discussion.” The reality is that these systems end up as agree or disagree buttons, or sometimes even as simple as “I like you” or “I don’t like you” buttons.

This results in those buttons and the general scoring system being, well, not useful. Chronological discussion is almost as useful as a simple up or down vote. Some communities have attempted solutions, but all have pretty distinct flaws:

• Many forums remove the downvote button entirely.² This has the benefit of getting rid of “I disagree” or “I don’t like you,” but actually makes upvotes even less useful because content that is actively harmful to the discussion now has no way to filter out against content that is simply not as interesting.³ There’s a balance to be had, to be sure, but this is something of a hammer when you should be using a wrench.
• Some forums provide reminders when you hover the upvote or downvote button. ⁴ This is a better approach, but not as good for accessibility and not super effective. It will remind some people who would otherwise follow the appropriate etiquette, but a decent percentage of people—perhaps even the majority—wouldn’t do so anyway.
• A few forums require some form of reputation score to unlock various features, including voting. ⁵ In some implementations, you then spend part of your own score to downvote. This gamifies the system, resulting in twisted incentives and typically a rather toxic community. This deserves its own post, so I’ll leave it at that for now, but search around for some issues people have with the StackOverflow community⁶ as a very clear example.

So, what’s the solution? Well, hearken your mind back to the late nineties and early aughts, where there was once a link aggregator site that gained a bit of popularity. I speak, of course, of ”/.” Slashdot is an older social news website that uses a style which has gone out of fashion, a combination of user submissions and an editorial board. What we care about, though, is the comments.

Slashdot’s comments used to have⁷ optional “tags” associated with them. Some theoretical examples could have been “intriguing,” “insightful,” or “incorrect.” Comments labeled this way would be weighted higher or lower, giving them more or less visibility. While the system was, ultimately, optional, it did provide a generally higher quality of comment then some competitors at the time.

The Slashdot method fell out of favor primarily for convenience, but I believe it is possible to implement something similar in such a way to introduce a minimal amount of additional friction. So with that story, scoring looks like this:

Alice, on her shiny new CoolNewSocial account, finds a fascinating post about foxes. Alice loves foxes, after all. She taps a “like this” box under the post, and is presented with a small set of options: “interesting,” “tasty,” “cool,” “informative,” or “funny.” She clicks “interesting,” and the post’s positive score count goes up by one.

Later, she sees a post about bats, and she’s terrified of bats. She clicks the “hate this” button under the post, and has a different set of options: “boring,” “gross,” “dislike,” “misinformation,” “NSFW,”⁸ or “rule breaking.” She clicks “gross,” because that’s what she thinks of bats, and the post’s negative score count goes up by one.

Even though she “downvoted” it, she’s still oddly intrigued by the bat post, so reads some comments. In the comments, she finds a post that reads “Bats are terrible, they murder 200,000 babies per year!” She doesn’t like bats, but she knows that’s clearly not true. She clicks the “hate this” button and then “misinformation.” What Alice doesn’t know is she is far from alone in marking this as misinformation. The post has its negative count increased by one, but is also dimmed and collapsed (that is, you have to click a link to view the comment now). It now has a badge that says “misinformation” next to it when viewed⁹.

Are there issues with this system from a user perspective? Absolutely! It introduces an extra step to voting, which will reduce interaction. However, we aren’t trying to appease to advertisers¹⁰, so lower engagement isn’t a huge concern as long as we have a decent base-level of engagement. There’s still the potential for online bullying through the voting system. This doesn’t resolve that problem, but it also doesn’t make it worse—this would be a good thing to consider how to improve.

The Community Center

In the signing up section, we briefly touched on how federation must be hidden from the normal, everyday user. That is true when it comes to finding communities as well. The interface must appear consistent, and so the boards that communities live on need to span the entire network.

To make this a reality, we separate boards from individual servers. A board can exist in multiple servers simultaneously, and still be the same board. This allows the UI to present each board as a single entity, and only one will exist throughout the entirety of the network.

Boards would be tagged with a series of topics or keywords, things that define the community itself (like “3d printing,” “anime,” or “hiking”) and things that describe the community on a more meta-level (“NSFW”, “Kid-Friendly”, “videos only”). These tags would be set by moderators and can be used by administrators to filter what communities they would allow on their instance.

The key thing to worry about here is that a community is singular within the network, even if at a technical level it is split across many servers. The ongoing theme here is that the federated system must appear centralized from the user perspective.

Privacy Is A Human Right

I firmly believe that privacy is a fundamental human right, and this network allows for privacy at multiple layers.

Here are the things we must consider when making this system user-friendly for privacy:

• Personally Identifiable Information, or PII–names, dates, etc. but also things like IP address and geolocation.
• The content of posts, comments, etc.
• Ownership of a given server.

Taking each one in order:

For PII, we simply do not collect it within the network. The system is decentralized but strongly federated, meaning individual server admins can’t create their own user requirements for their server. All servers share the same user database, and users can log into any given server.

For the content of posts and the like, these must always be owned primarily by the creator. If the creator wants that information gone for some reason, they simply delete it. The decentralized network is necessarily eventually consistent, so deletes may take some time to traverse the whole network but are always honored within the network.

Finally, server ownership. What I mean here is allowing server administrators themselves to remain anonymous if they so desire. This is relatively simple of course–as the network is largely hidden from the end user, they do not know what server they are ever on. Just as server administrators do not know what users they run, users do not know who their server admin is.

Moderators Moderating

I will readily admit here that I have never moderated a large community. I have spoken to moderators in the past and learned through reading complaints and thoughts of existing moderators of the tools they would like to see. Even so, this section will be light on details due to my own lack of experience. I did not contact any current moderators (or anyone at all really) when writing this post, so if you’re here to pick holes in my design, this is probably where to start!

Automate everything you can…

The basics of automated moderation have been a solved problem for a long time. Think spam filters and block lists, things of that nature. There’s no need to reinvent the wheel here–we simply need to integrate with existing spam filtering tools and implement well-known, existing moderation systems. There’s nothing novel here.

Moderators will have access to tweak these settings for their own communities. There must be sane defaults, of course, so that a new community isn’t setting everything up on their own, but communities must be able to customize to their needs.

To prove this is important, let’s take a contrived example. A community of scam-baiters has spun up a new board on CoolNewSocial. They talk a lot about the scam of the day, and sometimes share links around for fellow scam-baiters to use. The default spam blocking configuration flags these links and some of these messages, rightfully so for most, and prevents them from being posted. In order to allow this community to freely talk about these scams, the moderators of the community need to be able to reduce the sensitivity of the spam filter.

In general, spam filters will include bad links, hash-checks of images and videos, general keyword filtering and other similar techniques. Notably, users on VPNs or using anti-fingerprinting tools must be treated the same as any other users in order to preserve privacy. This does limit some options for spam filtering.

…and simplify everything you can’t automate

Not everything can be automated, but we can make things as simple as possible. Moderating does not need to be a full-time job, but it does need to be an active responsibility.

Users will always report problematic behavior, much of which is truly worth acting on but some of which is not. There’s no good way to separate the two. Sometimes a moderator will come across a bad actor, and will need to take action.

The best we can do here is to make this as painless as possible. A button click to block a person, or to delete a comment, or to hide a comment, or whatever makes sense at the time. I cannot think of a great solution to this, which leads to…

Problems, problems everywhere, but not a solution in sight

Real talk, moderating is a hard problem, and no one has solved it yet. The suggestions I make above are surface level, well-known, and not novel or unique–they’re literally what everyone today does. Meta and TikTok hire full-time moderators¹¹ to do this job.

Moderators have to deal with the worst of human behavior, and in a federated network like this, they have to do it for free or very little. On top of that, there’s no good way for a moderator to keep communities on-topic without manually addressing comments and posts that stray.¹²

In the future, AI, LLMs, or ML may help to improve this situation. We should be very wary of relying on it exclusively, though, especially today. Moderators must be able to adjust the sensitivity and “attitude” of any filtering system in place, and these technologies today don’t have that level of control.

As a side note, in my opinion, you should be wary of anyone who says that AI will solve the problem today, because they’re trying to sell you a solution that doesn’t exist yet. Also be wary of anyone who says that AI will never solve the problem, because they’re either trying to sell you a solution to a non-problem or trying to prevent change. These are all very promising technologies, and have some legitimate use cases even today. There is a lot of misinformation and FUD surrounding them, but there are also a lot of companies going a bit too strong into them without thoughtful consideration. I’ll leave my thoughts on AI here for now, as they could be a post on their own.

What does this mean for this design? Well…moderators need to be committed, and need to volunteer. This isn’t any different from existing link aggregators today.

What about user moderation?

Communities are defined by what the community creators–typically the moderators–set as the rules. Non-moderators can enforce these rules in small ways, though, through the scoring system. This addresses some problems of things like staying on topic, but only so far as the community is willing to participate.

The scoring system allows users to specify a given comment as off-topic, misinformation, incorrect or otherwise not contributing to the discussion. Moderators can take this a step further. In the example I gave in the user section, Alice either gave or took away points based on how she voted, but specifying misinformation also caused a post to be demoted and hidden. This behavior is controllable by moderators of communities.

Different categories of “upvote” or “downvote” can be weighted when added to the point value. For example, “misinformation” can be weighted at 2.5x, so that every misinformation “vote” is equivalent to 2.5 points taken away from the total. Alternatively or in addition, posts that are frequently rated a certain way can be hidden or even deleted to remove them from the discussion. Posts that are frequently highlighted with positive reactions can be given a badge or even weighted more highly to rise further up to the top of the page.

Users with frequent reactions to their posts in a given community can be badged or flagged. This could be either a badge of honor or shame, depending on the community and the moderators. This can help encourage users to contribute to the discussion and to not fall into some negative traps.

As an important point of note, not all reactions will be available to all boards. Depending on the board’s tags, some reactions may be unavailable, or may change their meaning. As an example, a NSFW tagged community will not see “NSFW” as a “downvote” option.

Can this scoring system be gamed? Absolutely. However, I think this is a better solution then what we have now, and would encourage better behavior in the users who engage.

Administrators Administrating

As an admin of most services, you get complete, unfettered access into everything about the services you run. You have root access, after all! Here, things are a little different.

Let’s consider for a moment a large service run by a single company. It could be anything. That company almost certainly doesn’t run the entire service on a single server, right? Of course not¹³! Most companies these days run their services on infrastructure distributed across multiple data centers for resiliancy¹⁴. Now, what if a different person owned each individual computer running this service¹⁵?

That’s what this system is. The admin cannot have full access to everything, because everything is distributed across multiple nodes in the network. So what can an admin do?

An admin can do two main things:

1. Specify the resources available to the network from this server. The admin can specify less than the server has available, but cannot specify more. This includes memory, storage, compute power, network bandwidth and latency, etc. This will directly affect how much traffic and how much content this server receives.
2. Set a series of tags that limit what communities may be hosted on this server. This mostly exists to prevent people from serving content they find questionable or might not be legal in their country. There are two sets of tags: meta tags which are defined by the network and are limited, and topic tags which are defined by community creators and are not limited. Notably, an administrator cannot specify an allow-list of tags. Only a block-list.

While there are other settings an admin will be able to change, they are limited and do not directly affect a user’s experience on their server at all.

The Gritty Details

Well, not really, this is just a 40,000-foot view, after all.

Let’s talk about how this works.

First: the protocol itself. I won’t go into explicit detail, but the protocol should be a primarily binary protocol to reduce the amount of data flowing over the network. Data should be stored in a compressed form, and in most cases should be split across multiple servers–a single server shouldn’t have the entirety of one post or comment.

Next: I mentioned it a few times above, but this system works like a distributed service in a datacenter, except the datacenter is all admins who join the network. This poses a few unique considerations from a traditional federated system:

• What happens when part of the network goes away, as will happen constantly?
• How do servers talk to each other?
• How does security work?
• Do admins get compensated for this, and if so, how?

Distributed distribution

Let’s start with the second question: how do servers even talk to each other?

Servers use a consensus mechanism to determine what data is where. Effectively, this is a DHT which forms a part of a distributed database. But let’s back up a second–how does a server even know how to join the DHT? And wait, there’s a single URL for all users, but who owns that?

Lord of the Root

Let’s again start with the second question: The primary URL is the one point of centralization in the system. The original developer of the network will likely own the primary URL that people use to access the network. This will also be the primary URL that at least the first servers use to access the network.

This is only important for bootstrapping. Once established, this URL becomes far less important for the network. Every server will need its own Fully Qualified Domain Name, FDQN, in order to be accessed by the local administrator. Servers will know a subset of other servers’ FQDNs on the network, in order to talk to multiple servers on the network. These servers will also know what the primary URL is, as owned by the original network creator.

If that creator goes away, turns out to be malicious, or is otherwise not capable of running the primary entry point, other administrators can change the primary URL. They do this by updating the primary URL that their server considers canonical. Importantly, however, it doesn’t immediately change. Nearby servers advertise who they consider the canonical primary URL of the network, and advertise counts of each configured primary URL. Once a given percentage¹⁶ is reached, the network flips. The primary URL changes for all servers in the network, and direct users to the new URL seamlessly¹⁷. External links won’t even be broken (unless the original server goes away or is maliciously modified), as the servers on the network will automatically redirect URLs as needed.

Servers talking to servers

You might have caught it earlier, but just in case you didn’t, every server has its own FQDN. This means that servers do not need to talk to the server at the primary URL, and in fact there is no “leader” server. Servers operate on consensus and distributed tables and databases. Once you’re in the network, it doesn’t matter where you talk, you will get the info you need somehow.

When you set up a server, you put in whatever URL you like as the “primary URL” of the network. As long as that URL is an existing server in the network, the new server will connect to it, announce its arrival, and be directed to a series of neighbors. These neighbors will be distributed–several physically nearby but many that could be hundreds or thousands of miles away. This prevents parts of the network going missing due to a natural disaster or something.

As noted, the primary URL the server uses is the one that is considered canonical within the network, which may or may not be the one that admin originally configured.

This method of distribution prevents the pitfall of talking to every other server, but introduces a level of latency to posts. This is a link aggregator and not an instant messaging system, however, so that latency is an acceptable compromise.

A Balancing Act

Okay, but if all users are coming into a single URL, that server is going to get overloaded, right? To a certain degree, yes. One of the bits of information servers get about other servers is their rough geographic location via IP address¹⁸. The primary server, the one acting as the entry point for all other servers, will spend most of its time as a load balancer, directing requests to whatever server on the network is closest to the requesting user. This does mean that there is a level of centralization here, but it is possible to bypass this “central” server entirely.

Any given server only knows about its neighbors, so in order to direct the user it needs to build a local cache of as many servers on the network as it can. The servers in this cache are not “neighbors,” they are instead only considered when making routing decisions. The cache gets built in a manner similar to a basic routing protocol. The first request will be directed to the neighbor physically closest to the user, which will then direct to its physically closest neighbor, and so on until the request hits a nearby server. The server will be roughly close to the apparent location of the user, but remember we’re just using IP-based geolocation. If they’re behind a VPN or a poorly-managed network, then the server itself may not be nearby. Because this is an estimate, we can just drop to any server we find out about within a certain radius.

As the request traverses the network, this first hit may be slow for the user. However, each neighbor will be reported up the chain to every server the request passed through, which will build the cache all the way up to the root. This means subsequent requests by any user in that region will be immediately directed to a close by server based on the cache.

When a user tries to access a different server, that one will itself direct traffic to the server closest to the user¹⁹. The user can continue to use this alternate server exactly as if it was any other–URLs will be rewritten and all the content will appear the same. Eventually, the user may end up back at the primary URL, but they shouldn’t be able to even notice.

Posts, Posts Everywhere

So what if a post doesn’t exist on the server I’m looking at? That’s where the distributed nature of the database comes in. The server you’re talking to will communicate with its nearby servers to get a local copy of everything in the page.

The page may not be stored entirely on a single server–comments could be on other servers or parts of the post could be split apart. The server you’re working with will reassemble the contents as it receives them, and will make the page visible once it has put together the pieces. The server will then store this page, in its entirety, in cache. However, it may not keep it in perpetuity. The network will split the page and distribute each portion of it to multiple servers to maintain in perpetuity, which may or may not include the server you are on.

When you comment on a page, it will be saved on the server you’re on and distributed to a few of its neighbors. Those neighbors will distribute it and so on, depending on the specific hashing algorithm in use. Edits will go in the same way, but will only be eventually consistent–some people may be able to see the old version of a post after it’s been changed, for a short while. Deletes work the same way, travelling through the network.

Resiliency is the name of the game

If a server goes away, temporarily or forever, the data on it is not lost to the network. It was replicated to multiple servers, and once the neighbors realize that they have not received a heartbeat from a given server in a long enough period of time, they will announce the departure to the network.

The hashes that node stored–available to everyone in the network because of the DHT–are replicated again if needed to ensure enough copies remain in the network for resiliency and speed.

Security And You

No system is perfectly safe from all threats, especially not a distributed one like this. There are a lot of potential concerns and pitfalls, but let’s talk about two in particular: User accounts and malicious servers.

Keys to your own Kingdom

The most concerning aspect of this is the user account database. Fortunately, this problem is mostly solved with WebAuthn, the protocol behind Passkeys.

The user account database is also distributed, and there is no secure information stored in this database. There are no passwords on this network–WebAuthn public keys are stored in this database, which are, well, public. From a user perspective, as long as they are using a modern system, the experience is even easier than a password–just click a button, and you’re in.

As this database is itself distributed, multiple copies of the data must agree on what is contained in a user entry whenever it is accessed. That could be for signing in, or for checking what level of permissions a user may have in a given board.

A problem for your consideration: How might you allow the user to make changes to their account? We’ve negated the effect of a single malicious admin by requiring agreement with multiple copies on reads. How would you ensure that writes are authorized by the user?²⁰²¹

No Oscar for that Bad Actor

Bad actor servers within the network can cause chaos. They may exist to try to exfiltrate data, or to just disrupt normal operation of the network. While no distributed system can be 100% protected against bad actors, there are some basic things we can do to start taking care of the low-hanging fruit.

First: heartbeats. Occasional pings every few minutes to all of a given server’s neighbors, indicating merely that it is still alive. This helps against black-hole servers that suck as much data as they can but then go offline with it to try to reduce network resilience. It also helps against servers which pop up then immediately go away–this is frequently due to someone spinning up a new server, but may be an attempt to cause unneeded latency within the network.

The agreement of multiple servers about data is important as well. Every so often the network audits its data to ensure it is as correct as possible. Posts may change on a server here or there due to bit flips, but also potentially for malicious reasons. Data that is inconsistent is expunged from the network and corrected, but a malicious server may not delete that data.

We mitigate this problem with the “nosy neighbor protocol”: Servers keep track of how often their neighbors have invalid data, for each individual piece of data. If one server frequently reports the same data incorrectly, or frequently reports incorrect data in general, the neighbors will alert the network of a potential bad actor. The network puts that server into a sort of “time out,” where it continues to interact on that network, but is sent no real users. Simulated users–designed to look as similar to possible as real users–will occasionally “visit” it. If the problem server doesn’t start to behave after a period of time, or it has gone in and out of time out frequently, the network will kick it out and ignore it from then on.

Servers follow standard security protocols beyond these of course, such as rate limiting, preventing injections, and just generally treating all of their neighbors as hostile. These are just a few examples of techniques used to mitigate problems.

Money makes the world go ‘round

Finally, let’s talk about keeping the lights on. It’s not cheap to run a server of any sort, and this network will involve a lot of inter-server communication (though less than some other networks that exist today). How do we ensure that admins can afford to run their servers, and are incentivized to do so? Well, I have some thoughts.

Incentives Are Not Real

Let’s talk incentives, or rather, the lack thereof. It’s not really possible to sustain an open source project by donations alone. With few exceptions, maintainers of all open source projects are primarily a corporate sponsor, a series of employees of companies that need the project, or a gracious volunteer. In the latter case, some cost of the project may be offset by generous donations, but in the vast majority of cases not nearly enough to be sustainable as a day job.

This is likewise the case here. Admins will primarily be expected to run this out of the goodness of their hearts. There are some basic solutions for donations to offset some cost, but generally speaking this will always be a time sink and a money sink. There is nothing lucrative here, other than the satisfaction of providing a service for people who want it.

This isn’t limited to just this design, though–this is true of most fediverse today, and is even true of Reddit²².

Crypto ain’t Cool, Bro

Some folks will immediately pop up and say, “Clearly, cryptocurrencies are the answer!” In my opinion, clearly, they are not.

There are many, many problems in the crypto space today, not the least of which is the co-opting of the term “crypto,” and I won’t trouble you the reader or myself with all of them.

Cryptocurrencies are, in general, really unstable. Most vary wildly in value on a minute-to-minute basis, making them unsuitable for a method of donation to most people. Of those that are not, they are difficult or at least additional friction to convert money into, which then must be converted out of again in order to make use of it. Even those that are somewhat stable²³ are prone to failure and have questionable financial practices²⁴.

Leaving those issues aside, there is the possibility of mining on a user’s machine while they use the website. This has been done to some success by less reputable websites in the past. However, it is both rude to the end user, needlessly harms their battery if using a laptop or phone, and ultimately provides very little, if any, actual value in the end.

While the promise of crypto was great in the early days, these days it’s merely become a speculative market. It isn’t particularly worth taking seriously as anything except a highly-volatile financial market. Blockchains, the technology behind cryptocurrencies, do have some potential but are not useful for our design here, and will not help keep the lights on by themselves.

You Can Do It, but It’s Up To You

Instead, there are two possible paths that can be taken here:

• Advertising
• Distributed donations

Both follow the same general model, and I don’t really want to consider advertising personally, so let’s talk about distributed donations.

Every server admin has the choice to set up an account on one of a limited few donation-accepting sites. The basics of this account, like the service and the name of the account, are added to the server config.

When the load-balancing server directs traffic to a given server, that server is the one that is loading the page and everything on it. The service will put the donation details on the page somewhere in a somewhat prominent location for users to see. If they choose to donate, the money will all go to the admin running the server (after the donation service takes their cut).

A simple solution, but it guarantees the people running the servers are the ones getting compensated. It means that they are potentially getting compensated in proportion to the amount of users they are receiving, which should be roughly related to the size of their instance.²⁵

This isn’t a perfect system, but including donation or some other form of compensation in the base design of the network is critical for something distributed like this. It is expensive to run servers, and without enough money to do so, the network could grow unstable as too many nodes start to drop off.

So Why Won’t This Work?

There are several technical and social problems that exist in my design, I will admit. I’m only one person after all, and haven’t really spent a lot of time thinking about this. Some holes I mentioned, some I decided not to mention, and some I’m sure I never even thought of myself. None of that is as important as the most important reason a new link aggregator like this would never work today:

The Network Effect.

It’s a vicious cycle. Without users to comment, no one will make posts. Without posts, no users will come to comment. It’s really as simple as that.

This can, of course, be overcome–every social media site that exists today had their own methods. What would the best way to overcome that issue with this network be?

That, my friends, is an exercise best left to the reader.