continuwuation/continuwuity

Watch

Fork 135

[Tracking issue] Rewrite of media service #1990

New issue

Open

opened 2026-07-14 22:24:31 +00:00 by silversys · 5 comments

silversys commented

2026-07-14 22:24:31 +00:00

Member

Tracking issue for me to document progress until i get a PR opened with some actual code.

Background

The media service is currently a smoking mess, almost unreadable, and full of legacy code. I intend to rewrite the entire service to make it more readable and coherent, and to support modular storage backends through the use of a single trait that backends can implement.

Discussions started as me wanting to implement S3 support (#93; matrix.to), something i quickly abandoned (was told wasnt actually important, and the issue was closed). Decided to rewrite the media stack anyways (matrix.to), as it is hot garbage.

Rough outline of tasks

Create trait for storage repositories
Implement filesystem storage repository
Change how files are stored and how they use the DB
- Currently stores all the data about the file in the key for whatever reason, leaving the value empty. Should be changed
Create migrations for files from old to new DB keys
Implement dedup? Should be easy enough with a sha256-sum for uploaded files, pointing different MXC-uris to the same files based on that sha-sum.
Testing
- Automated testing? Unit tests? Will need to investigate ways to test different parts of the code. Storage repositories will be easy enough to test with adding files, checking sha-sums, listing and ensuring correct output, etc, as these don't require DB access.
Better file management tools
- Listing files?
- Downloading from URL? (i.e. admin/user provides URL, c10y gets a file from that URL and stores it?) Both MXC and HTTP(s)

Tracking issue for me to document progress until i get a PR opened with some actual code. ### Background The media service is currently a smoking mess, almost unreadable, and full of legacy code. I intend to rewrite the entire service to make it more readable and coherent, and to support modular storage backends through the use of a single trait that backends can implement. Discussions started as me wanting to implement S3 support (#93; [matrix.to](https://matrix.to/#/!ksTlboXVgcyWjv5GrlEeKyQuJ8ZCprnwQx2b6-BQ44Q/%24_yyG4ynnJ0JBX93OR76O-pL_6cj2IfnYVpg87yv3E1I?via=wolfgirl.pet&via=explodie.org&via=matrix.org)), something i quickly abandoned (was told wasnt actually important, and the issue was closed). Decided to rewrite the media stack anyways ([matrix.to](https://matrix.to/#/!ksTlboXVgcyWjv5GrlEeKyQuJ8ZCprnwQx2b6-BQ44Q/%24PDtOPr_L1csuGrv3QRjv4tNHOtG6b-lfOoFYQBoSZEY?via=wolfgirl.pet&via=explodie.org&via=matrix.org)), as it is hot garbage. ### Rough outline of tasks - [x] Create trait for storage repositories - [ ] Implement filesystem storage repository - [ ] Change how files are stored and how they use the DB - Currently stores all the data about the file in the key for whatever reason, leaving the value empty. Should be changed - [ ] Create migrations for files from old to new DB keys - [ ] Implement dedup? Should be easy enough with a sha256-sum for uploaded files, pointing different MXC-uris to the same files based on that sha-sum. - [ ] Testing - Automated testing? Unit tests? Will need to investigate ways to test different parts of the code. Storage repositories will be easy enough to test with adding files, checking sha-sums, listing and ensuring correct output, etc, as these don't require DB access. - [ ] Better file management tools - [ ] Listing files? - [ ] Downloading from URL? (i.e. admin/user provides URL, c10y gets a file from that URL and stores it?) Both MXC and HTTP(s)

silversys changed title from ~~Rewrite media service~~ to Tracking issue: Rewrite of media service

2026-07-14 22:24:46 +00:00

nex added the

Matrix/Core

Enhancement

Meta

labels

2026-07-15 13:09:08 +00:00

silversys was assigned by nex

2026-07-15 13:09:16 +00:00

silversys commented

2026-07-20 15:48:47 +00:00

Author

Member

Decided to nuke media_compat_file_link. No more ability to downgrade to Conduit.

Context:

me: Question: At the moment we have the media_compat_file_link option for possible backwards-compatability with Conduit (i.e. moving back to Conduit) -- is this still something we wish to keep? It would make my life a LOT easier if I could just drop that option completely and not allow old filenames and file links
Ginger: kill it ✅

Decided to nuke `media_compat_file_link`. No more ability to downgrade to Conduit. --- Context: > **[me](https://matrix.to/#/!ksTlboXVgcyWjv5GrlEeKyQuJ8ZCprnwQx2b6-BQ44Q/%24tjadZ8AA21lnkaAW_A5bFTgNqIBae7TF0TZuP_xq3AU?via=wolfgirl.pet&via=explodie.org&via=matrix.org):** Question: At the moment we have the `media_compat_file_link` option for possible backwards-compatability with Conduit (i.e. moving _back_ to Conduit) -- is this still something we wish to keep? It would make my life a LOT easier if I could just drop that option completely and not allow old filenames and file links > **[Ginger](https://matrix.to/#/!ksTlboXVgcyWjv5GrlEeKyQuJ8ZCprnwQx2b6-BQ44Q/%24AHK6aiq3IHT0wyIfkRcNfdObhX3MJR6fT7-cmNhoIf8?via=wolfgirl.pet&via=explodie.org&via=matrix.org):** kill it ✅

silversys commented

2026-07-21 16:54:06 +00:00

Author

Member

File management feature suggestions:

delete all media over certain filesize
delete all media from user
delete all media from remote server
ideally, delete all media from room
a command to show some stats (maybe per-local-user / per-remote-server? )

These should all ideally be part of the same commands with multiple flags to allow for combinations of filters

File management feature suggestions: - delete all media over certain filesize - delete all media from user - delete all media from remote server - ideally, delete all media from room - a command to show some stats (maybe per-local-user / per-remote-server? ) These should all ideally be part of the same commands with multiple flags to allow for combinations of filters

silversys referenced this issue from a pull request that will close it,

2026-07-21 18:00:15 +00:00

WIP: Rewrite of media service #2030

ginger added this to the 26.7.0 milestone

2026-07-25 13:59:21 +00:00

silversys referenced this issue

2026-07-27 12:55:07 +00:00

FR: media retention based on access time. #440

nex removed this from the 26.7.0 milestone

2026-07-27 13:54:54 +00:00

silversys commented

2026-08-02 17:40:00 +00:00

Author

Member

From my digging into the code so far, i think this rewrite will consist of multiple PRs:

Rewrite how files are stored on disk. This will change file management into being based on a trait, and technically support multiple storage backends (even though filesystem will be the only one implemented as of right now). The service itself will maintain the same interfaces as before.
- This will also include the inability to move back to old versions (see #1990 (comment))
Add ability to differentiate between local and remote media. This will further change how files are stored, moving them into a subdirectory based on server name.

The order for the rest is unknown, but will at least consist of:

Changing how thumbnails are stored (and likely a rewrite of the entire thumbnail.rs file.
Same as above, but for URL previews. They currently use manually serialized db values which is cursed and i want it gone.
Adding more functionality for media management (see #1990 (comment))
Some sort of deduplication, likely based on content-addressable storage (filenames = sha-sum of contents?)

This will all likely take a good while to implement, especially as I start full-time work tomorrow, but I will keep everyone updated.

From my digging into the code so far, i think this rewrite will consist of multiple PRs: 1. **Rewrite how files are stored on disk.** This will change file management into being based on a trait, and technically support multiple storage backends (even though filesystem will be the only one implemented as of right now). The service itself will maintain the same interfaces as before. - This will also include the inability to move back to old versions (see https://forgejo.ellis.link/continuwuation/continuwuity/issues/1990#issuecomment-32561) 2. **Add ability to differentiate between local and remote media.** This will further change how files are stored, moving them into a subdirectory based on server name. The order for the rest is unknown, but will at least consist of: - Changing how thumbnails are stored (and likely a rewrite of the entire [thumbnail.rs](https://forgejo.ellis.link/continuwuation/continuwuity/src/branch/main/src/service/media/thumbnail.rs) file. - Same as above, but for URL previews. They currently use [manually serialized db values](https://forgejo.ellis.link/continuwuation/continuwuity/src/commit/9491be928d6ded74e8a2750dc52b7f299b9fd446/src/service/media/data.rs#L176-L237) which is cursed and i want it gone. - Adding more functionality for media management (see https://forgejo.ellis.link/continuwuation/continuwuity/issues/1990#issuecomment-32629) - Some sort of deduplication, likely based on content-addressable storage (filenames = sha-sum of contents?) This will all likely take a good while to implement, especially as I start full-time work _tomorrow_, but I will keep everyone updated.

silversys changed title from ~~Tracking issue: Rewrite of media service~~ to [Tracking issue] Rewrite of media service

2026-08-02 17:40:11 +00:00

silversys commented

2026-08-27 15:45:26 +00:00

Author

Member

I am still slowly working on this, but with just starting a new job and the summer vacation over my available free time has dropped significantly so it will take longer than expected.

Mark my words though, I will finish the rewrite at some point.

I am still slowly working on this, but with just starting a new job and the summer vacation over my available free time has dropped significantly so it will take longer than expected. Mark my words though, I _will_ finish the rewrite at some point.

silversys commented

2026-10-15 20:00:57 +00:00

Author

Member

#1990 (comment)

Possibly a third PR with S3 support as well. Discussed it a bit more with people in dev chat, there seems to be a vague-ish agreement that it would be a nice-to-have, but not really an important feature. Would probably use something like MSC3870 or MSC4177, details to be figured out later

https://forgejo.ellis.link/continuwuation/continuwuity/issues/1990#issuecomment-33384 Possibly a third PR with S3 support as well. Discussed it a bit more with people in dev chat, there seems to be a vague-ish agreement that it would be a nice-to-have, but not really an important feature. Would probably use something like MSC3870 or MSC4177, details to be figured out later