PubHubs — julian

PubHubs Moderation update 2024-04-29

Mon, 29 Apr 2024 13:28:09 +0000

Completing This Phase

This is the last week of my funding on Moderator Tools for PubHubs. It has been a pleasure working with the PubHubs team. The time seems to go quickly.

Over the last few weeks I have been documenting everything about the Moderator Tools for PubHubs project on my dedicated web site, https://www.ph.trax.im/.

To summarise, these are the main work areas in this project, linking to their web site sections:

Civilised Discourse
- Researching best practices to inform the longer term design of PubHubs moderation facilities.
Disclosure of Identity Attributes
- Building a moderation tool specific to PubHubs' special features.
Draupnir for PubHubs
- Adapting the best existing moderation tool from the regular Matrix ecosystem (Draupnir), evaluating and extending it.

Looking Back

How Did it Go? This is my own perspective.

Draupnir for PubHubs (item 3) was the first task. At the beginning of the project, it seemed clear that a good way to start would be to integrate the best available Matrix moderation tool, Draupnir, into PubHubs. I made it work, but it turns out that at this time Draupnir is not a very good fit for PubHubs's needs. Read more in the Draupnir for PubHubs section.

Disclosure of Identity Attributes (item 2) was undertaken next. This is about implementing a particular moderation feature, related to PubHubs's special identity system (IRMA/Yivi). Each participant is identified initially by a pseudonym. A moderator may ask a participant to disclose an attribute of their real identity, such as their registered home town), and the participant may provide a cryptographic proof (attestation) of the requested attribute, using Yivi. We now have a working implementation of this feature in PubHubs. There is a description, with screen-shots, in the Disclosure of Identity Attributes section.

Civilised Discourse (item 1): We needed a higher level plan for how to address moderation needs in PubHubs. Research suggested that Discourse.org provides a good role model. The foundation of its successful pattern for civilised discourse is structured around the idea of “Trust Levels”, guiding each new user gradually through increasing power and responsibility, up to possibly becoming a community leader. The other key idea is that the best kind of moderation is more about giving positive signals guiding towards intended behaviour than it is about reacting to negative behaviours. We copy and adapt these ideas to PubHubs, suggesting how to build successive features around this concept. See the Civilised Discourse section.

Each of these areas could be built on further. The Matrix moderation tool Draupnir turned out not to be such a useful building block as I had first assumed. However, we should keep an eye on upcoming developments from it and related projects from the wider Matrix world. Disclosure of Identity Attributes, with some work on a few aspects of its user experience, could be considered a complete feature. The Civilised Discourse concept has potential to guide the development of moderation-related features, in such a way as to promote desired behaviours as well as limiting undesired behaviours of a hub's community members.

Looking Forward

Where Next?

This was a part-time assignment and the depth of exploration was limited. It would be satisfying to take this work further forward. I intend to stay in touch with PubHubs, at least as a volunteer. I might also submit another funding application. I would be glad to do further work on moderator tooling or perhaps in another area that would be useful to them.

PubHubs is a great example of the kind of project I want to support. Software for the public good, built on freedom-respecting foundations of open standard protocols and free (libre) open source software (as listed on the Open Source page).

Besides PubHubs I will be looking to work on other projects in the field, especially those based on Matrix which I see as having great potential as an open standard for many kinds of messaging. I am particularly interested in public-benefit and personal use cases, enabling organisations and individuals who want to take their private messaging away from the tech monopolies and into their own hands.

#PubHubs #matrix

Follow/Feedback/Contact: RSS feed · Fedi follow this blog: @julian@wrily.foad.me.uk · matrix me · Fedi follow me · email me · julian.foad.me.uk Donate: via Liberapay All posts © Julian Foad and licensed CC-BY-ND except quotes, translations, or where stated otherwise

POSSE: TWIM: Moderator Tools for PubHubs

Fri, 29 Mar 2024 19:30:00 +0000

This is my POSSE copy of the announcement posted in This Week in Matrix (TWIM) 2024-03-29.

This Week in Matrix 2024-03-29

Dept of Interesting Projects

Moderator Tools for PubHubs

JulianF announces

This week I have put up a web site documenting my work on Moderator Tools for PubHubs.

PubHubs is a Dutch research project to enable citizen-facing organisations to provide online group communications, value-aligned with their real-world presence. It uses matrix protocol, combined with an interesting and different user identity model involving pseudonyms and selective cryptographic disclosure of identity attributes such as “is over 18” or “is a member of organisation X”. Each hub is built around a non-federating Synapse server, with their own identity plugins and custom client.

I have been working on three aspects of introducing initial moderation tooling. Some of it crosses over with general matrix (this week's Pantalaimon role is a side product of the Draupnir part), while some is different (Attribute Disclosure), and the third part is general (research and planning for Civilised Discourse).

My funded stint is coming to an end and I am looking for ways to continue in any related area of work — please matrix me @julian:foad.me.uk!

#PubHubs #matrix #POSSE

POSSE: TWIM: Pantalaimon role for matrix-docker-ansible-deploy

Fri, 29 Mar 2024 19:00:00 +0000

This is my POSSE copy of the announcement posted in This Week in Matrix (TWIM) 2024-03-29.

This Week in Matrix 2024-03-29

Dept of Ops 🛠

matrix-docker-ansible-deploy (website)

Slavi announces

Thanks to Julian Foad, matrix-docker-ansible-deploy can now install the Pantalaimon E2EE aware proxy daemon for you. It's already possible to integrate it with Draupnir to allow it to work in E2EE rooms – see our Draupnir docs for details.

See our Setting up Pantalaimon documentation to get started.

#PubHubs #matrix #POSSE

PubHubs Moderation update 2024-03: A Web Site

Thu, 28 Mar 2024 18:43:57 +0000

I put up a web site with details of my PubHubs work:

https://www.ph.trax.im

Under Moderation, there are subsections for the main work areas of the project: Draupnir+Pantalaimon, Disclosure of Identity Attributes, and Civilised Discourse.

That last area is the one I am currently working on.

#PubHubs #matrix #awesomeFOSS

PubHubs Moderation update 2024-02-02

Fri, 02 Feb 2024 12:16:45 +0000

Related docs: Disclosure of Identity Attributes page on Moderator Tools for PubHubs web site.
PubHubs-moderation live demo: central.ph.s.trax.im/client
- TODO: instructions; basically you need Yivi app with dev mode enabled and two sets of demo credentials (one as moderator, one as recipient)
disclosure UI live prototype: on qx.trax.im

Disclosure Flow

A moderator asks someone to disclose an attribute of their real identity. The recipient provide the requested attribute, using Yivi to attach a cryptographic proof.

In the last update I introduced a demo of attribute disclosure. I have since completed the main TODO there, making the disclosure flow happen on the recipient's account. (In the first demo the moderator's role and the recipient's role both took place in the same login session in the same account.)

This week I have been thinking about how we will need to improve the user experience, or flow, of this disclosure request and response.

Writing the dialogue boxes and associated logic by hand was tedious and buggy. Rapid prototyping would be helpful. I decided it's time for me to learn a better way. Being new to UI design and fervently open-source principled, I searched for a FOSS solution and found Quant-UX.

Quant-UX

Quant-UX seems well suited for this task. Unlike the better known PenPot, an open source tool for detailed visual design, Quant-UX focuses on dropping UI components into place and wiring them together for a live testable UI design, with facilities for collecting feedback from user testing. While Quant-UX is a bit rough around the edges compared to a polished commercial product like Figma, having minor bugs, inconsistencies and so on, it is nevertheless powerful and usable enough. And on the positive side, I understand it can do things that Figma can't.

There is even a “low-code” sister project Luisa.cloud which promises to import a Quant-UX (or Figma) design into a real application and run it for real. I am interested to try that too, but that will have to wait.

I set about self-hosting Quant-UX to be sure of owning my own data. Now it is running on my Trax domain, at qx.trax.im. (You can try it, but be aware I'm providing it “as-is”, no guarantees at all, even if you create an account there (which I may or may not allow). Consider using the official site or hosting your own.)

Live Prototype: Disclosure Flow

I made a prototype, roughly representing the disclosure flow in the initial demo, and a wiki page about it with screen-shots and with links to the live prototype where you can click through and add comments to the screens.

View, interact with and comment on the prototype

Improvement Ideas

Some initial ideas about improvements to the flow:

The moderator could initiate the process by clicking an action button on a message from the intended recipient user in a hub room, or by clicking on the user's avatar or pseudonym in some list, and the relevant user would be pre-populated in the initial dialogue and not editable there.
The recipient user should receive a more gentle notification than suddenly seeing a pop-up dialogue of any kind. Perhaps a notification consistent with other notifications, though perhaps indicating a greater “urgency”, from which they can then access the full details of the request when they are ready.

I started adding some “comment” annotations on the UI prototype, mentioning some of these thoughts. You (dear reader) can do so too, either anonymously or after creating an account. (I have reported a bug whereby none of the existing comment annotations can be seen until you add a new comment, then they all appear.) If you add any comments there, please also contact me another way to let me know you're doing so, as I might not otherwise notice.

[EDIT 2024-04-23: add links to Related Docs]

#PubHubs #matrix #QuantUX #awesomeFOSS

PubHubs Moderation update 2024-01

Tue, 23 Jan 2024 20:21:07 +0000

This month I have been building a PubHubs-specific feature, the ability for a moderator to ask a someone to disclose an attribute of their real identity.

Related docs: Disclosure of Identity Attributes page on Moderator Tools for PubHubs web site.

When a person signs in to PubHubs hub through the Yivi verified credentials system, initially they are allocated a pseudonymous user identifier, for example @123-321:testhub.matrix.host. From this pseudonym, not even an operator or moderator of the hub can discover the user's real identity.

A moderator may wish to ask a user to confirm their real identity, to some degree. Through Yivi it is possible to ask a user to reveal a cryptographic proof [1] of one or more of their identity attributes. Some common attributes are one's real name, physical address, or email address. An attribute could also be something like “age is at least 18 years”.

First Demo Version

This demo may be seen and tested at https://testhub0.ph.s.trax.im (the hub-client alone) or https://central.ph.s.trax.im/client#/ (in the global-client). (This is a staging/testing deployment, not stable.)

In this demo version:

the moderator is concerned about a user (pseudonym 'bad-apple3'), and starts the disclosure request
moderator chooses: a user, a message, a set of attributes
on submitting the form, a private room with the recipient is created or opened, and a request message is sent into that room
a Yivi signing session is started (DEMO: this signing session runs on the moderator's side; it should run on the recipient's side)
the recipient uses Yivi to provide the requested attributes, with which Yivi signs a (pre-filled) reply message
the reply, signed with the requested attributes, is received by the moderator in the private room

TODO:

The Yivi signing session must be initiated on the recipient's client, not the moderator's. [DONE, 2024-01-30]

This version does not need or use Draupnir.

[1]: A proof that such an attribute has been attested by some mutually trusted authority.

[EDIT 2024-04-23: add links to Related Docs]

#PubHubs #matrix

PubHubs Moderation update 2023-12

Wed, 13 Dec 2023 13:39:33 +0000

Last week I began making this primitive Draupnir (moderation bot) UI, in my PubHubs work.

The “Moderation view” column on the left is my new bit. The right hand side is a regular matrix timeline, showing some interaction in the Draupnir bot's management room.

Draupnir is built to be operated by sending commands like !draupnir rooms in its management room, and reading its responses in the room timeline. That's a universal way of interacting with a bot, but it's not very friendly to a new moderator.

So we want some sort of UI that's more friendly.

This first attempt captures the various HTML response messages from the Draupnir status-getting commands. It shows the same displays as we can see in the timeline, only in a place where they don't scroll away and we can hide and reveal each one separately.

Updating this view is inefficient of course. When it sees any message from the Draupnir bot in the management room, it updates the corresponding view section (based on text substring matches, ugh). If you click the “refresh” button, it sends all the status-getting commands, so that the responses will (soon) come back and update the view.

Probably neither PubHubs nor Draupnir wants to continue it in this direction but anyway it's something where there was AFAIK nothing. Nevertheless, if anyone's interested, it's open-source.

I'm not sure what direction best to take the desire for a GUI. I'm going to take a break from that until a better plan emerges.

I think, more than the technical issues in getting such a view updated and displayed nicely, a bigger issue is it feels unfocused. Rather than a GUI that just has the ability to display all the possible info, it feels like we would want a GUI that focuses on specific scenarios, bringing together all the required info and control for, for example, managing a spam attack, or managing a user who violates CoC but has previously been in good standing.

I don't have the UI design skills nor motivation nor funding to go into a big UX design, although I'll enquire into it a bit.

What Next?

Now I'm going to build a PubHubs-specific feature, the ability to ask a user (who initially has a pseudonymous mxid) to reveal an attribute of their real identity, from the IRMA/Yivi verified credentials system, to the moderator. I don't yet know if or how much Draupnir might be involved in that.

#PubHubs #matrix

Deploying Pantalaimon on my Matrix Test Rig

Thu, 28 Sep 2023 11:46:25 +0000

Last week I was setting up Draupnir on my matrix test rig, in order to become familiar with Draupnir deployment before I integrate it with PubHubs.

Now I need to address end-to-end-encryption (E2EE). PubHubs exclusively uses encrypted matrix rooms, and Draupnir doesn't yet have E2EE functionality built-in. (Why is that? Moderation in public rooms is Draupnir's main use case, and for several reasons public matrix rooms are usually not encrypted. However PubHubs is different.)

There is a generic solution for adding E2EE to a matrix bot, and it's called Pantalaimon, an “E2EE aware proxy daemon for matrix clients.” So this week I'm setting up Pantalaimon.

The handy matrix-docker-ansible-deploy has no Pantalaimon role ... yet. I may be able to contribute one, but no promises. First I will make a stand-alone Pantalaimon setup role, in my quest to automate, with Ansible, as much as possible of the set-up.

Simple Ansible Role for Pantalaimon

I have made and published a simple Ansible role to run Pantalaimon. It consists of:

default variables, with (minimal) documentation
main, build, install tasks
a pantalaimon.conf template

I use the role in my playbook like this:

  - name: "pantalaimon"
    include_role: name=trax_im.matrix_ansible.pantalaimon
    vars:
      pantalaimon_docker_image: "{{ my_docker_registry_host }}/pantalaimon:latest"
      pantalaimon_docker_network: "{{ matrix_docker_network }}"
      pantalaimon_base_path: /srv/PubHubs/pantalaimon
      pantalaimon_log_level: Debug
      pantalaimon_homeserver_name: example
      pantalaimon_homeserver_url: "https://matrix.example.org"

My intention is to run Pantalaimon in a container, managed by Docker (alternatives like Podman should work similarly), on the target machine where the matrix server runs. Note that, in general, to minimise exposure of encrypted data, Pantalaimon should be run “close to” the bot or client that uses it. At least the unencrypted connection between the bot or client and Pantalaimon should be secured.

There is no Pantalaimon docker image published by its creators, so my role builds it, and pushes it to my private registry. (You could delegate the building to a different machine such as localhost; that's commented out in tasks/main.yml in v1.1.0. Or, building on the target machine, you could avoid using a registry if you set my_docker_registry_host to localhost, I think; you might need to disable the 'push' option in the build task as well.)

Connecting Draupnir to Pantalaimon

To connect Draupnir to Pantalaimon, I am going to show a playbook task that invokes the existing draupnir role. (Usually to set up a regular matrix system I run the 'matrix-docker-ansible-deploy' playbook as a whole. Invoking a role individually from another playbook is working towards using it with PubHubs rather than a regular matrix system.)

The key part here is to override the Draupnir config's homeserverUrl to point to Pantalaimon, while leaving the Draupnir config's rawHomeserverUrl pointing to the matrix server's public client-server API, as documented in Draupnir's example config.

  - name: "draupnir" 
    include_role: name=playbooks-from/matrix-docker-ansible-deploy/roles/custom/matrix-bot-draupnir 
    vars: 
      matrix_bot_draupnir_access_token: "{{ matrix_draupnir_bot_access_token }}"  # using value generated by login step earlier; alternatively read it from a vault-var
      matrix_bot_draupnir_management_room: "{{ matrix_draupnir_management_room_id }}"  # using value generated by room-creation step earlier; alternatively read it from an inventory var
      matrix_bot_draupnir_configuration_extension_yaml: | 
        homeserverUrl: "http://pantalaimon:8009" 
        pantalaimon: 
          use: true 
          username: "bot.draupnir-admin" 
          password: "{{ matrix_draupnir_bot_password }}"  # using an inventory vault-var
        protectAllJoinedRooms: true  # my preference
        commands: 
          allowNoPrefix: true  # my preference
      matrix_bot_draupnir_systemd_required_services_list: 
        - docker.service 
        - matrix-synapse.service 
        - matrix-pantalaimon.service

These vars would better be placed in the inventory than here. To use the role stand-alone like this we also need to set a few other base variables from matrix-docker-ansible-deploy, which we can do like this:

  vars_files:  # defined at the playbook level
    - playbooks-from/matrix-docker-ansible-deploy/roles/galaxy/com.devture.ansible.role.playbook_help/defaults/main.yml
    - playbooks-from/matrix-docker-ansible-deploy/roles/galaxy/com.devture.ansible.role.systemd_docker_base/defaults/main.yml
    - playbooks-from/matrix-docker-ansible-deploy/roles/custom/matrix-base/defaults/main.yml

  vars:  # defined at the task or block level
    matrix_user_uid: 991  # to match our existing matrix installation
    matrix_user_gid: 991
    matrix_homeserver_url: "https://matrix.example"

We have looked at a simple stand-alone Pantalaimon role. Now to integrate it in matrix-docker-ansible-deploy.

M-D-A-D Playbook Role for Pantalaimon

The first draft of a suitable role is published on TraxLab: roles/matrix_pantalaimon.

[2023-10-19] I prepared a merge request to the m-d-a-d playbook:

Pantalaimon role is activated by matrix_pantalaimon_enabled and connects to the homeserver by default. No further config is needed. Integration with Draupnir is included, activated by matrix_bot_draupnir_use_pantalaimon. No integration with Mjolnir or anything else. Alternatively Pantalaimon can be configured alone, and then whatever component is meant to talk to it, in or out of the playbook, may be configured separately/manually.

... and Slavi has responded to me with a bunch of good review comments which I need to address.

UPDATE 2023-12-21: Addressed those review comments.

UPDATE 2024-03-29: This is now accepted and included in matrix-docker-ansible-deploy.

#matrix #awesomeFOSS #Draupnir #PubHubs

Deploying Draupnir on my Matrix Test Rig

Wed, 20 Sep 2023 17:00:00 +0000

This week I'm setting up Draupnir on my matrix test rig, in order to become familiar with Draupnir deployment before I integrate it with PubHubs.

Very glad to be able to use matrix-docker-ansible-deploy's Draupnir setup to automate the majority of the Draupnir deployment.

I also want to automate, with Ansible, as much as possible of the set-up that is required before running that playbook. I aim to document here what I have done and open questions about it. The numbered steps here correspond to the manual instructions in that documentation linked above.

1. Register the bot account

I register a matrix account for the bot, using a little Ansible role I wrote, calling it like this in my Ansible playbook (personal one, specific to this installation).

  - include_role: name=matrix-synapse-register-user
    vars:
      matrix_synapse_user:
        name:  "{{ matrix_draupnir_bot_username }}"
        pw:    "{{ matrix_draupnir_bot_password }}"
        admin: "{{ matrix_draupnir_bot_admin }}"

defining those vars in my inventory file inventories/prod/host_vars//matrix-draupnir.yml:

matrix_draupnir_bot_username: "bot.draupnir"
matrix_draupnir_bot_password: !vault [... I use vault encoded values here ...]
matrix_draupnir_bot_admin: false

I published my matrix-synapse-register-user role. I thought I should, if there isn't already a more widely available alternative. It looks like this, in tasks/main.yml:

---
- name: "register a matrix synapse user"
  command:
    argv: "{{ (cmd_check if ansible_check_mode else cmd_real) + args }}"
  vars:
    cmd_real:
      - /matrix/synapse/bin/register-user
    cmd_check:
      - echo
      - "Would run: /matrix/synapse/bin/register-user"
    args:
      - "{{ matrix_synapse_user.name }}"
      - "{{ matrix_synapse_user.pw }}"
      - "{{ '1' if matrix_synapse_user.admin|default(false) else '0' }}"
  check_mode: false
  register: result
  changed_when: result.rc == 0
  failed_when: result.rc != 0 and 'User ID already taken.' not in result.stdout
  # if already registered, errors with (on stdout):
  # > Sending registration request...
  # > ERROR! Received 400 Bad Request
  # > User ID already taken.

2. Get an access token

Manually get an access token. OK I know how to do that. First question, though: as that's a speed bump in the road, and seems fragile, has anyone shown interest in making either Draupnir itself or the playbook do a login automatically? Can't see any issue filed about “token” or “login”.

Basically these days I know I'm going to have to repeat my steps on a different rig later, tear things down and build them up again, so I always look to automate the whole procedure. (Aware it's sometimes more efficient to go manually at first and automate only when worth the effort. And aware I'm at risk of volunteering myself to contribute.)

Well, I asked about this. The kind folks let me know their thoughts. There are several issues.

When I said “fragile” I meant I wouldn't expect an access token to remain valid forever. At the time this was designed, access tokens were considered permanent until explicitly revoked (“logged out”). Putting an access token into a bot's config was taken for granted, and perhaps still is. However, nowadays the client authentication spec is more complex and tokens may need refreshing. That seems to me to suggest that's no longer good practice. It can still work if we take care that the token is not invalidated.

In one sense using an access token is considered more secure than knowing an account's password. That's the sense in which many systems allow getting an API access token and giving it to an external service that will call the API. However, I think this argument applies to accessing other accounts, not for the bot's own account.

Also, if Draupnir connects through Pantalaimon to get E2EE (as makes sense when it's being run by someone other than the server operator), then Pantalaimon needs the account password to create an E2EE device.

Currently I'm feeling the bot should know its password and we should automate its login. As a lesser step, I will do this in Ansible.

  - include_role: name=matrix-login-password
    vars:
      matrix_login:
        hs_cs_api: "{{ matrix_draupnir_hs_cs_api }}"
        user: "{{ matrix_draupnir_bot_user_id }}"
        password: "{{ matrix_draupnir_bot_password }}"
    # output: matrix_login_result
  - set_fact:
      matrix_draupnir_bot_access_token: "{{ matrix_login_result.access_token }}"

with additional inventory vars:

matrix_draupnir_hs_cs_api: "https://matrix.example.net"
matrix_draupnir_bot_user_id: "@bot.draupnir:example.net"

My matrix-login-password role has this in its tasks/main.yml:

- name: "log in to matrix"
  uri:
    method: POST
    url: "{{ matrix_login.hs_cs_api }}/_matrix/client/r0/login"
    body:
      type: "m.login.password"
      identifier:
        type: "m.id.user"
        user: "{{ matrix_login.user }}"
      password: "{{ matrix_login.password }}"
    body_format: json
  register: _result
  changed_when: _result.json.access_token

- set_fact:
    matrix_login_result: "{{ _result.json }}"
  when: not ansible_check_mode

# matrix_login_result contains at least: access_token, device_id, user_id
# see e.g.: https://spec.matrix.org/v1.8/client-server-api/#login and older versions

[Update: now published too.] (I hesitated because I thought I saw about a year ago someone had already published a set of ansible roles for matrix admin tasks like this. Maybe. Can't find it now.)

3. Make sure the account is free from rate limiting

Same for this 'override_ratelimit' step of course. Would be nice to automate.

One way to change this permission is through some other admin account. In that case, “know an access token” is an appropriate way to use that other admin account.

In the case where the bot account itself is configured to be a (matrix) server admin account, then in Synapse's case at least it would already have sufficient permission to use Synapse's admin API to override its own rate limit.

Now about admin APIs. Unfortunately matrix admin APIs are not standardised. Synapse has its admin API, Dendrite has another, and Conduit I gather doesn't have a REST admin API. On Dendrite, “the username has to be specified in dendrite.yaml to disable rate limiting, and personally i hate when anything other than the sysadmins write to configs” said bones_was_here. The playbook, if instructed to install Dendrite, controls that config file, but Draupnir would (or should) not be able to do that by itself unlike with Synapse.

So, there are lots of cases. Different homeservers, and the playbook being used to install Draupnir with or without also its homeserver, and choice of whether the playbook or Draupnir itself performs this configuration.

Currently I'm think I will automate it for the Synapse admin set-ratelimit API only, as that's the server we use in PubHubs.

  - name: "disable rate limiting for Draupnir bot"
    uri:
      method: POST
      url: "{{ matrix_draupnir_hs_cs_api }}/_synapse/admin/v1/users/{{ matrix_draupnir_bot_user_id }}/override_ratelimit"
      headers:
        # access token must be for a user with synapse admin access;
        # can be the bot's if it is an admin, else of another account.
        Authorization: "Bearer {{ matrix_draupnir_bot_access_token if matrix_draupnir_bot_admin else matrix_draupnir_some_synapse_admin_account_access_token }}"
      body_format: json
      body:
        messages_per_second: 0
        burst_count: 0

4. Create a management room

I'm on a roll now. I'll just check the matrix spec for room creation, take a guess at which parameters make most sense for my case, and write it out in Ansible language.

  - name: "create a management room for Draupnir bot" 
    uri: 
      method: POST 
      url: "{{ matrix_draupnir_hs_cs_api }}/_matrix/client/v3/createRoom" 
      headers: 
        Authorization: "Bearer {{ matrix_draupnir_bot_access_token }}" 
      body: 
        name: "{{ matrix_draupnir_management_room_name }}" 
        creation_content: 
          m.federate: false 
        visibility: private 
        preset: trusted_private_chat 
        invite: "{{ matrix_draupnir_operator_user_ids }}" 
      body_format: json 
    register: _result 
    when: matrix_draupnir_management_room_id is undefined 
    # output: _result.json.room_id 
  - set_fact: 
      matrix_draupnir_management_room_id: "{{ _result.json.room_id }}" 
    when: matrix_draupnir_management_room_id is undefined

with inventory vars:

# the management room (bot and its operators); create if room_id undefined
matrix_draupnir_management_room_name: "Draupnir management"
matrix_draupnir_management_room_id: '!xxxxxxxxxxxx:example.net'

Starting Up

After running my playbook with the above set-up, and pasting the resulting access token and room id into the corresponding inventory vars (TODO: join the two parts together in a better way than cut-n-paste), here we go with matrix-docker-ansible-deploy:

ansible-playbook .../matrix-docker-ansible-deploy/setup.yml -l example.net --tags=setup-bot-draupnir,start -Dv

In the logs, journalctl -n100 -fu matrix-bot-draupnir.service:

Starting Matrix Draupnir bot...
Started Matrix Draupnir bot.
[INFO] [index] Starting bot...
[INFO] [index] Resolving management room...
[INFO] [index] Mjolnir is starting up. Use !mjolnir to query status.
[INFO] [ProtectedRoomsConfig] Resolving protected rooms...
[WARN] [ProtectedRoomsConfig] Couldn't find any explicitly protected rooms from Mjolnir's account data, assuming first start. MatrixError: Error during MatrixClient request GET /_matrix/client/v3/user/%40bot.draupnir%3Aexample.net/account_data/org.matrix.mjolnir.protected_rooms: 404 Not Found -- {"errcode":"M_NOT_FOUND","error":"Account data not found"}
[... three of these 'Account data not found' errors ...]
[INFO] [Mjolnir@startup] Checking permissions...
[INFO] [Mjolnir@startup] Syncing lists...
[INFO] [Mjolnir@startup] Startup complete. Now monitoring rooms.

And then I found and joined the management room. I used a Hydrogen web client.

_@bot.draupnir:example.net joined the room_
_bot.draupnir named the room "Draupnir management"_
_admin1 was invited to the room by bot.draupnir_

**bot.draupnir:**
Mjolnir is starting up. Use !mjolnir to query status.
Checking permissions...
All permissions look OK.
Syncing lists...
Done updating rooms - no errors
Startup complete. Now monitoring rooms.

_admin1 joined the room_

It's alive! Perhaps a little confused about its new name. Responds to both !mjolnir and !draupnir, either way replying:

Old Commands:
`!mjolnir        - Print status information`
`!mjolnir status - Print status information`
[...]

mjolnir commands:`ban   [...reason]` - Bans an entity from the policy list.Parameters:
entity - no description
list - no description
[...]

Well, there we are. The bot's alive. Next it's time for me to learn its commands and put it to work.

Update: All these Ansible roles are now published. TODO: contribute some of this to matrix-docker-ansible-deploy? TODO: re-implement these roles as Ansible modules instead, using a matrix python API such as synadm or mautrix-python?

#matrix #awesomeFOSS #Draupnir #PubHubs

2023-09-18 Update: PubHubs Moderation Tools

Mon, 18 Sep 2023 19:19:52 +0000

Last week

I officially received confirmation of funding. (Thank you, PubHubs team and Dutch government open-source funding team.)
I re-joined the project team after a summer break, having previously joined them as a volunteer, and joined a general meeting and a technical meeting.
I posted a short announcement/introduction on my blog.
I updated and re-started my own test-bed installation of Pubhubs components.
I made some progress on my Ansible installation scripting of Pubhubs components.
I joined the new pubhubs-hosted project discussion room, in a “stable test hub”, which we would like to use instead of Slack, both for reasons of living our values and to “eat our own dog food”.
In our pubhubs dev room, we discussed implementing email notifications using Synapse's built-in support, which would be very useful for us maintining a long-term conversation in the room; and we discussed briefly some privacy implications if we wanted to offer follow-up notifications by email, or in other ways, to users who would like to remain pseudonymous.

This Week

Get some part of my Ansible deployment tested and published?
Start self-hosting Draupnir (on a normal matrix server) to get experience of deploying and using it.

Tech note: Dependency Updates

Updates needed, since around June/July.

dependencies: NodeJS and NPM: update to later than Node 12 (which was installed via Debian 11 packages). I now install via Ansible role geerlingguy.nodejs, which in turn uses the nodesource.com APT repo, and currently defaults to Node 16.
dependencies: add package libssl-dev, required by Cargo openssl-sys package dependency (error was failed to run custom build command for openssl-sys v0.9.60).

#PubHubs #matrix