OK, I understand what you're saying. However, inventing an unspec'd, poor man's version of a content-addressed filesystem by just saying "look there are hashes" is not exactly a satisfying solution to the problem.

First of all, and the biggest problem with this as of now: how would the files actually get anywhere else when lost? In almost all cases, they won't be stored with hash filenames on people's various devices that they used to post the media to begin with, even if they could theoretically find all missing source files (most people won't).

But there are other issues, like e.g. nostr.build using file extensions in the URLs, but not every service doing that. It also changes filename extensions by its own choosing.

Then there are cases like longer and high-res videos, where you don't want most clients to download a single 4K source file for example. You'd need a video-specific server and specs for this to solve it properly.

I'm not saying these (and other) problems cannot be solved. However, my initial reply was about content creators currently not being able to "publish content natively on nostr" when it comes to media files. And just looking at the current situation, that is just true either way, hash filenames or not. So there's no point in shaming people for linking media files from any HTTP URLs, regardless of the nature of the underlying service.