PLEASE READ, SHARE, AND COMMENT:
(Apologies in advance for any misconceptions I may have about the current state of Nostr. I admit to not having kept up.)
## Problem:
Nostr has been an important step in the right direction for decentralized and uncensorable social media, and furthermore giving us cryptographic proofs of the authenticity of every post.
HOWEVER, all external information (photos, screenshots, PDFs, audio & video) contained in a post *exclusively* relies on the existing DNS system, HTTP protocol, AND a *single* server, making it highly vulnerable to loss of content through situations like data loss, host shutdown, deplatforming, or government seizure.
Or WORSE, *content replacement*, leading to propagation of false information under the guise of being cryptographically verified.
If Nostr is ever to be a reliable (AND uncensorable) protocol for ALL media, we need a mechanism to cryptographically secure all types of media.
## Proposed solution:
We already have a decentralized uncensorable content network, widely used and proven over several decades:
**Bittorrent**
How can we leverage this network to further make Nostr the future protocol for publishing content?
These are the steps I see that can bring us into the next phase of Nostr:
1. Enable support for Bittorrent magnet links in posts.
Today an embedded HTTP link (to e.g. an `.mp4`) will embed the video instead of showing the link. A magnet link contains a content hash that points to content in the Bittorrent network, and the `so` parameter identifies the exact file in that torrent, thus a client can display the linked file in a similar way. So, just like an HTTP link:
`https://i.imgur.com/v6dFs83.mp4`
we should be able to use an file-indexed magnet link:
`magnet:?xt=urn:btih:3cf3eae685739b4792fd150443eeeb93fd0a28d1&so=0`
and achieve immutable and persistent content references.
2. Torrent contruction and publishing.
Step 1 might be sufficient, but not very user friendly. Nostr clients can assists in creating a torrent from the media content the user wants to include, just like the clients today upload to a choice of HTTP servers. This can be done in-app, or through a simple web API, like a regular HTTP content server (see below for a POC).
3. Improve availibility and distribution.
The first step alone is an improvement because it solves the problem of forgery, a core feature of Bittorrent, through content hashing. But we can also solve availability by giving Nostr users the ability to help seed content they think is valuable and worth preserving. This is obviously a client UX choice, but a ❤️ could mean that you help seed the content. Or if that's too heavy handed, more likely a dedicated 🗃️ button for this would be preferred for more transparency and choice. Seeding *can* be done on mobile devices, but power users and content producers might want to offload that to dedicated seed box, thereby helping the network. Such a seed box could also serve as a Nostr relay.
4. Nostr content signing?
For step 2, we could sign the content with a Nostr key. I originally thought this would be a core feature of Bittorrent on Nostr. But upon further thought I think this has very limitied useability. Step 1 simply provides support for displaying content from torrents, and is a big win on its own, however it does not provide cryptographic proof that the content is from the same key that is embedding the content. This is clearly not needed nor desired in many cases, but is it desirable for other use cases? I'm not sure.
## Conclusion:
My hope is that one day this video will play in most Nostr clients:
magnet:?xt=urn:btih:439f914cf85da4a5975cef115634a108376fda8d&so=0
(Any mention of Bittorrent implicitly also infers Webtorrent)
Nostr clients will handle torrents.
If not as a destination of our uploaded media, then at least as source for things people want to share this way.
I was thinking about this yesterday.
20 years ago when Opera was just a cool browser, they integrated a bittorrent client into it. Downloads Page was both http and bittorrent.
It is such an obvious feature not commonly implemented in browsers it's shocking.
I think Webtorrent does this now, over WebRTC instead of UDP.
