Cross-Chan Alliance

CLEANUP CANDIDATE

Relevant discussion may be found on the talk page. Reason: Basic Article to start

The Cross-Chan Alliance is a network of Exodus chans made in response to the downfall of 8kun, all working together. This page details an attempt at this by Julay.World

What is the Imageboard Federation?

The imageboard federation is a currently work-in-progress system which will eventually become a full-fledged federation of imageboards. In the federation, boards from all nodes are merged into global boards. These boards get posts and threads from all nodes. Users can post in the same threads from different nodes, and can reply to each other. The file data is stored on the node it was originally created in.

The idea of the system was inspired by the Fediverse/GNUSocial. In GNUSocial, the federation system was built in a similar way, but instead of boards federating, the users federate themselves.

The current federation API draft can be found here.

What is Final Solution?

Final Solution is the current work-in-progress implementation of the imageboard federation. It is written in Python and consists of two parts.

1. FinalSolution: The backend, which provides the API for accessing posts. This part basically acts as an imageboard API.
2. FinalFrontier: The reference front-end for FinalSolution. It is implemented as a separate application and uses FinalSolution's API to generate web pages. It supports both JS and Non-JS users.

Can I help develop the imageboard federation?

Absolutely! In fact, developers are really needed because I haven't had any time at all to work on FinalSolution. If you know Python programming, you can contact me and I can help you with any pointers you need. If you have an idea that could benefit the imageboard federation, that's fine too — just let me know.

Why make it in two parts?

A couple of reasons. First off, keeping only the imageboard engine part of the imageboard in the package means that the FinalSolution code is not concerned with front-end generation and thus has less overhead to consider. Second, because only the engine part remains, it becomes very easy to create a full unit test suite with 100% coverage, ensuring that FinalSolution is as stable as it can be. The "imageboard API" concept also makes it extremely simple to implement front-ends other than the web front-end. Since all data that needs to be displayed is required to be in the API (because the web front-end also uses the API), you can easily write a TUI or mobile front-end for any FinalSolution imageboard.

So how do these "federated boards" work?

Let us think of two federation nodes, A and B. Both of these nodes have agreed to have a federated global board, /a/. When a user makes the first post of /a/ from node A, a thread is created and its ID is A:1. When a user from node B replies to >>>/a/A:1, their post ID is B:1. Essentially, if imageboards choose to federate a certain board, it becomes a single board which people can post to and receive replies from every single node that has the board.

What happens when I post an image?

FinalSolution currently does not have file uploads, but the plan is to keep every file that is posted in a certain node on that node, and when a file is going to be displayed, the file is fetched by the user from that node.

How does moderation work in an imageboard federation?

Moderation on a federation would be local, in other words, posts would only be deleted from the nodes that decide to delete it. Likewise, reports would probably be local to nodes, although this is open to discussion.

Can anyone join the federation at will?

Because the imageboard federation is anonymous and the board moderation is local, simply having anyone join the federation at will would mean the federation would be very easy to spam and abuse. Due to this, the federation depends on a trust mechanism to explicitly include new nodes. This is basically how the Webring works anyway.

Post IDs look weird. Why NODE:ID?

Because the imageboard federation is no longer a centralized, single entity, it becomes very hard to maintain a single, monotonically increasing post ID across all nodes for a board. What if two people post from two different nodes at once? There would be an obvious post ID conflict. The solution that I (with some help from others) have come up with is to make post IDs depend on the node that they're posted from. This does mean that post IDs won't accurately represent how many posts the board has at first glance and that they look "uglier", but nodes will simply display that information on the board list.

Doesn't local moderation mean that bans are worthless?

Unfortunately, yes. Though I am currently thinking of possible ways to identify posters across nodes without making the node expose their identity. If you have an idea for this, feel free to let me know.

In some games like "Rust", "Arma 2" and "DayZ Standalone" servers have a system where staff members are alerted when a player joins with an IP banned in multiple places. (IPs are stored in a hashed form to protect privacy.) I think a similar system where imageboards selectively choose to receive the banlist from other imageboards (by entering their addresses) would work. It'd help moderation without immediately banning users. Dlthl (talk)

Python sucks. Use a better language.

Python makes it really easy to quickly iterate on changes. Once the API of FinalSolution stabilizes, there are plans to re-implement it in faster languages.