fiatjaf (npub180c…h6w6) #asknostr #bloossom #ipfs
creo que si ahi una forma en que se podria implementar IPFS como una segunda opcion para recuperar el mismo archivo si esta tanto en servidores bloossom como en IPFS.
un archivo tiene un sha256 y un CID unico, si tanto el nombre como la estructura del archivo siempre es la misma al cargarse en los clientes NOSTR.
si un archivo se sube primero a servidores, se obtendra primero el sha y despues se obtendria el CID por si el usuario tambien decide subir sus archivos por IPFS para poder recuperarlos de esa red.
un detalle que note, es que si los servidores comprimen el archivo antes de subirlo, entonces el sha256 del archivo original y su CID ya no seran los mismos, por lo que si se pasa el archivo luego a IPFS, se tendria que mantener el archivo con la misma estructura y el mismo nombre para que tanto su sha256 como su CID siempre sean los mismos por si el usuario decide cambiar de servidores en el futuro y hacer que enlaces de publicaciones de hace años sigan funcionando gracias a que siempre se logra tener en un servidor un archivo con el mismo sha y el mismo CID.
si el archivo se sube primero a IPFS, este ya tendria un CID y un sha256 fijo, intentar comprimir luego el archivo para servidores bloossom provocaria que tanto su CID como su sha256 ya no sean los mismos por lo que ahora se tendrian 2 archivos iguales pero con ID distintas, por lo que el cliente NOSTR ya no podria recuperarlo de IPFS porque su CID no encaja con el archivo original
The_Crin
npub1v4…ec9al
2026-10-09 03:23:53 UTC
Author Public Key
npub1v4qqsdtwt2ezzmhax339t82k7t9t85w38f7ksv3vhtrzkya6z0hq4ec9alSeen on
wss://relay.ditto.pubPublished at
2026-10-09 03:23:53 UTCEvent JSON
{
"id": "c02198a30a30e25203f7b1d8dd57f40b8f562abff42795998fc97a379654dfef",
"pubkey": "654008356e5ab2216efd3462559d56f2cab3d1d13a7d68322cbac62b13ba13ee",
"created_at": 1791516233,
"kind": 1,
"tags": [
[
"t",
"asknostr"
],
[
"t",
"bloossom"
],
[
"t",
"ipfs"
],
[
"p",
"3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"
]
],
"content": "nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 #asknostr #bloossom #ipfs \n\ncreo que si ahi una forma en que se podria implementar IPFS como una segunda opcion para recuperar el mismo archivo si esta tanto en servidores bloossom como en IPFS.\n\nun archivo tiene un sha256 y un CID unico, si tanto el nombre como la estructura del archivo siempre es la misma al cargarse en los clientes NOSTR.\n\nsi un archivo se sube primero a servidores, se obtendra primero el sha y despues se obtendria el CID por si el usuario tambien decide subir sus archivos por IPFS para poder recuperarlos de esa red.\n\nun detalle que note, es que si los servidores comprimen el archivo antes de subirlo, entonces el sha256 del archivo original y su CID ya no seran los mismos, por lo que si se pasa el archivo luego a IPFS, se tendria que mantener el archivo con la misma estructura y el mismo nombre para que tanto su sha256 como su CID siempre sean los mismos por si el usuario decide cambiar de servidores en el futuro y hacer que enlaces de publicaciones de hace años sigan funcionando gracias a que siempre se logra tener en un servidor un archivo con el mismo sha y el mismo CID.\n\nsi el archivo se sube primero a IPFS, este ya tendria un CID y un sha256 fijo, intentar comprimir luego el archivo para servidores bloossom provocaria que tanto su CID como su sha256 ya no sean los mismos por lo que ahora se tendrian 2 archivos iguales pero con ID distintas, por lo que el cliente NOSTR ya no podria recuperarlo de IPFS porque su CID no encaja con el archivo original",
"sig": "fe7d58e61ac17e6a58d3bf2c997500998fc91b2c9de16206c024641eea4e4086b31a408941e2530ac6382cc357f8a6037d526c0a518e4a66616b7ee5dc8c4b56"
}