itepechi/akkoma
1
0
Fork 0
Code Issues Pull requests Releases Activity
A fork of AkkomaGang/akkoma
16062 commits 3 branches 2 tags 279 MiB
Elixir 97%
HTML 2.2%
CSS 0.4%
Shell 0.3%
Find a file
Oneric 2b885288fa ap: don't require explicit addressing of personal-inbox owners 
This requirement was originally added together with splicing the
inbox owner into the non b* addressing fields to make bcc transports
work in https://git.pleroma.social/pleroma/pleroma/-/merge_requests/390.
Later on this was relaxed to always allow deliveries devoid of any
addressing at all in f6cb963df2
and always allow deliveries from actors the owner is following in
750b369d04 to fix interop issues with
Mastodon and Honk respectively.

The justification for both the filtering and splicing comes from
one sentence in AP spec’s inbox section:
> In general, the owner of an inbox is likely
> to be able to access all of their inbox contents.

While this may provide plausible justification for splicing the owner
into cc, it is less clear how this requires or justifies the set of
filtering rules employed here.
Surveying a few other implementations no similar
filtering or splicing appears to be employed.

Furthermore, spec-compliant servers will strip bto/bcc _before_
delivery to remote servers, meaning any compliant bcc transport
out there will NOT contain any explicit addressing of the inbox owner.
Thus the addressing requirement directly opposes
the goal of the original patch.

Currently the requirement for the owner to be addressed once again
is causing interop issues. It turns out to be the root cause of
a long-standing (2+ years) bug preventing meaningful federation.
Bridgy sends e.g. Follow activities and Accepts for Follows directly
to the affected user’s personal inbox while solely addressing
the public scope in the to field. Notably follow relations never
getting established prevented the "accept if followed" allow rule
to ever come into effect.

To make matters worse non-addressed messages simply lead to a
vague "internal server error" response being sent back
which likely slowed down locating the issue.
Furthermore additional issues wrt to signatures cropped up after
the 500-response issues wa first reported, but they seem to have
already been fixed in the meantime, possibly with the signature
handling overhaul in Akkoma.

Given it repeatedly caused issues, does not appear to align with common
practice in the wider fedi ecosystem and apparently contradicts its
original intention, simply remove the requirement.

This is confirmed to fix bridgy interop.

The addressing splicing actually should also add the inbox owner to bto
or bcc instead of cc, but for now this is not changed and in practice
bto/bcc delivery appears to be basically unused anyway.
2025-06-07 20:27:58 +02:00
.gitea/issue_template Update '.gitea/issue_template/feat.yml' 2022-12-12 04:26:43 +00:00
.woodpecker drop back to 1.14/OTP25 2025-03-02 13:04:10 +00:00
benchmarks Benchmarks: fix user timeline and tags benchmarks 2021-12-12 17:35:02 +00:00
ci drop back to 1.14/OTP25 2025-03-02 13:04:10 +00:00
config federation/out: raise publisher retries by one 2025-05-18 14:24:08 +02:00
diagnostic-tools add diagnostic script 2024-06-10 15:10:47 +01:00
docker-resources Update docker compose commands to Compose V2 2023-06-18 01:37:40 -04:00
docs api/masto/instance: add short_description field 2025-05-15 20:41:55 +02:00
installation openbsd: update service file 2025-01-03 21:22:38 +01:00
lib ap: don't require explicit addressing of personal-inbox owners 2025-06-07 20:27:58 +02:00
priv instances: drop has_request_signatures 2025-06-07 20:27:58 +02:00
rel Disable busy waits in the default OTP vm.args configuration. 2024-02-17 13:21:56 +01:00
restarter fix_flaky_transfer_task_test.exs (#237) 2022-11-01 14:31:29 +00:00
scripts document prometheus 2022-12-16 10:24:36 +00:00
test ap: don't require explicit addressing of personal-inbox owners 2025-06-07 20:27:58 +02:00
uploads fix issues with the uploads directory 2019-04-28 06:43:00 +02:00
.credo.exs Move Consistency.FileLocation to ./test 2020-10-13 19:57:45 +02:00
.dockerignore Docker builds (#231) 2022-10-16 19:25:54 +00:00
.formatter.exs add a snapshot test for api prefixes 2025-02-23 16:51:48 +00:00
.gitattributes Don't treat js/css as binary in git anymore 2022-12-23 18:03:14 +00:00
.gitignore Add docker override file to docs and gitignore 2023-08-07 13:09:04 -04:00
.mailmap Add myself to .mailmap 2021-02-15 13:19:44 +03:00
AGPL-3 LICENSE → AGPL-3 2019-04-01 00:31:21 +02:00
CC-BY-4.0 Add a copy of CC-BY-4.0 to the repo 2020-09-06 11:38:38 +03:00
CC-BY-SA-4.0 CC-BY-SA-4.0: Add a copy of the CC-BY-SA-4.0 license 2019-04-01 00:30:21 +02:00
CHANGELOG.md changelog: add missing entries since 3.15.2 2025-05-09 23:43:08 +02:00
CODE_OF_CONDUCT.md add code of conduct (#129) 2022-08-03 10:55:11 +00:00
COPYING Remove reference to city.jpg in COPYING 2022-11-25 07:29:50 +00:00
docker-compose.yml Merge pull request 'Add docker override file to docs and gitignore' (#621) from norm/akkoma:docker-compose-override into develop 2024-04-12 18:50:25 +00:00
docker-entrypoint.sh Fix busywait on docker-entrypoint script 2024-08-20 19:29:11 -03:00
Dockerfile Bump builds to OTP26 2023-08-09 14:39:28 +01:00
FEDERATION.md Merge branch 'develop' of https://akkoma.dev/AkkomaGang/akkoma into use_fep-c16b_formatting_mfm_functions 2025-02-23 10:13:44 +01:00
mix.exs http_signatures: ensure mandatory headers are set 2025-06-07 20:27:58 +02:00
mix.lock http_signatures: ensure mandatory headers are set 2025-06-07 20:27:58 +02:00
README.md readme: drop mention of YunoHost package 2025-02-14 22:10:25 +01:00
SECURITY.md Update notes on security exploit handling 2024-03-04 17:50:19 +01:00
SIGNING_KEY.pub 2022.09 stable release chores (#206) 2022-09-10 14:44:17 +00:00

README.md

akkoma

a smallish microblogging platform, aka the cooler pleroma

English OK 日本語OK

About

This is a fork of Pleroma, which is a microblogging server software that can federate (= exchange messages with) other servers that support ActivityPub. What that means is that you can host a server for yourself or your friends and stay in control of your online identity, but still exchange messages with people on larger servers. Akkoma will federate with all servers that implement ActivityPub, like Friendica, GNU Social, Hubzilla, Mastodon, Misskey, Peertube, and Pixelfed.

Akkoma is written in Elixir and uses PostgreSQL for data storage.

For clients it supports the Mastodon client API with Pleroma extensions (see the API section on https://docs.akkoma.dev/stable/).

Differences with Pleroma

Akkoma is a faster-paced fork, it has a varied and potentially experimental feature set tailored specifically to the corner of the fediverse inhabited by the project creator and contributors.

This should not be considered a one-for-one match with pleroma; it is more opinionated in many ways, and has a smaller community (which is good or bad depending on your view)

For example, Akkoma has:

  • Custom Emoji reactions (compatible with misskey)
  • Misskey-flavoured markdown support
  • Elasticsearch and Meilisearch support for search
  • Mastodon frontend (Glitch-Soc and Fedibird flavours) support
  • Automatic post translation via DeepL or LibreTranslate
  • A multitude of heavy modifications to the Pleroma Frontend (Pleroma-FE)
  • The "bubble" concept, in which instance administrators can choose closely-related instances to make a "community of communities", so to say

And takes a more opinionated stance on issues like Domain blocks, which are enforced far more on Akkoma.

Take a look at the Changelog if you want a full list of recent changes, everything since 3.0 has been Akkoma.

Installation

OTP releases (Recommended)

If you are running Linux (glibc or musl) on x86, the recommended way to install Akkoma is by using OTP releases. OTP releases are as close as you can get to binary releases with Erlang/Elixir. The release is self-contained, and provides everything needed to boot it. The installation instructions are available here.

From Source

If your platform is not supported, or you just want to be able to edit the source code easily, you may install Akkoma from source.

Docker

Docker installation is supported via this setup

Compilation Troubleshooting

If you ever encounter compilation issues during the updating of Akkoma, you can try these commands and see if they fix things:

  • mix deps.clean --all
  • mix local.rebar
  • mix local.hex
  • rm -r _build

Documentation