Replying to Avatar Stuart Bowman

> it reads like media relaying since it doesn't address longevity of storage. Or does it?

It does! In fact longevity/resilience was one of the primary considerations for this design. Any host can store media files which are identified by hash and served from a cdn over http, or if clients cannot find any host that has the media they can try to pull it from other peers (hence the choice of infohash). It only takes one person seeding the content for it to remain available.

> For the choice of infohash (sha1) - why not sha256?

The majority of installed bittorrent clients only support sha1, and for the fallback p2p option to work there must to be seeders. It's true that the torrent infohash is a bit clunky since it has to follow the BitTorrent v1 spec, but the gains in backward compatibility are worth it I think. And this limitation is mitigated/obviated by that fact that our proposal allows for multiple hashes. If you wanted to add support for IPFS, or any other hash, you could absolutely do that by just adding another "i" tag to and labeling it in a way that clients recognize, and we are actually planning to enumerate a few popular alternatives in the NIP. In any case, what makes the torrent infohash special (and why is was our default choice) is the ability to not only be an integrity check but that it also provides a means to actually "get" the data in a p2p way without reinventing the infrastructure that exists for doing so.

> We can expect to live in a world of deep fakes soon, so I would also consider pgp signatures instead of pure integrity hashing

Well that's the whole point of having the user sign the metadata (including integrity hashes) of the file. The metadata goes to the relays and the blob goes to the host(s). If hosts don't have the file you can load it as a torrent in your browser via WebTorrent (which is already integrated into some clients)

PGP integration would be really cool (again, backwards compatibility ftw) but I wonder if it makes sense to do that in a more general way, perhaps as part of the key delegation concept that is already addressed by other NIPs. Lot's to think about. Thanks for your feedback.

Who pays the storage cost?

or does that matter since your spec allows for some future post-ipfs type tech?

Reply to this note

Please Login to reply.

Discussion

This will create a market for storage and delivery of media. The p2p fallback option (loading the media as a torrent, or from IPFS/something else) is always there, but I imagine most use cases would benefit from a CDN if nostr is going to compete against the UX of centralized apps. I like the idea of having a fast CDN to serve media (and possibly provided a revenue model for apps the want to act as paid media hosts) while also keeping copies of the signed torrent metadata on relays as an anti-censorship mechanism, and to prevent lock-in to any particular media host.

On the last point (preventing lock-in) I should add that this why media hosts ought to server files at a standardized pathname, e.g. `media.satellite.earth/` so that one host ever stops hosting that file it can be "repopulated" on other CDNs and the client just needs to know to swap out the endpoint to get the file from `/`. I figured I should put together a working implementation of this before drafting the NIP to test these assumptions and hopefully shake out any other issues that I hadn't considered.

#[6] will pay 1/88888888th of all storage costs