Great stuff. I built a private Blossom to IPFS gateway (Khatru based, despite the fact that the framework author does not like IPFS). My main problem so far is that when my CDN evicts media, latency increases substantially, even when I am acting directly as an IPFS host and gateway. It also seems to be a bit more bandwidth hungry, which is not a big deal.
But aye, in terms of redistribution and redundancy it is ahead of Blossom, especially as most Blossom implementations out there take liberties with the specs and are not compatible with each other, nor even between clients. I totally gave up on BUD-04 mirroring, as client and Blossom server devs break compatibility faster than I can fix stuff on my side.
Login to reply
Replies (5)
Here is fix for you friend,
ipfs config --json Routing.Type dhtclient
bandwidth hungry - you are right, small part to pay for availability
last time i tried mirroring it was an rt on nostrudel it took a while, it was three videos, I don't think any other nostr clients have implemented it.
You’re always welcome to contribute 🙂
I’ve intentionally kept the code simple and the implementation as close to the raw IPFS spec as possible.

GitHub
GitHub - besoeasy/file-drop: A decentralized, open-source solution for sharing images, videos, and any other files.
A decentralized, open-source solution for sharing images, videos, and any other files. - besoeasy/file-drop
I think I did play with a direct DHT Client as well as a cache-in-between the Blossom server and a local HTTP to IPFS Gateway with some aggressive catching headers (which gave me the best results as when the CDN evicts media, more often than not the bridge hits the cache instead of IPFS), but I'll revisit it for sure. And also play with your stuff, as if IPFS is enough Blossom becomes unnecessary.
Primal did, but compatibility between Blossom servers is still a bit hit and miss as some fair play is required between clients and both servers involved.