MSC3896: Appservice media

[tezlm]

Rendered

[rapiz1]

The duplication of media immediately came to my mind when thinking about building bridges for my use. I joined lots of rooms in an IM service and these rooms may upload various images, files, etc. But I only need a small portion of the files. And for some rooms I don't check often so even images I don't need them. Given that I run matrix on AWS for personal use, it will cause a considerable storage cost. So this is a big blocker for me to adopt matrix and I think this MSC is very useful.

[rapiz1]

Also, I wonder if it's possible to solve the problem by adapting MSC2246: Asynchronous media uploads.

With MSC2246 implemented, I wonder if it can be done with:

1. /create a media, giving it an infinite lifetime
2. retrieve the media and /upload it when a /download request is received

Not familiar with the matrix specs though, just some thoughts

[Kladki]

Since currently media ids are largely generated at random, it is very possible that existing media could collide with new namespaced media. Because of this, there needs to be some sort of way to disambiguate this media, either by adding some sort of prefix to media by appservices that homeservers cannot use, vice versa, or something completely different.

[Kladki]

Not to sure how much of an issue this is, considering:

• Dendrite uses hex for media IDs ([0-9a-f])
• Conduit uses alphanumeric chars for media IDs ([0-9a-zA-Z])
• Synapse uses alphabetical chars ([a-zA-Z])

So perhaps something should be added to the spec stating that for automatically generated media IDs, only alphanumeric characters should be used, so that appservices can use other characters to not collide.

[turt2live]

This feels like a similar problem to users: if users already exist under the appservice namespace when the appservice is introduced, they are adopted into the namespace as well. For media, we'd do the same: media which matches the namespace is adopted by the appservice, regardless of when it was created.

The grammar concern is best handled by another MSC (#1597, primarily)

[Kladki]

I see. I will bring this up in the aforementioned MSC then, thanks!

[Kladki]

Should probably specify that for the endpoint, the unstable prefix is /_matrix/app/unstable/org.eu.celery.msc3896/media/{mediaId}

[Kladki]

Would the timeout_ms parameter from the client request be forwarded to the appservice?

[Kladki]

Doesn't really make sense in this context, since this is for async uploads, which doesn't apply for media appservices. Not sure why I even asked this (this can be marked as resolved).

[Kladki]

Is the server expected to always follow redirects, or should it use the allow_redirect param like the C-S API?

[Kladki]

Considering that this was added after the fact to ensure compatibility, I think this should be assumed for new endpoints.

[Kladki]

mautrix-discord sets up what is essentially a homeserver which only serves media, so perhaps that could be mentioned, and then explain how that is sub-optimal.

In the past it also intercepted requests to your homeserver with regex in a reverse proxy, so that can also be mentioned.