owned this note   changed 4 years ago  
Published Linked with GitHub

Matrix Bridge

tags: matrix & irc

Overview

Thoughts around how to implement Matrix for the Ansible community

Lots of good ideas in this doc from OpenStack

use-cases / personas

  1. As a community team, we want to be as inclusive as possible, and be able to reach & connect to Ansible users wherever they are. Matrix is designed for this, permitting bridges to IRC, Slack, Discord and more (http://matrix.org/bridges)
  2. As a new user, it needs to be easy to get help. Clicking a link on our community docs ("Chat with us!") which opens Element-Web in a new tab, using (optional) social-sign-up via the usual providers, and landing in Ansible-Community within a few seconds is both user friendly and what people expect from a modern chat platform.
  3. For existing users, IRC needs to be viable - again, bridges are the key, but also the wealth of Matrix clients to fit a power user's requirements.

As per the OpenStack doc, there are also side benefits such as:

  • End to end encryption in any purely-Matrix rooms (mostly 1:1 chats)
  • Option to have our own homeserver (Matrix is federated so we are not dependant on matrix.org)
  • New users get persistence without needing a bouncer
  • No barrier to entry dealing with Nickserv
  • Potential for more complex things like running our conferences there
  • REST API makes writing bots for almost anything pretty easy

proposals

Propose to make Matrix the default community discussion place - this is an important statement as it implies the additional features provided by Matrix are welcome, and we are not just participating in an IRC room via a fancy client.

To achieve this, we have options:

  • Stick with Matrix.org
    • Probably the worst option. Matrix.org is overloaded and is often down. We lose the benefit of federation and we aren't supporting them either.
  • Host our own homeserver
    • Easy way to support Element and Matrix. EMS will do hosting, and it gives us some leverage if we want custom features or temporary changes.
  • Share infra with Fedora
    • Fedora are moving to Matrix, and will have their own infra. We could ask to share, and combine budget.
    • Less for us to manage, but no vanity matrix.ansible.com URLs :)

limitations

Right now, there's a couple of problems

  • The Libera bridge won't activate on a room with more than 100 new-to-Matrix users in it. This is so that the bridge doesn't suddenly have to generate a ton of new users.
    • We currently have far more than this in some rooms
    • This only applies if the users aren't in any other Libera/Matrix bridge room. If we add our smaller rooms first, we may be able to avoid it
    • Alternatively we can ask for an exemption (probably easier if we're paying)
    • Or we can kick everyone from a given IRC room temporarily. Not likely to go down well.

Stats

  • #ansible on Freenode had around ~1,600 people
  • Monitor number of users and active in IRC

Questions

notes

  • Consider ansiblenetwork.slack
  • Meeting bot
    • Matrix bots are fairly easy
    • There is matrix-rust-sdk being worked on
    • There will be a python wrapper around it using pyo3 (no ETA for that though)
  • Gwmngilfen to ask Fedora about their plans
  • Gwmngilfen to raise hosting queries with EMS
  • Top level GitHub issue for libera.chat & Matrix #613
  • Meeting meeting thoughts
    • What learnings from other communities?
    • Homeservers
      • What does it mean to have a room ID on matrix.org or our own?
      • Are we then insulated from matrix.org outages? yes
      • Can we migrate rooms?
      • Bridges - can we use libera bridge directly?
        • IRC bridge features - editing and line-length - deployed?
        • Slack bridge
        • Discord bridge
        • gitter intergration - we have a room already
      • conferencing / jitsi hosting / recording
  • Slack
    • Slack & IRC double-bridging? - What's libera's concern?
  • When will spaces be out of beta?
    • IRC bridge
      • Any idea when its out of beta? (not to be disclosed)
      • 100 users limit, what workarounds do we have?
        • This will be handled as part of the homeserver purchase, no further issue

Talk notes

  • more use of matrix
  • aspirations and mitigations
  • irc is not going away
  • this is about defaults
  • promote use of matrix
  • integrate community (lots of slack talk this am)

Current plan as of 2021-06-14

  • Mozilla's server is a good model

  • Funding still TBD

  • Homeserver for Ansible at Gold level

  • Bridge plumbing for all ansible rooms to equiv Matrix rooms

    • Start with smaller WG rooms and work up
    • Use the Libera bridge directly
      • Portal rooms are best, per Element devs
      • Need a plan for the two rooms that have existing matrix rooms
      • Guest mode means users may not even need to sign up to view rooms
        • Could also replace public history, you can create matrix.to links to specific lines of the room history
    • Set IRC modes appropriately and test as we go

  • Decide policy for homeserver accounts

    • Could go small, a "nickel" level homeserver would handle our rooms
    • Otherwise minimum is probably 100 accounts, so how should we allocate these?
      • Staff?
      • Steering committee
      • Long time / senior community?
      • Open registration?
        • Good po
    • How many users do we expect?
      • Existing matrix users may not want to take up the offer of an Ansible account
      • Open registration could get expensive
        • We could always close the registration if it goes too high

  • DNS name

    • We'll get custom dns for rooms (and users if we do that)
    • We need a DNS subdomain (or .well-known/matrix) for that, such as
      • #ansible-community:matrix.ansible.com
      • @gwmngilfen:matrix.ansible.com
    • Alternate option (thanks @corvus) is to get .well-known added to ansible.com
      • Gundalow can help with this

Who should get accounts?

  • This is similar to "Who should get an email address on our domain"
  • Should user accounts be under a different domain?
  • Follow Ansible CoC

Things we might want to work with Element on

Interesting blog posts and pages

Questions that have come up in chat

  • misc: i have seen some issues with ghosts and people joining twice

So this is an issue with "double-bridging" which is where a portal room and a plumbed room exist at the same time. How does this happen? Consider this scenario:

  • #room exists on Libera. Users on Matrix join it as #room:libera.chat (this is a portal room)
  • some users don't know about the portal room. They create a new room called #room:matrix.org and start chatting
  • The admin of #room:matrix.org learns about #room on Libera (but still does not know about the portal room) and adds the plumbed bridge integration to the room.
  • Now users in #room:matrix.org will also appear as "user[m]" in #room:libera.chat. That's because it's true - the plumbed bridge creates users on Libera that the portal room then sync's back to the Matrix side of the portal

This key understanding here is that one should only create portal or plumbed rooms, not both. Thanks to the upgraded tech stack on Libera, portal rooms are recommended by Element, so we'll be standardising on that (but rooms can have arbitrary additional aliases, so we'll also have matrix.org and ansible.com room addresses)

  • misc: you talk about giving accounts, but what about removing them

Super question. I've been discussing this with other communities, and the consensus seems to be that an MXID is very similar to an "work email". It's something that belongs to the organisation, and you can lose it:

  • GNOME's draft is here but it's a draft so don't go widely resharing please.
  • Mozilla don't explicity talk about loss of account, but the Matrix notes cover migrating accounts (and how MXIDs cannot be reused, interesting), and the CoC (CPG in Mozilla terms) deals with losing access to Mozilla systems

An org's MXID means you're representing that org, just like with work mail. That means you need to adhere to the org's CoC when using it, and that will be the primary reason for losing an account

  • An open question is when someone peacefully departs the org. If this were an employee leaving a company, then email would be revoked. But due to the lack of multi-account Matrix clients, I forsee scope-creep, people will use their one MXID for all things. So, it's highly disruptive to lose it.
  • Tools exist for migrating accounts, but it's a tricky business. No worse that migrating email though (probably slightly better, tbh)
  • Element bills for active users, so we may not need to remove accounts just because they left the project. If they're still active on Matrix elsewhere, then perhaps, but if they disappear entirely they won't cost anything.
Select a repo