In the thread Should we join forces with TopAnswers?, @marklar423 mentioned that it might benefit Codidact to become a federated system, sort of like Mastodon. This eventually lead to the following statement:
Since the how is yet to be determined (and I can’t seem to stop thinking about it), I’ve decided to start a thread to begin the process of fleshing out some of the details.
My brainstorming has led me to two distinct options.
NOTE: While this is not necessarily MVP material, I also marked it as MVP-adjacent, because the how may very well influence aspects of the MVP.
Option 1: Mastodon-esque Federation
It is my understanding that Mastodon works somewhat like this:
- Each node is a completely separate instance of the mastodon software that can work completely isolated from the rest of the network. It has its own database, authentication system, physical (or virtual) servers, and users.
- Through a set of Standards/Protocols baked into the software, the individual nodes are able to communicate with other nodes and any other software that implements the same standards. (i.e. Mastodon nodes and GNUsocial nodes can/could communicate)
Advantages
- Each node is able to develop almost completely independently, as long as the standards/APIs/protocols are implemented.
- No node is reliant on any other for its basic functionality (i.e. if the main Codidact instance went down, any federated instances would still work fine, they would just be unable to access any Q&As stored in the main instance’s db)
- The ability to pick and choose which instances communicate with your instance. (i.e. The main Codidact instance could refuse to pull Q&As from questions.neo-nazis.fakewebsite)
- Eugene Rochko (creator of Mastodon) uses his platform (probably somewhat obvious), and would therefore be easy to reach out to as a potential source for implementation tips.
Disadvantages
- Node administrators need to stay vigilant; “undesirable” nodes will need to be manually blocked as they pop up if federation is enabled by default, or desirable ones will have to be added as they form if it is disabled by default.
- No inherent cross-node login. While OAuth can help, because each node is very independent, there is no guarantee that Bob@Codidact and Bob@TopAnswers are the same person.
- Related to the previous: Namespacing. Mastodon uses an email like syntax to show which node is “home”. (i.e. Everyone becomes @name@node, instead of simply @name.)
- The network becomes more complicated if nodes are allowed to answer questions cross-network.
Other
- This method relies on setting very solid standards/protocols/APIs before the federation begins, and future changes will likely need to be backwards compatible, unless of course no one cares about any of the Q&As from that one node that doesn’t like to update.
Option 2: Shared Resources Federation
Another way to create a federated network is to share a few key resources across the entire network. Database and Authentication system come to mind as prime candidates.
Advantages
- Single login across the entire network. If the whole network shares an authentication system, an account created on one node, would be an account created on all nodes.
- Shared database enables easy cross-node contribution. Furthermore, users are free to chose whichever node suits their tastes if there are multiple of the same topic.
- Burden sharing between communities. Since all nodes rely on (some of) the same systems, it is not entirely unreasonable to ask that they all contribute to the upkeep of said systems.
Disadvantages
- Single point of failure. If the shared systems go down, the entire federation goes down. Theoretically, the likelihood of this occurring decreases as more nodes join due to burden sharing.
- Content that is “undesirable” on any particular site could/would eventually enter the database. Each site would need to set some sort of filter mechanism to only get the content they want (i.e. questions.meatismurder.example probably doesn’t want content from hunting.cookemup.example)
- Any shared resources must suit the needs of all nodes in the federation.
Other
- This method also relies on a very solid API, but once that is established, the shared resources can become modular (i.e. The entire database could be changed as long as the new database can be accessed in the same way)
- Due to the importance of the shared resources, a new group would likely need to be formed to manage them. Ideally this group would have representative members of all (major) nodes of the network.
- Like most proprietary sites, usernames would likely need to be unique across the entire federation. Bob here is Bob there, but if someone gets the name Bob before you, it’s gone.
As with most things in life, both of these options come with trade-offs. I tried to be as fair as possible in presenting them, but I am sure there are advantages and disadvantages that I haven’t thought of (probably entire methods too, this pair just got stuck in my head).
There is also the easiest option of just making our data easily accessible so people can take and and do what they will (within licensing, of course). However, that doesn’t really make for any kind of “federation”, so I left it out.
tl;dr
We could make a federated network using a Mastodon-like method, or by sharing key resources like the db. Both have advantages and disadvantages that may help us decide which is better for our use case.
So there you have it. My two ideas on how to federate Codidact! If we like one over the other, we can flesh out the nitty gritty details. (For the curious, I am currently leaning slightly toward option 2 because it seems a little easier in my head).