[Matrix] switch to mautrix-go + initial support for application services#1864
[Matrix] switch to mautrix-go + initial support for application services#1864nightmared wants to merge 11 commits into
Conversation
![qlty-cloud-legacy[bot]](https://avatars.githubusercontent.com/in/9403?s=60&v=4){kind=small}
That seem unlikely to happen given Matterbridge config heavy approach, but it would be really nice if this appservice improvement could properly create ghost users Matrix side through the bridge. |
|
Agreed on both counts! As for the "proper ghost accounts", that's actually what it does: |
|
I am not a Go developer and thus don't have an dev environment to compile this easily. But if you can share a x86_64 binary I am willing to test it in a IRC-Matrix-Discord setting. |
|
@nightmared thanks for your work! :) I'll try to test later |
|
Does this also bring support for IRC I don't know if the previous library supported |
nightmared
force-pushed
the
mautrix_appservice
branch
from
186b23a to
c59c7b0
Compare
Sure thing, here is one: https://nightmared.fr/files/matterbridge-2022-08-14. You can verify its integrity with sha256sum: Sorry about the time this took me, I have discovered the joys of COVID19 these past few days, and unsurprisingly that doesn't really help focusing on code (or anything really) ^_^ |
No, I haven't added support for |
nightmared
force-pushed
the
mautrix_appservice
branch
from
201874a to
7cc9a31
Compare
|
For golangci-lint, while I could reproduce locally the golangci-lint messages about the extraneous spaces in Does anyone happen to know why that is ? |
|
Hi, is this still being worked on? I have had so much problems with other bridges yet matterbridge works really well. Would love to have this feature. |
|
@Akselmo Yes, this is definitely still ongoing :) I'm currently waiting for user feeback to know if it works for other people, and if the current design seems acceptable or if I have to go back to the drawing board. So if you happen to have some feedback, or to know people who might, I woul be happy to hear some or discuss this further! |
Ah, I could try building this with your PR and see if it works for me. |
|
Alright I got it to work, here's some feedback!
Anyhow so far so good and I prefer this way much more over the other bridge bots I've tried. |
|
Thanks for the feedback!
|
If the room ID started with It's not that big of a deal since using the public address of the channels worked. I tend to use the internal addresses/ID's in case I change the public address, so it still keeps pointing to right place.
I could try changing it again, it was a bit odd. Sometimes when closing the bot and then starting it up again it wouldn't launch the appservice and worked in the non-appservice way: Instead of ghost accounts it would just relay messages with Edit: Okay I changed it and now it works. It seems that if the appservice is not up, it relays the messages normal way, but when appservice is up it uses the ghost bots. Could perhaps make it so that I could change different nick style for the appservice bots itself? |
|
I also noticed custom emojis wont go over the bridge either. I guess this is also something to do with Mautrix? |
|
What do you mean by "custom emojis"? Reactions to messages? |
I mean actual emojis and stickers. Here's an example of Discord custom emoji to Matrix Discord: Matrix: And from Matrix to Discord Matrix Discord This bridge has managed to solve this issue, so maybe theres something we could use? https://github.com/matrix-org/matrix-appservice-discord Also, something new I noticed! After enabling appservice, someone on the Matrix channel has to talk first for the appservice to be active.
After enabling bot, the first message there came from Discord, without the appservice. But after I said something in the Matrix channel, then tried again from Discord, the appservice was enabled. |
|
Also it seems I can't delete messages on discord from matrix side. |
|
Thanks for all these reports, I will take a look at them (mostly this week-end I think)! |
|
No problem, I don't know Go but I can also look into some issues if I got time. |
nightmared
force-pushed
the
mautrix_appservice
branch
from
7cc9a31 to
7d70cb2
Compare
nightmared
force-pushed
the
mautrix_appservice
branch
from
73079d0 to
7163d6c
Compare
Sorry for the late reply! #1864 (comment) is an adequate status of the progress of this PR. As such, I believe it would be best to merge the PR as-is (fixing eventual errors and style issues of course), and to open dedicated PR for each of these issues, considering they are enhancements that we would love to see, and not regressions. This would allow other developers to look into adding support for them, which is understandably not very feasible with the current PR. What do you think? |
nightmared
force-pushed
the
mautrix_appservice
branch
from
16459b0 to
bbea005
Compare
|
Code Climate has analyzed commit bbea005 and detected 5 issues on this pull request. Here's the issue category breakdown:
View more on Code Climate. |
|
Can you please share another x86 binary for testing? I am running into probably very basic issues in compiling it that are likely just due to me not being used to the go tool-chain at all and I would rather spend the time actually testing the bridge than trying to debug go compilation which I am not using at all otherwise. Thanks! |
|
Sure thing: https://nightmared.fr/files/matterbridge-2023-04-11. And to check its integrity: FYI, if you want to reproduce the build yourself (this is always better than relying on someone else on the internet, like me :)): |
|
How do you enable puppeted users? Messages seem to come from the normal bot user |
This has some hints: https://github.com/42wim/matterbridge/pull/1864/files#diff-0b4fb334dec5e2cf5c073565d97d11ffb59c157269ff451f25df8ef26fac4d9f But so far I didn't manage to fully configure it due to a lack of time. Probably tomorrow. |
|
Here are some notes from my testing: Because the non-Matrix platform I use is Mattermost, I will say "mattermost", but it likely means any non-Matrix platform that Matterbridge supports. 1: user puppeting
Steps to reproduce:
It's probably this item in the todo list:
I am not sure why that workaround would be needed. The appservice should be listening to messages on the claimed prefixes, no matter what, and sending messages as bridged users is completely independent from the REST API of the appservice. Sending messages as bridged users should only involve making the same queries to the Matrix homeserver REST API, but with a new parameter on the query string: Might this be a bug in 2: imagesPDF file was properly bridged from Mattermost to Matrix
Element (seems completely blank):
Fluffychat (attempts to load image but fails because it only contains
3: deletions
|
|
@gabrc52 can you share your config for the appservice part? I finally got time to try this and the non-appservice part works for Matrix <-> IRC, but even after enabling the appservice it continues sending it as a bot (yes I tried sending from Matrix first). Sadly nothing in the logs either side and matterbridge starts up fine without complaining about a problem with the appservice part. I am not a big expert with appservice configurations though, so maybe I did something wrong in the config files. Thanks! |
|
@poVoq my file is id: "matterbridge"
url: "http://127.0.0.1:29777"
as_token: "REDACTED"
hs_token: "REDACTED"
sender_localpart: "matterbridge"
namespaces:
users:
- exclusive: true
regex: "@_mattermost_.*"
aliases:
- exclusive: false
regex: "#_mattermost_.*"
rooms: []
push_ephemeral: true
de.sorunome.msc2409.push_ephemeral: true
Since it is only listening to rooms starting with Off-topic: Also keep in mind if you just want to bridge IRC and Matrix, you're better off using a dedicated Matrix bridge. https://matrix.org/bridges/#irc. The purpose of this project, at least imho, is to have a powerful multibridge that works with as many platforms as possible. If you just have two platforms in mind you want to bridge, the Matrix ecosystem offers multiple bridges. |
|
Thanks a lot for sharing your config!
Hmm, that would explain why it fails with the suggested config as well: But I am a bit surprised about this as Matterbridge is usually used to bridge existing channels that are not named in a special way like this. Can I just remove that part for it to work with any Matrix channel specified in the Matterbridge config file? Or what would be a regex that works with any channel name? Edit: or do I need to create local alias names for each room to be bridged?
Yes I do run an appservice-irc already... the problem arises from double bridging multiple IRC channels (and a specific ToS clause of libera.chat) that requires an alternative bridge for now. |
I believe you can either set aliases to a catch-all regex ( to bridge all rooms (which would include DMs as well). I have not tested it, though.
Yeah, this is showing one of the differences between Matrix app services and bots with accounts. Since this PR is still under development, it could be improved so that for rooms that don't match the regex, it receives messages using the bot method, and sends them using the app service method. There's other Matrix bridges with puppeted users that let you link any rooms without needing to have any specific alias (such as the Discord one matrix-appservice-discord), so this is not a Matrix restriction per se. |
|
I noticed that Matterbridge fails to start if the Synapse server is not immediately available. This can be of course fixed via adapting the systemd script, but I think given the http nature of Matrix and the inherent slowness of it, a bit more failure resistance would be cool. |
|
For those looking for a Mattermost<->Matrix bridge only, I have done another one: https://github.com/gabrc52/mattermost-to-matrix |
|
Any news on merging this? I have been using it for a while now and it seems to work fine. Edit: it seems to have issues doing the user puppeteering when joining more than one Matrix channel? @nightmared any idea? |
|
Could this then be used to also do puppeting for Rocket.Chat? Not sure whether it can also act as the home server part for an appservice. |
|
Since I've not worked on this in a long time (nearly a year), and that the PR would have to be updated against code changes in "upstream" matterbridge, perhaps it would be best to close this PR? |
|
I tried using it, but it didn't work for more than one channel at a time so I went back to other bridging options. |
|
@poVoq Right, that's what I expected given the lack of polish this PR have received so far (which is my fault, for the most part). I think you were one of the very few people to give it a try, so it is reasonably safe to assume no one relies on it anymore. |
|
@antonizoon maybe this is something for your fork? It was almost working, just multi-room support was borked in my tests. |
7 participants
Hello,
This is a revival of #1541, #1543 and #1544.
Fixes #137.
Before considering reviewing this, I would really like for other people to confirm that it works for them, to detect some of the numerous issues that must be lurking inside this changeset.
If you want to test the appservice support, you can use the same example configuration than in #1544.
The work that remains to be done mainly revolves around application services: