fiatjaf (npub180c…h6w6) #asknostr #bloossom #ipfs
I think there is a way IPFS could be implemented as a second option to recover the same file if it's on both Bloom servers and IPFS.
A file has a sha256 and a unique CID, if both the name and the file structure are always the same when uploaded on NOSTR clients.
If a file is uploaded to servers first, the sha will be obtained first and then the CID would be obtained in case the user also decides to upload their files via IPFS to be able to recover them from that network.
A detail I noticed is that if the servers compress the file before uploading it, then the sha256 of the original file and its CID will no longer be the same, so if the file is later passed to IPFS, the file would have to be kept with the same structure and the same name so that both its sha256 and its CID are always the same in case the user decides to change servers in the future and make links from posts from years ago keep working thanks to always being able to have on a server a file with the same sha and the same CID.
If the file is uploaded to IPFS first, it would already have a fixed CID and sha256, trying to compress the file afterwards for Bloom servers would cause both its CID and its sha256 to no longer be the same, so now there would be 2 identical files but with different IDs, so the NOSTR client would no longer be able to recover it from IPFS because its CID doesn't match the original file.
translator_nbot
npub1gf…g6n2l
2026-10-09 03:38:20 UTC
in reply to nevent1q…chlp
Author Public Key
npub1gf0gw2cznxdaxu93shtxftm635h52vk92pk79n99sny7u0fkfx4qmg6n2lPublished at
2026-10-09 03:38:20 UTCEvent JSON
{
"id": "7e7ed591143e92f3b5a3abb0cd5218867d70f13d1151f07b7a943fefbfe0d7ed",
"pubkey": "425e872b02999bd370b185d664af7a8d2f4532c5506de2cca584c9ee3d3649aa",
"created_at": 1791517100,
"kind": 1,
"tags": [
[
"p",
"3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"
],
[
"e",
"c02198a30a30e25203f7b1d8dd57f40b8f562abff42795998fc97a379654dfef",
"wss://spatia-arcana.com/inbox",
"root"
],
[
"e",
"9c6012fca9692129094c860d1e868572443c13dadf1aee6dffb68998e56af720",
"wss://basspistol.org/inbox",
"reply",
"3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"
],
[
"p",
"654008356e5ab2216efd3462559d56f2cab3d1d13a7d68322cbac62b13ba13ee"
]
],
"content": "nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 #asknostr #bloossom #ipfs\n\nI think there is a way IPFS could be implemented as a second option to recover the same file if it's on both Bloom servers and IPFS.\n\nA file has a sha256 and a unique CID, if both the name and the file structure are always the same when uploaded on NOSTR clients.\n\nIf a file is uploaded to servers first, the sha will be obtained first and then the CID would be obtained in case the user also decides to upload their files via IPFS to be able to recover them from that network.\n\nA detail I noticed is that if the servers compress the file before uploading it, then the sha256 of the original file and its CID will no longer be the same, so if the file is later passed to IPFS, the file would have to be kept with the same structure and the same name so that both its sha256 and its CID are always the same in case the user decides to change servers in the future and make links from posts from years ago keep working thanks to always being able to have on a server a file with the same sha and the same CID.\n\nIf the file is uploaded to IPFS first, it would already have a fixed CID and sha256, trying to compress the file afterwards for Bloom servers would cause both its CID and its sha256 to no longer be the same, so now there would be 2 identical files but with different IDs, so the NOSTR client would no longer be able to recover it from IPFS because its CID doesn't match the original file.",
"sig": "215bb60c9d302e24c3c71f47a42d822b6f2af5181a6b0aabb9f9162cdaa559cd30b4cd9195726d2120e2ec6d0453feb86e29567f04f11655f57200ab42555590"
}