Stuart Bowman on Nostr: > it reads like media relaying since it doesn't address longevity of storage. Or does ...
> 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.
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.