#ipfs + #nostr
Una muestra de como funciona mi cliente NOSTR con un nodo ipfs.
El cliebte analiza los links que uno pasa el evento, revisa si es un enlace ipfs y si el enlace tiene un cid junto al nombre del archivo, el cid revisa si es v0 o v1, si es v0 lo intenta trabsformar en v1, pero si el cid empieza por bafk... No se podra convertir a v1, agregar el nombre junto al formato es importante para que el cliente sepa que ripo de archivo es.
Para mostrar los archivos, lo que el cliente hace es usar la puerta de enlace local del nodo ipfs que esta en localhost: 8080, asi no se tiene que depender completamente de puerta de enlace de terceros porque ahora uno mismo puede recuperar los archivps de su nodo.
Lo que descubri, es que si el misno archivo si se mantiene intacto tanto en ipfs como en servidores bloossom, tabto el nombre como su esttuctura, sienpre generaran el mismo hash y el misno cid, por lo qie si el archivo se elimina de un lado, se podria reponer del otro y si se recupera de ipfs, se puede resubir a servidores manteniendo el mismo hash que estaba en enlaces antiguos.
The_Crin
npub1v4…ec9al
2026-10-28 00:17:43 UTC
Author Public Key
npub1v4qqsdtwt2ezzmhax339t82k7t9t85w38f7ksv3vhtrzkya6z0hq4ec9alPublished at
2026-10-28 00:17:43 UTCEvent JSON
{
"id": "6518dc0e4c3df793341e9057f043a6b8f6362b207dcd431b599ce55962694f11",
"pubkey": "654008356e5ab2216efd3462559d56f2cab3d1d13a7d68322cbac62b13ba13ee",
"created_at": 1793146663,
"kind": 1,
"tags": [
[
"t",
"ipfs"
],
[
"t",
"nostr"
],
[
"r",
"https://nostr.download/007a2a0b07a1df23134995269ecd7835337e6bfc92ffbbf2b978f2a718ef7f3b.mp4"
],
[
"r",
"https://bafybeicwvdr3yk2l5g6sha65curm4if5uwxlqa7myopwz5jnautc4dfxg4.ipfs.dweb.link/?filename=sin_ipfs_con_ipfs.mp4"
],
[
"imeta",
"url https://nostr.download/007a2a0b07a1df23134995269ecd7835337e6bfc92ffbbf2b978f2a718ef7f3b.mp4",
"x 007a2a0b07a1df23134995269ecd7835337e6bfc92ffbbf2b978f2a718ef7f3b",
"size 2220314",
"m video/mp4; codecs=\"avc1\"",
"dim 1918x854",
"blurhash ZMQ9D,AD?bWBg%wbpdxZ%hu4XTVYRPx]n3x^xuof00WB~qxax]%2ROkDVs^PtSD%RjkqRjoft7Rj",
"ox 007a2a0b07a1df23134995269ecd7835337e6bfc92ffbbf2b978f2a718ef7f3b",
"alt Ejemplo"
],
[
"client",
"Amethyst"
]
],
"content": "#ipfs + #nostr\nUna muestra de como funciona mi cliente NOSTR con un nodo ipfs.\n\nEl cliebte analiza los links que uno pasa el evento, revisa si es un enlace ipfs y si el enlace tiene un cid junto al nombre del archivo, el cid revisa si es v0 o v1, si es v0 lo intenta trabsformar en v1, pero si el cid empieza por bafk... No se podra convertir a v1, agregar el nombre junto al formato es importante para que el cliente sepa que ripo de archivo es.\n\n\nhttps://nostr.download/007a2a0b07a1df23134995269ecd7835337e6bfc92ffbbf2b978f2a718ef7f3b.mp4\n\nhttps://bafybeicwvdr3yk2l5g6sha65curm4if5uwxlqa7myopwz5jnautc4dfxg4.ipfs.dweb.link?filename=sin_ipfs_con_ipfs.mp4\n\nPara mostrar los archivos, lo que el cliente hace es usar la puerta de enlace local del nodo ipfs que esta en localhost: 8080, asi no se tiene que depender completamente de puerta de enlace de terceros porque ahora uno mismo puede recuperar los archivps de su nodo.\n\nLo que descubri, es que si el misno archivo si se mantiene intacto tanto en ipfs como en servidores bloossom, tabto el nombre como su esttuctura, sienpre generaran el mismo hash y el misno cid, por lo qie si el archivo se elimina de un lado, se podria reponer del otro y si se recupera de ipfs, se puede resubir a servidores manteniendo el mismo hash que estaba en enlaces antiguos.",
"sig": "84acbdf5f75b9a1da01f8ee7490af260dae4123252b65292cf7f10a9d5e3959074de5b2fc9894b975921de6f2c9454efc4ba2f20003f4e34476854b7e2d30ae4"
}