This repository has been archived on 2023-12-05. You can view files and clone it, but cannot push or open issues or pull requests.
2020-10-02 23:12:32 +02:00

18 KiB

Table of Contents

todo / extra

already irc networks

irc bridge to freenode

This describes how to use official matrix bridge. The matrix discussion room is

note: I hope for other IRC networks should be very similar

previous steps

To do an IRC bridge you have to be operator (op)

Check the general state of the chat room with the following command

/msg ChanServ info #channel

If you are alone in the room and seems that is not configured you can register it

/msg ChanServ register #channel

If you loose the operator of your channel (you logged out), ask it to ChanServ

/msg ChanServ op #channel yourUser

To register a room you require to register your current nickname

/msg NickServ REGISTER password

Change nickname

/nick newUsername

To identify your existing user

/msg NickServ IDENTIFY yourUser password

note: if the room is not configured but the room is full of people, nobody can claim to be operator. A solution is try to convince everyone to quit the room (difficult), or get help from #frenode channel/freenode staff (not tested)

/msg ChanServ info #coopdevs


do the bridge!

From Riot client in a matrix channel select Manage Integrations, select IRC, select the network Freenode, select operator (you need your IRC user logged and being operator of that channel), link

After some seconds you will receive a message like

<MatrixBridge> has requested to bridge 'My room in Matrix' ( with #my-room-in-IRC on this IRC network.
               Respond with 'yes' or 'y' to allow, or simply ignore this message to disallow. You have 300 seconds from when this message was sent.
<yourUser> y
<MatrixBridge> Thanks for your response, bridge request authorised.


configure IRC room to avoid spam

With the following configuration everyone can read the channel but only registered IRC users can write to it. With the exception of matrix users (who are not registered accounts in IRC!):

/mode #channel +qe $~a *!*@gateway/shell/*

if you are fed up of lots of login/logout traffic from spammers, you can ban unidentified users from IRC with exception of matrix bridge:

/mode #channel +be $~a *!*@gateway/shell/*

check all/configuration of a channel with:

/mode #channel bqeI


utility to kill spam

future work

save disk space: purge history

the most relevant script (untested):

Interesting discussions:

Relevant documentation:

send HTML formatted messages

You can send HTML formatted messages (for example for bot/alert notification) with curl, at the moment this is officially not documented

check html message example in send_message.env.example

and use it in

telegram bridge

Comment about telegram bridge: A matrix els usuaris de telegram es veuen com un usuari de matrix, però els missatges escrits a matrix a telegram els diu un bot que diu "tal persona a dit"

translating a telegram channel to riot

Only some people can send messages, and lots of listeners

Solution? You can restrict users from sending messages to the room and only accept Moderator, Admin, etc. The rule has the name "To send messages, you must be a"

In matrix-riot, there is no way to hide members of a channel


specification for script that migrates user from one server to another

implementation: work in progress


  • matrix API
  • userA_A: user A in server
  • userA_B: user A in server

objective: perform migration from userA_A to userA_B


  • userA_A massively invites userA_B to all its rooms
  • userA_B massively accepts invitations of userA_A
  • userA_A puts the same permissions it has on userA_B
  • export riot encryption keys from userA_A to file
  • import riot encryption keys from file to userA_B
  • [optional: blank account in server A] userA_A leaves all rooms she is in

script to blank account in server A

#!/usr/bin/env python3

 # motivation: 
 # - there are problems to deactivate account and rooms in matrix
 #     -
 #     -
 # - this will be part of the migration script for users between one server and another

 # this script login to a specific matrix account and LEAVES ALL ROOMS

 # requirements
 # - apt install python-pip3
 # - pip3 install wheel matrix_client

 # based on
 # useful resource

import sys

from matrix_client.client import MatrixClient
from matrix_client.api import MatrixRequestError
from requests.exceptions import MissingSchema

 # access data


 # login

client = MatrixClient(host)

    client.login_with_password(username, password)
except MatrixRequestError as e:
    if e.code == 403:
        print("Bad username or password.")
        print("Check your server details are correct.")
except MissingSchema as e:
    print("Bad URL format.")

 # actions

roomlist = client.get_rooms()

print("leaving rooms:")
 # list() does a copy of dictionary to avoid error: "RuntimeError: dictionary changed size during iteration" -> src
for room in list(roomlist.values()):
    print("  " + room.room_id + " left")

use our own integration server

particular interest: monitoring with prometheus and grafana




tomeshnet bot remindering meetings:

bot to interact with gitlab stuff

bash script to send notification to bot

another login script - The script is written for a special old version of the Python SDK that has E2E support added, so it'll probably work if you remove the encryption=True and device_id parts from the script

(you have to test this) when you login with a new device an access_token is generated, that access_token can be used until that device exist or you logout

do your own piwik analitics on matrix

something useful

matrix email bridge idea

requires this particular Federated Matrix Identity Server - mxisd - you can use this provider to test

then you can probably talk with users

whatsapp and telegram bridge (take 2) idea - you can use this provider to test

dark things about matrix and riot

Political concern: Main funder is?was? AMDOC, search amodoc-mossad on google and you can discover something interesting. The funding situation is strongly changing (see relevant notes)

Tecnological concern: matrix generate ALOT ot metadata on the central server, even if the communication is encrypted, the metadata are not and most of the software analysis to generate network maps use just metadata, more you have more the map is accurate

Riot client is not free. Such a hype for a server-client non-free [0] software which tries to act as a Person In The Middle interconnecting any other network...


relevant notes:

extra notes 2019-2-22

Here follows a backup of the insights from Maximus and this is the link to the original conversation

Given the inability to implement and document a functional Matrix protocol by New Vector and resolve security vulnerabilities that are public for years, mxhsd will no longer try to implement the Matrix protocol. Instead it will implement what we (Kamax) think makes sense and document as we go. ->

In no specific order:

  • State resets which can be used to abuse permissions or create states that never existed (it was used last year to take over Matrix HQ per ex)
  • The value of depth is not checked/validated properly, leading to possible room takeover attacks
  • Until very recently, malicious/fake evens could be injected
  • There are amplification/proxying attacks via the /send_join and /media endpoints

and that's just what's on top of my head - I didn't bother to keep scores in the end

there are also a whole set of (D)DoS attacks on a server by abusing server ACLs, max values of various fields and the likes

I've spent several years in the Matrix ecosystem and built a bunch of projects on it, and at least one for each spec (Client, Server, Application, Push). There is much more to it than what I just listed, but it would be a waste of time to discuss them further. I've already written things like a Server ACL feature review or just explained the various issues to length in various rooms and on my 18 months as a Matrix dev manifesto.

In terms of how to solve the issues, I know several ways to solve them personally, but they tend to be all related so it's faster to just take a different approach, which I am now doing using The Grid project (fork of Matrix) and this rewrite of mxhsd now called Gridepo.

I have tried my best to also report those issues and talk to the MAtrix dev about them before going down this road but to no avail. Matrix is deeply insecure and not privacy friendly at all. The only reason it has been getting away with it so far is because there is no alternative implementation that truely challenges the protocol and the implementations. If you look in the client world per example, many are just copying what Riot is doing instead of following the spec. In terms of servers, there hasn't been any successfully federated server ever until mxhsd & construct came along.

Given that we have to reverse engineer everything all the time, we just know were all the issues are, and we are now taking action to solve them the best way we can: forking.

As for promoting Riot, my personal opinion is that it just promotes a closed protocol/ecosystem as Riot is actually not Matrix compatible and very bad in terms of privacy. One of the worse horror story is that everytime you switch to a room, a HTTP call is made to with a token directly used to retrieve your Matrix ID. They can know exactly when you do something, your Matrix ID, etc. This can also be hijacked by a third-party potentially as there is no safeguard in place to prompt the user about sharing their personal info (All this done via the /openid endpoints).

This is the kind of thing that shows me there is no path forward in Matrix as the ecosystem is simply dominated by Riot and Synapse which do not follow the spec themselves and block any implementation that stick to the spec to actually be able to do anything. So you are force to implement the custom ways of Riot and synapse (whatever you build) which prevents from solving the security issues even if you wanted to.

3pid problem

In the case of federation/state resolution/internal room stuff, I know that there is no homeserver to this day, synapse included, that actually implement the S2S API spec. Even just trying to send data fails with a 404 with synapse, because it's actually using another URL. (this is just the tip of the iceberg). So rather than spend more time reverse-engineering a moving target, I prefer invest my own time somewhere else.

Users dilemma

A known problem is that until today (late april 2020) it is not possible to completely remove a user from the postgresql database, only unable them (and changing their names in the database is a bad idea, things will start to get very messy, being related to dirrefent tables). That means that the username will not be able for new users. If you use LDAP you want to keep the possibility to create new ldap users, without their names (uid= in ldap) to be already used in the matrix server. Which leads to close public registration on the server. To be able to allow public registration, and still not have a complete caos when creating important LDAP users, as a workaround, after few trials and errors (and database dumps) I was able to overtake an existing matrix user with a new LDAP user: a very authoritarian way to do it!

  • when adding a new ldap user, the ldap username/password will allow login to matrix server.
  • once logged in the matrix server, change the password in the matrix settings (LDAP and matrix's postgresql passwords are different and both are valid to login the matrix server)
  • in matrix settings, write down the existing email address and delete it
  • somehow, you can add a new email address and verify it, but it will not be permanetly stored in the matrix server (LDAP is unaffected)