DOCSEARCHbyAlgolia
Submit Docs

Draupnir Documentation

website·Indexed 29 days ago

https://the-draupnir-project.github.io/draupnir-documentation

Open community management infrastructure for Matrix, providing tools for room protection, spam detection, and user policy management. Includes API references for event spam checking and user join permissions, as well as documentation for the Matrix Protection Suite and Draupnir v3.0.0.

Tokens
22.1K
Snippets
78
Records
194
Agent score
75%

What's inside Draupnir

  2. Overview of the Draupnir planning and design system

    Draupnir uses a layered system to organize work, separating strategic design from tactical planning. The system is structured as follows: Problem → Bet → Solution → Increment → Task.

    Design Tier (Strategic context):

    • Problems: High-level context of systemic issues or feature requests.
    • Solutions: Exploration and design space for solving a problem.

    Planning Tier (Execution):

    • Bets: High-level abstract plans to explore a solution, wagered against potential value and maximum resource commitment.
    • Increments: Concrete plans defined by deliverables to be completed within a 'longhouse cycle'. These are materialized shortly before the cycle to prevent 'planning decay'.
    • Tasks: Focused, detailed plans for specific units of work.

  3. Overview of Room Discovery protection

    The Room Discovery protection matches policies from Draupnir's watched lists against rooms joined by the homeserver. It is specifically designed for servers with open registration to handle two scenarios: automatically rejecting existing spam invitations and preventing local users from joining or remaining in rooms containing intolerable or illegal content. If a room is marked with a takedown recommendation, the protection instructs the homeserver to shut down the room, forcing all local participants to leave, purging history from the database, and blocking the room. This protection requires Draupnir v2.3.0 or above. As of v2.4.1, it no longer depends on synapse-http-antispam, though installing that module is still recommended to block invitations preemptively.

  4. Overview of Draupnir homeserver protections

    Draupnir provides a suite of protections for Matrix homeserver administrators, which are especially critical for servers with open or public registration. These protections help prevent abuse from malicious actors and protect resident users from unsolicited abuse or harmful content (such as CSAM). To function, these features may require Draupnir to have a Synapse admin account or the synapse-http-antispam module.

  5. Overview of Draupnir community management goals

    Draupnir is a community management service designed for Matrix communities with public rooms. Its primary goals are to:

    • Maintain moderation decisions via policy rules.
    • Inform users of the community's code of conduct.
    • Manage access control and on-board new users to prevent conversation disruption.
    • Facilitate distributed, 24/7 moderation by monitoring curated policy rooms.
    • Automatically protect new spaces on a homeserver upon creation, including any rooms subsequently added to that space.

  6. Understand Matrix power levels and standard roles

    Matrix uses a power level system instead of traditional roles to manage permissions. A power level is a numeric value (typically 0 to 100). A user can exercise a specific permission if their power level is equal to or greater than the power level required for that permission.

    By default, the following standard roles are defined:

    • User (Power Level 0): Can send messages, media, reactions, and redact their own messages.
    • Moderator (Power Level 50): Includes User permissions, plus the ability to change room name/address/topic, remove users (kick/ban), redact others' messages, and use @room notifications.
    • Administrator (Power Level 100): Includes Moderator permissions, plus the ability to change history visibility, enable encryption, remove entire servers from the room, and promote other users to Moderator or Administrator.

  7. Install and configure synapse-http-antispam for Synapse

    The synapse-http-antispam module allows Draupnir to make decisions about events received by a Synapse homeserver, replacing the legacy Mjolnir antispam module. This requires Draupnir v2.3.0 or above. If using matrix-docker-ansible-deploy, refer to the playbook documentation; otherwise, follow the module's README.

  8. Create a Bet to manage high-level objectives

    Bets are provisional hypotheses about high-level objectives. They encapsulate the value of pursuing a goal and the maximum cost the project is willing to risk before the effort is considered a failure, preventing sunk-cost fallacy.

    Key Components of a Bet:

    • Present Value: The expected gain if the bet succeeds. This includes erased user pain, opportunistic value, learning value from problem exploration, and compound value toward other goals.
    • Wager: The maximum amount of contributor time the project is willing to commit before moving on. This is a limit on loss, not a cost estimate.
    • Commitment: An explanation of the objective, the problems being addressed, and relevant context.
    • Other Risks: Factors that could fail the bet regardless of the wager (e.g., a failed MSC or a competing third-party solution).
    • Deliverable Meaningful Results: Abstract outcomes used to demonstrate success to stakeholders (e.g., feature releases, documentation, or research) without prescribing implementation details.

  9. Understand Draupnir's state management and synchronization loop

    Draupnir uses the matrix-bot-sdk for its client library. Because the /sync response's timeline provides events in the order they are received by the server rather than their mainline order in the DAG, Draupnir cannot rely on /sync alone for an accurate representation of room state. To ensure consistency, Draupnir re-requests the entire state of a policy list every time it receives a state event in that list. This prevents the bot from acting on stale events resulting from DAG forks that have converged.

  10. Understand Draupnir's approach to task estimation

    Draupnir does not use story pointing to avoid inaccuracies associated with large stories and the bias introduced by Goodhart's Law (where the measure becomes the target). Instead, the project uses Tasks as the fundamental unit of work. Because tasks are grounded in the specific implementation and broken down into small, workable units, they are treated as being of a consistent size, removing the need for traditional estimation.

  11. Understand the role of the Root Contributor Circle in Draupnir

    The Root Contributor Circle holds the primary responsibility for all functions of the Draupnir project. Members are deeply trusted individuals committed to the project's vision and are responsible for ensuring the project's continuity during crises. Current members include Gnuxie, Cat, Nex, and Sky.