Regarding 1. Why another protocol ? P2P file sharing exist since a long time and are battle tested.
Discussion
Having some example of a kind of workflow like : I chose a file to share in my client. The client creates a magnet link to be shared through nip-94, seeds the file, and users that want to access the file retrieve it thanks to the magnet url and an embedded torrent client.
Am I missing something obvious here ?
There would be an obvious question of the data persistence - e.g : how long should I seed - but nothing that seems to be a huge impediment to me
Which p2p protocol is battle tested ?
Torrent is not web ready.
Webtorrent is not battle tested.
Ipfs does not work at scale.
Torrent protocol is battle tested. And who said it had to be web ready ? Why should this be a constraint ?
That's all about use case.
Torrent: open your favorite torrent app on your desktop, you download and seed some content.
Nostr. You open your favorite webapp or mobile client, you publish some meme and finally close the app.
The Nostr client would embed the torrent client.
This is a common practice with the protocol in some apps. e.g: Steam uses bittorrent for application/update downloads.
Up to the client to handle the seeding and the rules to apply ( service workers to keep seeding in the background for X time even if user is not on the app actively ).
The idea is that this way the files content wouldn't be in the nostr protocol and it wouldn't require additional protocol design. It'd be up to the client to handle the content retrieval, sharing, caching, etc.
Obviously there should be a way for user to fine-tune the behavior of the client regarding the torrent client, but i see this as another matter