User spoofing for puppeteering support for XMPP

[poVoq]

This was discussed internally and would be a really nice feature to have.

Previously there was a very experimental user spoofing option via slack like webhooks, but that was removed since the Prosody module it depended on was long abandoned.

The ideal solution would be to add XEP-0225 privileged component connection support to Matterbridge, so that it can connect directly to a XMPP server and create user puppets as needed.

The blocker for that is basically that the go-xmpp library that we use lacks this feature. It seems however that this could be added relatively easily based on an previous partial PR.

An alternative would be to switch to the Mellium library that supports this, but this might bring other disadvantages and would need a partial rewrite of the xmpp bridge part.

One of our contributors made a proof of concept with Mellium to explore the general feasibility of this and it seems to work in principle.

Another option would be to use an existing feature in Matterbridge to spawn multiple connections on an SASL anonymous capable c2s endpoint and manage multiple bots that way. This is more of a hack and needs server specific server side configuration that most XMPP servers lack.

[selfhoster1312]

For reference, here was the start of implementing a component using mellium library https://codeberg.org/j.r/mellium-poc

[kousu]

I've done some experiments and it's not necessarily necessary to use a component to do XMPP puppetting, see https://github.com/kousu/xmpp-puppetbot/tree/v1

As I understand it, the difficulty with XMPP puppetting is that every group join on a single XMPP stream becomes a nickname change. A single stream is not allowed to impersonate other users.

But a separate stream is allowed to pick any MUC nickname it wants, meaning it can impersonate anyone (so long as their nick isn't already taken). It happens by accident sometimes because Gajim and Conversations can get desynced, in fact, and I find myself joined twice to a chatroom. It's very annoying actually. But for puppeting it's great.

However, this approach falls down around permissions. If "Allow anyone to see your JID" is on -- or if you're a moderator in the room -- then Conversations and Cheogram render all puppets as the same user:

(4 participants but only 2 icons listed? what??)

Even when "Allow anyone to see your JID" is off, Cheogram still somehow manages to use the same icon for each:

but Gajim and Dino properly render the puppets separately whether or not they know the real JID.

Gajim:

Dino:

I think Gajim and Dino are doing the right thing here and Cheogram is wrong. But we're not going to win that battle.

---

A component would be puppets.example.org, and would therefore be allowed to impersonate anyone@puppets.example.org, and each of those could join any rooms by using JID room@rooms.somesite.org/anyone. That's cleaner, but requires access to an XMPP server. --- but it's not that much access, it doesn't have to be a real XMPP server, it can be a server that hosts nothing but puppets.example.org and it can be on the same machine as matterbridge.

After working through this, I think that is an excellent design 🎉 🎉 🎉 . But I didn't understand that that was the plan originally, sorry 😅. I thought the plan was to make the component be the MUC.

In principle, matterbridge could become an XMPP server itself, directly doing the xmpp s2s protocol as puppets.example.org. Then it would be easier to set up -- though you won't get out of having to deal with certs -- but then that complicates things for anyone who does want to run an XMPP server on the same machine or do XMPP vhosting, so the component design is more flexible.

[poVoq]

Yeah, and running a simple Prosody really isn't that hard.

P.s.: I think another problem with the non-component hack you described first is that all the puppets would have the same avatar picture. I believe (hope) that is also better with the component option.