Aktor

Aktor is a Fediverse server derived from GoToSocial 0.21.2.

It started as a fork because ActivityPub federation is a large compatibility problem, and GoToSocial already solved many of the hard operational details in a clear Go codebase. Aktor is no longer a GoToSocial-compatible fork in the usual sense: the UI, configuration surface, storage direction, administration tools, maintenance jobs, and database schema have changed enough that it should be treated as its own project.

The public C2S and S2S protocols still matter. Aktor tries to preserve Mastodon/GoToSocial-compatible client APIs and ActivityPub federation behavior where that compatibility is useful, but new Aktor-specific functionality is documented explicitly instead of being hidden behind upstream assumptions.

What Aktor Adds

Aktor keeps the useful base of GoToSocial and adds the parts needed for a smaller, more personal, more operator-controlled Fediverse server.

• A Tumblr-inspired web UI: the web experience is part of the product, not an afterthought. The local UI includes the Aktor landing page, login flow, timeline, post permalink pages, compact notification cards, and administration panels.
• Embedded IPFS media storage: local media can be imported into an embedded Boxo/IPFS node and served through Aktor-owned /ipfs/<cid> URLs. This is a provider-only media layer, not a public arbitrary-CID gateway. See IPFS.md.
• Lua moderation filters: administrators can store Lua 5.4 filters in the database. Filters receive read-only post/account context and decide whether a post is accepted or blocked. See FILTERS.md.
• Group accounts: a group account can automatically accept followers and redistribute top-level posts addressed to the group. The repost keeps the original author visible with a From: line and is delivered through the normal timeline/federation path.
• RSS-to-post publishing: administrators can attach RSS feeds to local accounts. Aktor periodically reads the feeds and publishes new entries as public posts, with duplicate protection and per-feed rate limits.
• Registration capacity control: AKT_ACCOUNTS_REGISTRATION_MAX_USERS controls whether registration is unlimited, single-user/admin-only, or open until a configured local-user limit is reached.
• Inactive local-account cleanup: AKT_ACCOUNTS_INACTIVE_DAYS sets the maximum number of days a non-admin local user may go without posting or replying before the maintenance job queues the account for deletion.
• Monthly administration statistics: administrators can inspect federation traffic, Lua filter decisions, rejected delivery targets, rejected delivery recipients, and local user capacity. Large tables are grouped with an others row after the first ten entries.
• Remote federation expiry: old remote statuses can be cleaned up with AKT_STATUSES_REMOTE_MAX_AGE_DAYS, keeping local storage from growing forever because of remote traffic.
• Aktor environment variables: new configuration is exposed through the AKT_ prefix. The old GoToSocial configuration-file path remains transitional while the fork is being reshaped.
• Docker-oriented operation: the repository builds a container image and ships smoke tests for the server, UI, APIs, Docker runtime, and feature contracts.

Installation

Read INSTALL.md. It explains three supported local deployment paths:

• a standalone binary;
• a single Docker container;
• a Docker Compose stack with Aktor and PostgreSQL.

The install guide also lists the required environment variables, feature configuration, restart scripts, and operational checks.

Documentation Map

• INSTALL.md: build, run, restart, Docker, Docker Compose, and configuration.
• IPFS.md: embedded IPFS behavior, required variables, storage paths, ports, and operational notes.
• FILTERS.md: Lua filter administration, runtime behavior, and the complete read-only input table.
• ROADMAP.md: the Aktor 2.0 Phoenix roadmap.
• LEGAL.md: licensing boundaries between inherited GoToSocial code and new Aktor work.

Why Not Start From Scratch?

I tried more than once to build a complete Fediverse server from scratch. Basic local posting is not the hard part. Federation is.

Every ActivityPub server family has details, habits, extensions, and sometimes surprising interpretations of the same standards. GoToSocial is a pragmatic and understandable implementation in Go, so Aktor starts there and spends its energy on the parts that are different: a more expressive UI, stronger operator tools, smaller-instance assumptions, and less dependence on centralized media storage.

Decentralized Media

Aktor is skeptical of performative decentralization. A Fediverse server that stores and serves all media through a large centralized object-storage provider still leaks important information to that provider and inherits that provider's jurisdictional risk.

The first Aktor answer is embedded IPFS. Local media can be addressed by CID, served through Aktor's HTTP layer, and made available to IPFS-capable peers without handing normal media delivery to S3. If this direction proves insufficient, future work may evaluate other decentralized distribution models, but S3 is intentionally not the goal.

Licensing

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 Aktor-specific work is released under the European Union Public Licence 1.2, unless explicitly stated otherwise.

This is not a rejection of copyleft. The EUPL is a copyleft licence written for the European legal framework, available in the official languages of the European Union, and better aligned with where Aktor is developed and defended.

Credits

Aktor would not exist without GoToSocial.

GoToSocial repository:

https://codeberg.org/superseriousbusiness/gotosocial

I also want to acknowledge snac2, which shows how direct and understandable an ActivityPub server can be.

snac2 repository:

https://codeberg.org/grunfink/snac2

European Union Public Licence 1.2:

https://eupl.eu/1.2/en/