0e4c201f8d
- Drop Expect-CT Expect-CT has been redundant since 2018 when Certificate Transparency became mandated and required for all CAs and browsers. This header is only implemented in Chrome and is now deprecated. HTTP header analysers do not check this anymore as this is enforced by default. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect-CT - Raise HSTS to 2 years and explicitly preload The longer age for HSTS, the better. Header analysers prefer 2 years over 1 year now as free TLS is very common using Let's Encrypt. For HSTS to be fully effective, you need to submit your root domain (domain.tld) to https://hstspreload.org. However, a requirement for this is the "preload" directive in Strict-Transport-Security. If you do not have "preload", it will reject your domain. - Drop X-Download-Options This is an IE8-era header when Adobe products used to use the IE engine for making outbound web requests to embed webpages in things like Adobe Acrobat (PDFs). Modern apps are using Microsoft Edge WebView2 or Chromium Embedded Framework. No modern browser checks or header analyser check for this. - Set base-uri to 'none' This is to specify the domain for relative links (`<base>` HTML tag). pleroma-fe does not use this and it's an incredibly niche tag. I use all of these myself on my instance by rewriting the headers with zero problems. No breakage observed. I have not compiled my Elixr changes, but I don't see why they'd break. Co-authored-by: r3g_5z <june@terezi.dev> Reviewed-on: AkkomaGang/akkoma#294 Co-authored-by: @r3g_5z@plem.sapphic.site <june@terezi.dev> Co-committed-by: @r3g_5z@plem.sapphic.site <june@terezi.dev> |
||
|---|---|---|
| benchmarks | ||
| ci | ||
| config | ||
| docker-resources | ||
| docs | ||
| installation | ||
| lib | ||
| priv | ||
| rel | ||
| restarter | ||
| test | ||
| uploads | ||
| .buildpacks | ||
| .credo.exs | ||
| .dockerignore | ||
| .formatter.exs | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| .woodpecker.yml | ||
| AGPL-3 | ||
| CC-BY-4.0 | ||
| CC-BY-SA-4.0 | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| COPYING | ||
| coveralls.json | ||
| docker-compose.yml | ||
| docker-entrypoint.sh | ||
| Dockerfile | ||
| elixir_buildpack.config | ||
| Makefile | ||
| mix.exs | ||
| mix.lock | ||
| Procfile | ||
| README.md | ||
| SECURITY.md | ||
| SIGNING_KEY.pub | ||
akkoma
a smallish microblogging platform, aka the cooler pleroma
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 --allmix local.rebarmix local.hexrm -r _build