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.
Râu Cao /
npub1rau…dees
2024-06-17 12:29:06
in reply to nevent1q…26dc
Author Public Key
npub1raustrrh5gjwt03zdj8syn9vmt2dwsv9t467m8c3gua636uxu89svgdeesPublished at
2024-06-17 12:29:06Event JSON
{
"id": "1951df8b25419468064b97591da784125ee926398a287064257dc90d189e185e",
"pubkey": "1f79058c77a224e5be226c8f024cacdad4d741855d75ed9f11473ba8eb86e1cb",
"created_at": 1718620146,
"kind": 1,
"tags": [
[
"e",
"0076f1ebf2717661241fc7f6f4431bca2065ce0da1f1671f84e830579b229ce5",
"",
"root"
],
[
"e",
"605fa8bbcfd18cabcadf9751c0ef8ef55c75ff8c639fc43fbd8d212c04b0fe0a",
"wss://nos.lol/",
"reply"
],
[
"p",
"3356de61b39647931ce8b2140b2bab837e0810c0ef515bbe92de0248040b8bdd",
"",
"mention"
],
[
"p",
"e6a9a4f853e4b1d426eb44d0c5db09fdc415ce513e664118f46f5ffbea304cbc",
"",
"mention"
],
[
"p",
"6e75f7972397ca3295e0f4ca0fbc6eb9cc79be85bafdd56bd378220ca8eee74e",
"",
"mention"
]
],
"content": "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.\n\nFirst 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).\n\nBut 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.\n\nThen 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.\n\nI'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.",
"sig": "b34f6cae0a7579c18a8db83a30315045d643e88f27a3386e35a3525a0ba4696b16c2bdccb8057c507d304dbfad4d1818eaf1b6d98157fa1e60627ef4f6116907"
}