Matterbridge: Avatars of XMPP Users

[Polynomdivision]

Since matterbridge allows avatar spoofing with bridges that support it, I decided to implement this functionality - as the current XMPP bridge does not.

In my current implementation, it requests the avatar of XMPP users whenever they send a message and stores it in the media server download. I haven't tested it in production, but the avatar gets correctly downloaded and saved.

This, however, required adding support for XEP-0084 (User Avatar) via a bit of XEP-0060 (Publish-Subscribe) to mattn/go-xmpp, which appears to be matterbridge's XMPP library's upstream.

For me, before I can contribute this code here, this requires that I either open a PR in go-xmpp's upstream and upgrade matterbridge in this regard or port it to matterbridge's fork of go-xmpp.

TL;DR: I have an (untested) implementation of spoofing of XMPP users' avatars, which requires
me to bring some changes into either 42wim/go-xmpp or mattn/go-xmpp

[qaisjp]

Personally I recommend you attempt to get the changes merged upstream. The additions in the fork can always be rebased on top of the latest upstream.

You could also send your improvement to the fork, in case upstream takes too long.

I'm looking into getting the forked changes merged upstream.

Maybe wim recommends something else though :)

[Polynomdivision]

I have now created an issue upstream and will attempt to get my patches merged. Probably would've done it anyway.

[42wim]

I agree with @qaisjp about trying upstream, I'll rebase the fork until it isn't necessary anymore.
You're welcome to open a PR at my fork too, (do it against the work branch).

FYI, I'll be doing some matterbridge work this weekend, so if you also have time it can get merged quickly in my branch, while waiting on upstream.

[42wim]

@qaisjp thank you for merging the other stuff upstream btw! 💯

[Polynomdivision]

Now that my User Avatar patch has been merged into matterbridge/go-xmpp, I will try to clean up my hacky branch of matterbridge and create a PR the coming days.

[42wim]

@Polynomdivision thanks, I've just also updated matterbridge with your changes.

[Polynomdivision]

I have now a prototype for which I rewrote my initial code to better
mimic what the mattermost bridge does. This led me to a curious
discovery: While the User Avatar specification for XMPP says that the
avatar data MUST be image/png, my server returned image/jpg.
Presumably because my web server has disabled MIME type sniffing, Discord - which is the bridge I am testing against - refuses to display my
avatar, although my browser can.

While I have some ideas, I am unsure about what would be the best
path:
1) Convert the jpg avatars into png avatars using image/png. This, however, in my testing resulted in a 16bit PNG, which Discord doesn't seem to support (https://github.com/discord/discord-api-docs/issues/504).
2) Store the avatar either as jpg or png and adjust the avatar map to return, additionally to its SHA hash, its MIME type. This would lead to a mixture of JPGs and PNGs, which some clients may not support.
3) Accept this and write it off as a bug or issue with Discord, though I suppose that not only Discord will have a problem with this

EDIT: For testing purposes, I have implemented 2, which works. But the question still remains.

[42wim]

Hm sorry I don't follow, where do you get the image/jpg avatar from?
Mattermost and discord use image/png and xmpp also needs it as you say.

[poVoq]

I updated to the latest version, but this doesn't seem to work with Discord yet? Anything special to configure on the XMPP side?

[Polynomdivision]

@poVoq Unless I have missed something, it shouldn't be implemented yet. I have yet to clean up my code and create the PR.

@42wim It may be that clients - or in my case Conversations - do not convert a jpeg into a png for use as an avatar, hence my code downloads whatever the server returns. It seems that this was an issue with Conversations, but I am not sure whether it was fixed.

Since this now seems like my client is just behaving in a non-standard way, I can clean up the code and create the PR, unless this issue is bigger than I thought.

[Polynomdivision]

I now cleaned up my code and created the PR. I should note, though, that my patch does not check for support of User Avatars. I don't know how it handles the case that either PEP or User Avatars are unsupported.

[42wim]

@Polynomdivision Just merged your PR.

Would you mind making an extra one wrt the PubsubRequestLastItems on every message on xmpp servers without support of User Avatars. Maybe if after X-retries we don't have an avatar stop requesting them.

Or if it's possible to ask a XMPP server on start-up what's supported and making a decision based on that.

[Polynomdivision]

Or if it's possible to ask a XMPP server on start-up what's supported and making a decision based on that.

Yeah, that's definetely possible. Though that would, as far as I know go-xmpp, require another patch, that I have ready but need to separate. Using a disco request at startup should be the much simpler solution.

[42wim]

@Polynomdivision ok, feel free to send a PR, I'm going to close this issue for now as you implemented it :-)

Thanks again