Kevin's musings

The fedoraproject has moved pretty heavily toward matix in the last while, and I thought I would share some thoughts on it, good, bad, technical and social.

The technical:

• I wish I had known more about how rooms work. Here’s my current understanding:
  • When a room is created, it has a ‘internal roomid’. This is a ! (anoyingly for the shell) followed by a bunch of letters a : and the homeserver of the user who created it. It will keep this roomid forever, even if it has nothing at all to do with the homeserver of the user who created it anymore. It’s also just a identifier, it could say !asdjahsdakjshdasd:example.org, but the room isn’t ‘on’ example.org and could have 0 example.org users in it.
  • Rooms also have 0 or more local addresses. If it’s 0, people can still (if the room isn’t invite only) join by the roomid, but thats pretty unfriendly. local addresses look like #roomname:homeserver. Users can only add local addresses for their homeserver. So if you were using a matrix.org account, you could only add #roomname:matrix.org to any room, not any other server. local addresses can be used by people on your same homeserver to find rooms.
  • Rooms also have 0 or more published addresses. If 1 or more are set, one of them is ‘main published address’. These can only be set by room admins and optionally published in the admins homeservers directory. published addresses can only be chosen from the list of existing local addresses. ie, you have to add a local address, then you can make it a published address, a main published address and if it’s in your homeserver directory or not. If you do publish this address to your directory, it allows users to search your homeserver and find the room.
  • Rooms have names. Names can be set by admins/moderators and are the ‘human friendly’ name of the room. They can be changed and nothing about the roomid or addresses changes at all. Likewise topic, etc.
  • Rooms are federated to all the homeservers that have users in the room. That means if there’s just people from one homeserver in the room, it’s actually not federated/synced anywhere but that homeserver. If someone joins from another server, it gets the federated data and starts syncing. This can result in a weird case if someone makes a room, publishes it’s address to the homeserver directory, other people join and then the room creator (and all others from that homeserver) leave… the room is no longer actually synced on the server it’s address is published on (resulting in not being able to join it easily by address).
  • Rooms work on events published to them. If you create a room, then change the name, the ‘name changed’ event is in that rooms timeline. If somehow you ignored or looked at all events before that you can see the state at that time with the old name, etc.
  • Rooms have ‘versions’. Basically what version of the matrix spec the room knows about. In order to move to a newer version you have to create a new room.
  • Rooms can be a ‘space’. This is a organizational tool to show a tree of rooms. We have fedora.im users join the fedoraproject.org ‘space’ when they first login. This allows you to see the collection of rooms and join some default ones. They really are just rooms though, with a slightly diffrent config. Joining a space room joins you to the space.
• The admin api is really handy, along with synadm ( https://github.com/JOJ0/synadm ). You can gather all kinds of interesting info, make changes, etc.
• When you ‘tombstone’ a room (that is, you put an event there that says ‘hey this room is no longer used, go to this new room’, everyone doesn’t magically go to the new room. They have to click on the thing, and in some clients, they just stay in the old room too, and if it happened a long while back and people left a bunch, depending on your client you may not even see the ‘go to new room’ button. ;( For this reason, I’ve taken to renaming rooms that are old to make that more apparent.
• There’s a bit of confusion about how fedoraproject has setup their servers, but it all hopefully makes sense: We have 2 managed servers (from EMS). One of them is the ‘fedora.im’ homeserver and one is the ‘fedoraproject.org’ homeserver. All users get accounts on the fedora.im homeserver. This allows them to use matrix and make rooms and do all the things that they might need to do. Having fedoraproject.org (with only a small number of admin users) allows us to control that homeserver. We can use it to make rooms ‘official’ (or at least more so) and published in the fedoraproject.org space. Since you have to be logged in from a specific homeserver before you can add local addresses in it, this nicely restricts ‘official’ rooms/addresses. It also means those rooms will be federated/synced between at least fedoraproject.org and fedora.im (but also it means we need to make sure to have at least one fedoraproject.org user in those rooms for that to happen).

The good:

• When I used to reboot my main server (that runs my IRC bouncer), I would just loose any messages that happened while the machine was down. With matrix, my server just pulls those from federated servers. No loss!
• In general things work fine, people are able to commnicate, meetings work fine with the new meeting bot, etc. I do think the lower barrier to entry (not having to run a bouncer, etc) has helped get some new folks that were not around on IRC. Of course there are some folks still just on IRC.
• Being able to edit messages is kind of nice, but can be confusing. Most clients when you up arrow assume you want to edit your last line instead of repeating it. This is not great for bots, or if you wanted to actually say the same thing again with slightly different stuff added. I did find out that nheko lets you do control-p/control-n to get next/previous lines to resend (and up arrow does edit).

The bad:

• Moderation tools are… poor. You kind of have to depend on sharing lists of spamming users to try and help others block them, but there’s no real flood control or the like. I’m hoping tools will mature here, but it’s really not great.
• Clients are still under a lot of development. Many support only a subset of things available. Many seem to be falling into the ‘hey this is like a group text with 3 of your buddies’, which may be true sometimes, but the vast majority of my use is talking to communities where there can be 5, 10, more people talking. Little message bubbles don’t really cut it here, I need a lot of context I can see when answering people. I’m hopeful this will improve over time.
• I get that everything is a room, but it’s a bit weird for Direct messages. Someone sends you a message, it makes a room, they join it, then it invites you. But if you arent around and the person decides they don’t care anymore and leaves the room, you can’t join and have to just reject the invite and never know what they were trying to send you.
• Threading is a nice idea, but it doesn’t seem well implemented on the client side. In Element you have to click on a thread and it’s easy to miss. In Nheko, you click on a thread thingie, but then when you are ‘in’ a thread you only see that, not activity in the main room, which is sometimes confusing.
• Notifications are a bit anoying. They are actually set on the server end and shared between clients. Sometimes this is not at all what I (or others) want. ie, I get 10 notications on my phone, I read them and see there’s some things I need to do when I get back to my computer. So, I get back later and… how can I find those things again? I have to remember them or hunt around, all the notifications are gone. I really really would love a ‘bookmark this event’ so I could then go back later and go through those and answer/address them. Apparently the beeper client has something like this.

Anyhow, that’s probably too much for now. See you all on matrix…