Support unauthenticated media

[tusooa]

I do not want authenticated media, please give back the media_url configuration.

[funderscore1]

They probably won't support that config. I think Synapse is going to drop it too.

[tusooa]

They probably won't support that config. I think Synapse is going to drop it too.

Then it defeats the whole purpose of running this bridge. I want the media to be accessible from the irc side for as long as my server exists. If synapse is going to drop that support, I am going to run the appservice on conduwuit instead.

[funderscore1]

This bridge may spit out invalid matrix IDs which may not work on Conduwuit, see: #1780 It is in violation of the spec, and as far as I know the only Matrix homeserver that does not care is Synapse.

[girlbossceo]

We (conduwuit) can consider a workaround for the username capitalisation issue if they refuse to fix this. Judging by how long the issue has been open for, I think they are uninterested for some reason even though it would be a very trivial fix.

[Half-Shot]

Hi folks, to address a few of the things raised here. Formally Matrix is moving to a model where all media is authenticated, and the bridge tries not to diverge from the spec (it is there for a reason after all).

The username violation is a bug with the bridge that we've just not had the resources to fix. I don't want to get into it here in this issue but formally the usage of nicknames in mxids is a mistake we've needed to clear up for a long time. It's certainly not an indicator that the bridge is willing to break the spec in the future.

That said, the underlying library for the media proxy supports omitting the TTL to make the media links valid forever (or at least as long as your IRC server is up). Unfortunately this didn't make it's way as far as this bridge, but that's correctable. You can also set the ttlSeconds to something extreme like 9007199254740991 (Number.MAX_SAFE_INTEGER) and it'll last until the next ice age.

This doesn't solve the concern that your IRC server might not live as long as your Matrix server, but unfortunately that's out of scope for this.

[funderscore1]

To be clear, I did not mean to say they are intentionally violating the spec, just that at the moment there is that bug.

[mweinelt]

We tried using it with a ttl of 0, for which the matrix-appservice-bridge seems to have special handling. But sometime links still appear as expired, which is somewhat surprising.

[heftig]

I've also got complaints from IRC users behind our bridge that the experience is now miserable. URLs are now too long and often unclickable in a terminal, and the default expiry was too short. And the bridge creates a lot of media because of long messages.

[f0x52]

The reason these links are so long is because of the 64 bytes SHA512 signature + 8 bytes TTL added on top of the MXC (which is already longer than most irc-ish media hosts), used to statelessly verify if the media should (still) be served.
A different, stateful, approach could either track the original MXC, or an even shorter identifier, in the bridge datastore, and use that to generate much more usable links.

[heftig]

SHA512 also sounds like overkill. SHA256 should be good enough for this.