Me and #[2]​ are still hard at work hammering out a few technical details of the nostr-torrent idea presented at the hackathon last week.

https://github.com/lovvtide/nostr-torrent/issues

If anyone wants to jump in, please do so! Will publish a draft NIP soon.

I’ll volunteer

Great, thanks!

😂 That's actually a pretty good metric

Building stuff for nostr is the most fun I've ever had coding anything

Fed is fixing to pivot I think

Hi, is there a form for submitting new projects? I was hoping to get Satellite ( https://satellite.earth ) added to the list of web clients

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.

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.

I'm planning to deploy my implementation for Satellite next week

You should add Satellite https://satellite.earth :)

> 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.

I can't describe it, but I know it when I feel it. . . experience that doesn't fit inside a language model?

I'm really happy to see Apple doing this. I'd assumed they were incentivized to move slowly with support for mobile web because of how much money they make from native apps, but maybe this indicates acceptance/hedging for web-first as the future. Hopeful🤞

What???! That's awesome!

Very good point

Emotional skills

Wow

Stepping off the plane after a week in the jungle.

Is reverse culture shock a thing?

Open an issue on the repo