Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

iamb 0.0.10 (2e6376f) requests image attachments with a deprecated URL scheme #378

Open
dstu opened this issue Dec 8, 2024 · 2 comments

Comments

@dstu
Copy link

dstu commented Dec 8, 2024

In iamb 0.0.10 (2e6376f) (installed via Debian apt), the URLs that iamb requests for images attached to messages are for the /_matrix/media/v3/ endpoints. Per https://spec.matrix.org/unstable/client-server-api/#content-repository, these are in the process of being deprecated. URLs of the form /_matrix/client/v1/media/ should be used, instead. Our server is running matrix-synapse-py3 1.20.2+bullseye1 (also installed via Debian apt).

To reproduce:

  1. Connect to a Matrix server that uses newer image URLs.
  2. Have someone send an image with a message attachment.
  3. Try to download the image (:download in iamb).
  4. Observe that the download fails.
  5. The server's access logs should show that iamb requested a URL with an old-style path component.
dstu added a commit to dstu/iamb that referenced this issue Dec 9, 2024
This accommodates recent protocol changes and addresses ulyssa#378.
@dstu
Copy link
Author

dstu commented Dec 9, 2024

It looks like this can be solved by updating the matrix-sdk dependency to version 0.8. I have taken a stab at this at https://github.com/dstu/iamb/tree/update_matrix_sdk_0.8. (That builds cleanly and appears to run fine, but I haven't given it a solid shakedown yet.)

Before opening a pull request, I'd like to have a better understanding of changes in the ruma and matrix-sdk crates, to make sure we aren't introducing new bugs. And it might be nice to have an integration test to validate the behavior of :download in the client before opening a pull request. But I'm happy to do so sooner if that seems reasonable.

@mordquist
Copy link
Contributor

Dupe of #349.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants