Have you ever tried to use IPFS? It only ever works when you publish a file directly to the Cloudflare instance and then fetch directly from it via HTTP bypassing the actual software and p2p network.
I wrote nostr:naddr1qqyxgdfsxvck2dtzqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8y87ll a long time ago and haven't reread it since, so it's probably garbage. Search Nostr for "IPFS" and you'll probably find better content.
Got it, thanks. I'll give it a read and do some more practical research. I admit that I've played with impressive demos and not much else.
But I think I’ve sidetracked the post by even mentioning IPFS. My main idea was to implement Nostr Notes + Blossom media sync through torrents. Have, say, Khatru/Haven expose a torrent with a file structure similar to what you did for nak/FUSE, plus all my Blossom blobs. I can then expose a magnet link with a BEP-39 update URL.
We could even have a specific event on Nostr for folks to discover my Nostr/Blossom content index URL. For lack of a better name, let's call it master outbox. Anybody else can use this torrent to sync and seed my notes and media.
This doesn’t need to be a massive centralised index like Bluesky. Instead, each user publishes their content to whatever relay they want, chooses one as their current master outbox, and other relays and even clients (through WebTorrent) can perform full or partial syncs using the torrent/magnet link. Wouldn't this be useful at all? Sure Negentropy can be used for more complex gathering of notes spread across relays. But for simple sync it feels like this would be an efficient way of doing things.
there is a reddit and 4chan like social media protocol on ipfs, its a bit more wild west. it uses pubsubs.
but its nothing like nostr, nostr is more profile based, and a lot more closer to regular social media. just better in general.
and ipfs problematic when you share something alone from your own node, it takes a long while for others to discover it. but sometimes it also works fast, just like that.
i think one problem with nostr right now is all media is just http links to a cdn.
they are not distributed, and link have nothing to do with the content, makes it impossible to verify. so i think sharing a hash instead of some random centralized id makes more sense. and we already have ipfs hash and uri. so if we shared ipfs uri instead of http url i think it would just work.
like relay lists, we can also have ipfs api and gateway lists. clients can ask all of the gateways for the content until finding it at one. ipfs gateways allow HEAD requests, so you can know if the content exists and its size before fetching it.
you can easily backup/pin your own content on another gateway you pay for as well if you want to.
main thing is its hash based, and distributed.
right now if i post a media on primal, they will host it via their cdn, and all of the other nostr clients will fetch it from a url to that cdn. cdn can censor, remove the content, and in the future even cdn itself can shutdown. there is no way to access that content other than that cdn. but and ipfs uri is hash based, so anyone can host if for you. if the content is lost, you can verify it again once you find it, etc. primal can just host an ipfs gateway instead of a regular cdn.
i know not many clients support ipfs, or have a list of ipfs gateways to use. but what you can do is share an a gateway https url, and anyone can still parse, it and say that "its an ipfs url".
ipfs url formats are known, it can be in bafy subdomain type or bafy and Qm type with /ipfs/ pathname prefixes. you can extract the hash from there and try it on multiple gateways. and clients that doesn't support ipfs would still work, because its basically a https url to an ipfs gateway.
i plan on hosting one in the future for nostr, with my own client.
Sounds like a great application for IPFS! To be fair, Blossom blobs are hash based, and nostr:nprofile1qqszv6q4uryjzr06xfxxew34wwc5hmjfmfpqn229d72gfegsdn2q3fgpr3mhxue69uhhxct5v4kxc6t5v5hxs7njvscngwfwvdhk6tcpzfmhxue69uhkummnw3e82efwvdhk6tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsk7wj75 has also been asking around about "Negentropy." On top of that, if clients follow BUD-03 as intended, they should be able to recover the media from any of the servers in a user list: https://github.com/hzrd149/blossom/blob/master/buds/03.md
However, your idea of leveraging IPFS sounds very promising. The client wouldn’t need to implement fallback logic or fetch the media elsewhere, users wouldn’t have to carefully manage redundancy by mirroring blobs and managing multiple blossom servers, and a simple "just download and seed my stuff" approach is certainly a great way to do things.
I’d definitely like to try what you’re building (or planning to build) once it’s out there. And if it can be made Blossom-compatible, that would be even better. I know that despite both systems using SHA-256 hashes by default, they aren’t exactly compatible OOH. IPFS uses CID versioning, supports multiple ways of encoding hashes and even multiple hash algorithms. But given that IPFS has some flexibility built-in and Blossom is an emerging standard, I think there are ways to accommodate this.
didn't know about blossom before. looks promising.
i think where blossom is strong is its easier to implement in few hours. and more lightweight. more cdn like.
ipfs a bit more complex, but good side is, well-known gateways share content between each-other fast without something like /mirror.
if the hash were compatible/convertable it would have been great. then you can ask for the content on both blossom cdns and ipfs gateways. also blossom cdns can also seed the content on ipfs. and etc.
When I first started with Nostr back in 2023, IPFS sounded like a perfect match. But the more I played with it, the more convinced I became that IPFS is a broken and failed project. Nostr needs something simpler and more straightforward—and then nostr:nprofile1qqszv6q4uryjzr06xfxxew34wwc5hmjfmfpqn229d72gfegsdn2q3fgpr3mhxue69uhhxct5v4kxc6t5v5hxs7njvscngwfwvdhk6tcpzfmhxue69uhkummnw3e82efwvdhk6tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsk7wj75's Blossom came.
Ever since then, I've been dreaming about redundant decentralized storage with file fragmentation—something like what StorJ describes in their white paper:
"All data is encrypted and sharded using Reed Solomon erasure coding. The resulting pieces are distributed around the world. A typical large file is divided into 64 MB encrypted segments, and each encrypted segment is divided into 80 erasure-coded pieces—any 29 of these are sufficient to reconstruct the original file. Each of these 80 pieces is stored on a different drive globally, spread across diverse geographies, operators, power supplies, and networks."
In Blossom, this would be a killer feature. You would offer space on your server to others, and in exchange, get redundancy for your own files, or you would simply pay for it. File metadata could be published as a specific kind hosted by relays.
can you elaborate on IPFS brokenness? out of interest
I'm not op, but fiatjaf has posted this in one of the comments in this chain.
It is almost impossible to get content synced over the network. Try to sync a simple picture from your home node to a node in your laptop when you are on different networks... It will take hours or it will never happen.
I mean what I said was just getting content from well connected gateways anyway, or uploading to one, like nostr client providers can have their own default gateways and etc. i wasnt talking about p2p ipfs experience.
anyway I checked blossom, (first time hearing about it).
seems similar to what i was thinking with ipfs.
but instead its a cdn protocol basically, i think. didnt deep dive in it yet.
so i believe its like a normal cdn but hash based and has a known format, endpoints. so you can extract the hash (like i said in ipfs). and then check other blossom compatible cdns.
and of course user can give list of blossom cdns on their profile as well.
tbh blossom looks more lightweight and easier to implement for already existing cdn solutions. i see no problems with it.
seems like a more lightweight solution. i liked it.
i still see no problem with supporting both or more. similarly you can share a media with a https ipfs gateway URL, so it works everywhere.
and then while viewing extract the hash and check multiple other gateways with that hash as well using HEAD method.
which would also make those gateways search for the content. distributing the GET traffic more later when more users ask for same thing.
but yeah blossom looks nice, maybe better.
