Gnuxie a1cc936995
Tests / Build & Lint (push) Canceled after 0s
Tests / Unit tests (push) Canceled after 0s
Tests / Integration tests (push) Canceled after 0s
Tests / Application Service Integration tests (push) Canceled after 0s
Ci in a Box / Build & Lint / Node 24 / alpine / amd64 (push) Canceled after 0s
Ci in a Box / Build & Lint / Node 24 / slim / amd64 (push) Canceled after 0s
Ci in a Box / Build & Lint / Node 26 / alpine / amd64 (push) Canceled after 0s
Ci in a Box / Build & Lint / Node 24 / alpine / arm64 (push) Canceled after 0s
Ci in a Box / Build & Lint / Node 24 / slim / arm64 (push) Canceled after 0s
Ci in a Box / Unit tests / Node 24 / alpine / amd64 (push) Canceled after 0s
Ci in a Box / Unit tests / Node 24 / slim / amd64 (push) Canceled after 0s
Ci in a Box / Unit tests / Node 26 / alpine / amd64 (push) Canceled after 0s
Ci in a Box / Unit tests / Node 24 / alpine / arm64 (push) Canceled after 0s
Ci in a Box / Unit tests / Node 24 / slim / arm64 (push) Canceled after 0s
Ci in a Box / Integration tests / Node 24 / alpine / amd64 (push) Canceled after 0s
Ci in a Box / Integration tests / Node 24 / slim / amd64 (push) Canceled after 0s
Ci in a Box / Integration tests / Node 26 / alpine / amd64 (push) Canceled after 0s
Ci in a Box / Integration tests / Node 24 / alpine / arm64 (push) Canceled after 0s
Ci in a Box / Integration tests / Node 24 / slim / arm64 (push) Canceled after 0s
Ci in a Box / Application Service Integration tests / Node 24 / alpine / amd64 (push) Canceled after 0s
Ci in a Box / Application Service Integration tests / Node 24 / slim / amd64 (push) Canceled after 0s
Ci in a Box / Application Service Integration tests / Node 26 / alpine / amd64 (push) Canceled after 0s
Ci in a Box / Application Service Integration tests / Node 24 / alpine / arm64 (push) Canceled after 0s
Ci in a Box / Application Service Integration tests / Node 24 / slim / arm64 (push) Canceled after 0s
Validate Docker Build / validate-docker-build (push) Canceled after 0s
Docker Hub - Develop / docker-latest (push) Canceled after 0s
GHCR - Development Branches / ghcr-publish (push) Canceled after 0s
Seperate Projection into distinct reader / writer sides and add description for Projection partitions (#1183)
* Split the Projection interface into distinct reader / writer sides.

https://github.com/the-draupnir-project/planning/issues/150

* Add ProjectionDescription and make it hold the shape.

https://github.com/the-draupnir-project/planning/issues/152

* Expand ignore pattern for unused vars

Type paraemters weren't included mew

* Add a builder for protection descriptions.

https://github.com/the-draupnir-project/planning/issues/152

* WIP: begin using projection locator

* Rename ProjectionLocator to ProjectionAllocator and wire in.

The reason why we can't have an orchestrator own the projects yet is
simply because currently the projections are created from _protected
rooms set_ specific revision issuers that are disposed alongside
it. And of course if we were naive and implemented the global
orchestrator, we'd be tied to a stale protected rooms set if a
Draupnir was restarted via safe mode or whatever.

* Remove the projection allocator.

The problem with it is that we would be tunneling through the dataflow
from source to sink, not from sink to source. But the allocator is
designed for sink to source. Which is an issue because the ownership
semantics from source to sink are the desired ones (the orchestrator
owns the projections and is a global thing that caches them). But from
sink to source, ownership is adhoc and they can't be cached at all
because context is needed from the non-ported parts of the upstream
data pipeline. Which tbh are effectively non deterministic sources
as far as the orchestrator engine is concerned.

Additionally, using the projections or projection nodes from code
outside of the reducer pipeline will always require allocation of a
live handle. This is because of a few reaons:

1. GCing old projection nodes that are lazy loaded requires there are
   no live handles.

2. Managing cache of projection nodes (including via a Projection) on
   workers requires knowing if they are being accessed.

I don't think there are other reasons. So this really is the API to
get right. And i don't think it's easy while projections are muddled
with context.
2026-09-16 12:28:14 +00:00
2026-09-09 16:26:24 +00:00
2026-09-09 16:26:24 +00:00
2024-10-08 16:43:52 +03:00
2026-03-19 16:13:14 +00:00
2026-03-19 16:13:14 +00:00
2024-07-25 10:58:40 +01:00
2026-09-09 16:53:56 +00:00
2026-03-19 16:13:14 +00:00
2026-05-07 14:01:00 +01:00
2026-09-09 16:26:24 +00:00
2026-09-09 16:26:24 +00:00
2026-03-19 16:13:14 +00:00
2024-07-25 10:58:40 +01:00
2026-09-09 16:26:24 +00:00
2026-09-09 16:53:56 +00:00

Draupnir

Draupnir is a unified platform to grow, manage, and sustain communities on Matrix.

Why communities choose Draupnir

  • Draupnir provides Unified control to manage your Matrix community from one place.
  • Draupnir has Open governance and transparent project leadership grounded in grassroots community focus.
  • Draupnir is Extensible, dynamically reconfigure protections and plugins for your circumstances or needs.
  • Draupnir utilizes Distributed moderation: Subscribe to trusted, community-curated policy lists that keep spaces safe around the clock.

Status

We have recently passed a huge milestone: Draupnir's 3.0.0 release 🎉

See governance reports for the current project focus.

Draupnir is supported by NLnet through the NGI Zero Core programme. The goals of this work are described here.

Draupnir also accepts community support through Open Collective, hosted by Open Source Collective. Contributions help sustain development, maintenance, and contributor expenses with public budget transparency.

Quick start

See Setting up Draupnir.

Visit #draupnir:matrix.org in your client and come say hi.

Core Features

  • Draupnir's UX is centred around intuitive interactive prompts, with no need to type out commands for most activities. Just use your client to invite the bot to rooms, or manage community members, and Draupnir will prompt you to complete your changes.

  • Draupnir can protect your community by applying policies from community curated policy lists. For example lists such as the the community moderation effort can be watched to protect your rooms around the clock. This means that adjacent Matrix communities can warn and protect each other of known threats. Draupnir and the list provided by the community moderation effort are the bread and butter essentials of moderating public spaces on Matrix.

  • Draupnir includes advanced homeserver administrative features, such as automatically suspending user accounts, blocking invitations, and taking down rooms. As well as reviewing abuse reports. This also includes protecting your homeserver with Draupnir's watched policy rooms.

  • Draupnir can be used standalone to protect a community without a homeserver.

  • Draupnir includes a series of protections that can be enabled that can help you in given scenarios when your community is being targeted.

  • Draupnir is a forwards and backwards compatible drop in replacement for Mjolnir.

Prompt UX

It is no longer necessary to use commands for most core functions. Banning a user in a protected room from your Matrix client will cause Draupnir to show a prompt in the management room, which will offer to add the ban to a policy list1 .

A demo showing a propagation prompt

You can also unban users the same way, and Draupnir will prompt you to unban them without any confusing hiccups. If you do still wish to use the ban command, please note that users and other entities that are being banned are now the first argument to the ban command. It is now also possible to provide only the entity to Draupnir and have Draupnir prompt you for the policy list and the ban reason.

A demo showing the ban command

In general, all commands have been migrated to a new interface which feature better error messages for common problems and allow admins to trace the cause of unexpected errors much more easily.

Technical differences from Mjolnir and other moderation bots

I offer you the ring, which was burned, laid upon the pyre of Baldr by Odin.

Draupnir began as a fork of Mjolnir, in order to break a feature freeze and improve the architecture.

Draupnir remains a forwards and backwards compatible drop in replacement for Mjolnir that provides significant technical improvements:

  • Draupnir is much less dependant on commands and will automatically send prompts to the management room. Prompts are sent for inviting Draupnir to protect rooms, watch policy lists, ban users, and unban users.

  • Draupnir is much more responsive. Unlike Mjolnir and other bots, Draupnir does not need to request any data from the homeserver before applying new bans or to ban new users.

  • Draupnir uses an advanced persistent revision system for room state, members, policies, and policy matches. By using revisions, Draupnir only has to process room state once in terms of simple deltas as room state is updated.

  • Draupnir offers a room state backing store, allowing Draupnir to startup quickly, even when deployed at distance from the homeserver.

  • Draupnir's core functionality is implemented as protections, which can be configured and dynamically turned on and off. If you can write even a little JS/TS, Draupnir's behaviour can be radically changed or customized. And because the core functionality is implemented with the extension system, there are less limits.

  • A huge effort has been spent refactoring the code base, paving the way for future feature development of Draupnir and adjacent projects. This includes the rewrite of the core of Draupnir into the matrix-protection-suite, providing all the Matrix client code required to operate a protection platform. The matrix-protection-suite also covers severall shortfalls in the available SDK's, providing event parsing and types that keep code secure and sound. The interface-manager providing an advanced command-oriented interface (note, this does not mean command-line interface). The matrix-basic-types library for dealing with Matrix's various string types. And finally the introduction of prettier, eslint and typescript-eslint into Draupnir's development tooling, modernising TypeScript development.

Migration

Migrating from Mjolnir is straightforward and requires no manual steps, migration for your setup is likely as simple as changing your server config to pull the latest Draupnir docker image gnuxie/draupnir:latest instead of a mjolnir one. Draupnir remains backwards compatible so that it is possible to try Draupnir and still have the option to switch back to Mjolnir.

Any problems with migration should be reported to our support room.

Setting up

See the setup documentation for first-time setup documentation.

See the configuration sample with documentation for detailed information about Draupnir's configuration.

See homeserver administration for how to use Draupnir's features to protect your homeserver and users.

After your bot is up and running, you'll want to run a couple commands to get everything set up:

  1. !draupnir list create my-coc code-of-conduct-ban-list - This will create a new ban list with the shortcode my-coc and an alias of #code-of-conduct-ban-list:example.org. You will be invited to the room it creates automatically where you can change settings such as the visibility of the room.
  2. Review the Moderator's Guide.
  3. Review !draupnir help to see what else the bot can do.

Legacy documentation (v1.87.0 and below)

For information about the legacy version of Draupnir, see v1.87.0, the documentation for which can be found here.

Contributing & Opening Issues

Please see or contributing document, but do not worry too much about following the guidance to the letter. And keep that in mind throughout.

Supported by

NLnet

This project is funded through NGI Zero Core, a fund established by NLnet with financial support from the European Commission's Next Generation Internet program. Learn more at the NLnet project page.

NLnet foundation logo NGI Zero Logo

You can find details of the work that is being supported from NLnet here and the goals here.


  1. Yes, i know they don't align horizontally, you are welcome to suggest how this should be fixed. ↩︎

S
Description
No description provided
Readme
41 MiB
Languages
TypeScript 99.3%
JavaScript 0.6%