Implementation requirements:

• Server (uploading)
• Server (downloading)
• Client (using)

Rather than using a boolean, could the uploader specify a lifetime for the media after which servers could automatically purge it?

The current use cases don't have a known lifetime for the media objects.

The only currently listed use case is #4268 and based on matrix-org/matrix-rust-sdk#5113 (comment) this might be catered to with a static lifetime.

Are there any other intended use cases that are currently known?

I'm not confident that picking a timer for invites is going to be successful. Like the (arbitrary) 1 day cache on this proposal, it risks keeping data for too long, well after the invite is accepted and processed.

Previously QR code login used a similar media-based system, but has since changed. It also wouldn't work best if time bound.

Ok, fair enough. Was just thinking that it might be an easy solution for the cache lifetime problem. But I see your reasoning.

I'm 100% with @Johennes on this. A lifetime specified at upload time is:

• easier to implement
• guarantees expiry (whereas we can't guarantee the client will hit DELETE)

The use case in MSC4268 is indeed time-limited due to things like "how long after having accepted an invite will you try to access the key bundle" which is being set to ~1 day in the rust SDK. The key bundle is encrypted, so there isn't a pressing need to delete it NOWNOWNOW as soon as it is no longer needed. I'd rather have guaranteed deletion and have to hold onto the data for a bit longer than potentially having to hold onto the data forever if the client doesn't hit DELETE.

Guaranteed deletion is not easier to implement: it requires actually sending out deletion requests to servers/users who may have downloaded it. Other proposals offer that functionality.

Servers can also just delete ephemeral media at will, with or without client interaction. It's ephemeral, so it should be safe to purge. I'm not sure this is part of the proposal right now, but it should be.

I feel a stronger use case is needed to change this proposal to use a timestamp.

Guaranteed deletion is not easier to implement: it requires actually sending out deletion requests to servers/users who may have downloaded it.

Why would you though? If it's lifetime-based, you can simply share the expiry timestamp, and therefore don't need to send any deletion request to other servers or even users. Yes, faulty clients/servers will potentially not delete it, but that's unavoidable. We only care about the compliant scenario.

Servers can also just delete ephemeral media at will, with or without client interaction. It's ephemeral, so it should be safe to purge.

But it's not safe to purge if it's a key bundle? It's unsafe to purge, but we may want to reserve the right to do that anyway more like?

I feel a stronger use case is needed to change this proposal to use a timestamp.

I feel there needs to be stronger justification for a manual DELETE, particularly given both @Johennes and myself feel that for the MSC4268 use case an expiry time suffices.

We can also say the earliest a server can delete something is a day after upload, to match the (currently arbitrary) 1 day cache.

Aside from missing a strong use case, this proposal also just hasn't been open long enough to warrant a shift in how it works. Ideally, it gets implemented first to see how it works in practice. Or, it doesn't get implemented, which is effectively a downvote for the MSC.

..or we just make the media ID the hash of the media and don't have to worry about this? This is content-based addressing effectively.

That causes conflicts with several other media-related changes. Namely, anything which needs multiple owners, like events.