| .vscode | ||
| archive | ||
| cmd | ||
| internal | ||
| scripts | ||
| smoketest | ||
| test | ||
| testrig | ||
| tools | ||
| vendor | ||
| web | ||
| .dockerignore | ||
| .drone.yml | ||
| .gitattributes | ||
| .gitignore | ||
| COMMERCIAL.md | ||
| docker-entrypoint.sh | ||
| Dockerfile | ||
| go.mod | ||
| go.sum | ||
| INSTALL.md | ||
| LEGAL.md | ||
| LICENSE | ||
| mkdocs.yml | ||
| README.md | ||
| ROADMAP.md | ||
| smoketest.py | ||
Aktor
Aktor is a personal fork of GoToSocial 0.21.2. It has been stripped down to the parts I need in order to build and evolve a smaller Fediverse server, with a different web experience and a different direction for storage.
The immediate definition of done is simple:
- the repository no longer contains upstream process documents that do not apply to this project;
- the README, roadmap, and licence describe Aktor rather than GoToSocial;
./smoketest.py -buildcan build both the server and the Docker image. And TEST them.
Why create a new instance by forking an existing one? What motivates you?
I have tried several times, in different languages, to build a Fediverse instance from scratch. Each time, I reached the point where the basic features worked. Then came federation. The JSON part is fine, even trivial sometimes.
And federation is where things become complicated. Every server seems to have its own interpretation of how the protocol should be implemented, and today there are many of them. And, the protocol definition doesn't helps, since most of times is not covering the differences.
I am not especially interested in spending my time compensating for the W3C’s ambiguous and often poorly written ActivityPub documentation, which lead to this chaos of different implementations, with a bully (or more than one!) in the room, who thinks he can do whatever he wants, and breaking the protocol,"cause I am strong enough", like any Trump does. Rather than keep fighting that battle from scratch, I decided to stand on the shoulders of a giant. Since I like Go, GoToSocial looked like the right foundation.
But there is another reason. I want something better.
In the Fediverse, the dominant user interfaces still seem to follow either the Twitter timeline model or the Facebook feed model. These interfaces were not designed primarily to help users have fun, express themselves, or build meaningful interactions. They were designed to help companies monetize attention.
The best example I remember of a social interface that felt different was Tumblr. I do not intend to reproduce Tumblr exactly, but I do want to borrow some of its spirit: something direct, simple, expressive, and enjoyable.
So Aktor is not meant to be a headless instance. By forking GoToSocial, I save time on the federation layer. I want to invest that time back into a Tumblr-inspired UI and UX.
Part II: Decentralization should not be just for show
I am also tired of performative decentralization.
Many people developing Fediverse software present themselves as champions of decentralization, fighting against the big internet corporations. Yet, when it comes to media storage and delivery, the default answer is Amazon S3. Always Amazon S3.
Have you realized that when you put something on S3, Amazon does not only know which server it came from, but from that moment on ,it will also know the IP address of anyone who views that image in a browser?
And have you realized that, from that moment on, you could lose everything simply because of a legally binding order from the United States requiring Amazon to delete the content?
That is a contradiction, or people doing that is doing performative decentralization battle.
So are we really against giving user data to large internet corporations, or are we just performing decentralization as a fashion statement?
This is another reason why I chose GoToSocial as a base: I want to experiment with IPFS as a media delivery layer. IPFS can act as a decentralized CDN without placing media delivery in the hands of a GAFAM platform.
And if IPFS does not work, then I will try the Syncthing API to share images. After that, native torrent support. Anything, really.
But not S3.
And when users have IPFS support in their browser or local environment, media can be retrieved locally, while IPFS itself takes care of transferring and distributing the content.
Roadmap and licensing
The roadmap has also changed.
Anyone interested in Aktor should read both LEGAL.md and ROADMAP.md, because they describe the current direction of the project, the licensing model, and the boundaries between the original GoToSocial codebase and the new Aktor work.
All code inherited from GoToSocial, including GoToSocial 0.21.2 and the previous upstream history, remains under the GNU Affero General Public License as originally released.
From the Aktor fork point onward, new original work in this repository is released under the European Union Public Licence 1.2, unless explicitly stated otherwise.
In short: the past remains AGPL, while the new Aktor-specific work moves forward under EUPL 1.2.
Why move from AGPL to EUPL?
The reason for moving new Aktor-specific work from the GNU Affero General Public License to the European Union Public Licence 1.2 is NOT a rejection of copyleft.
On the contrary, the two licences pursue very similar goals: keeping the software free, preserving the freedom to study, modify, and redistribute it, and preventing proprietary appropriation of the work.
The practical difference is jurisdictional and institutional.
The EUPL is an official European Union licence, available in all official EU languages and designed within the European legal framework. For a project developed and maintained in Europe, this makes it a more natural legal instrument.
In particular, enforcement in a European court should be simpler and less ambiguous, because the licence is rooted in EU legal terminology and recognised within the legal framework of the European Union.
So the change is not about weakening copyleft. It is about using a copyleft licence that is closer to the legal environment in which Aktor is developed and defended. The European Union.
Gradual migration
Aktor is still very visibly derived from GoToSocial, and that will remain true for some time.
As I develop the parts that matter most to me, such as groups, IPFS-based media delivery, and possibly other decentralized protocols such as I2P, references to GoToSocial will gradually be replaced by references to Aktor.
This will not happen overnight. GoToSocial is a large codebase, and replacing names, documentation, assumptions, and internal conventions requires care. But the direction is clear: over time, Aktor will become less of a visible fork and more of its own project.
The codebase will also be progressively migrated toward a stricter engineering style inspired by EAL5+ practices. This does not mean that Aktor claims any formal EAL certification. It means that the code should become more explicit about its assumptions, contracts, invariants, and expected behaviour.
In practice, this means more inline contract documentation, clearer boundaries between components, and stronger tests built around those contracts.
The goal is not only to make the software work, but to make it easier to understand why it works, what each part is allowed to assume, and what must never be silently broken.
It will take time.
Credits and acknowledgements
Aktor would not exist without GoToSocial.
This project starts as a fork of GoToSocial 0.21.2, and I want to explicitly acknowledge the work of the GoToSocial developers. They built a solid, practical, understandable Fediverse server in Go, and Aktor stands on top of that work.
GoToSocial repository:
https://codeberg.org/superseriousbusiness/gotosocial
I also want to thank the snac2 project, from which I learned a lot about keeping ActivityPub software small, direct, and understandable. snac2 showed me that a Fediverse server does not have to become a huge, opaque machine in order to be useful.
snac2 repository:
https://codeberg.org/grunfink/snac2
Finally, I want to acknowledge the European Union for publishing the European Union Public Licence. The EUPL gives European free software projects a copyleft licence written for the European legal framework, available in the official languages of the Union, and recognised within that legal environment.
European Union Public Licence 1.2:
Aktor is built on existing work, existing lessons, and existing legal tools. The goal is not to pretend otherwise, but to make that inheritance explicit and then move forward from it.