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)

Reply to this note

Please Login to reply.

Discussion

## Proof-of-concept:

Features 1-3 could be supported easily by a normal HTTP content server also running e.g. qBittorrent, using the proper setup and a few API calls.

However, I've created a POC server that integrates all 4 features, using as few API calls as necessary:

https://nostrrent.bulletproof.ninja/api/

I was told (by an LLM, lol) that using `backticks` should generally prevent Nostr clients from resolving a video link. I see now that this is not the case in the clients I've used 🤷🏻‍♂️

Looking for some Nostr tech savy feedback on this suggestion here. Is he on to something -and if so, could it be solved with a NIP that clients can then choose to implement? 🧐 💜

#asknostr #nostr

nostr:nevent1qvzqqqqqqypzqucdhnysjsalrp98zdgfr795dwwm5j70wv2dqkhaagq5qntzlrvkqqsqrsjfmtsvqupvnxuv3r7p8zgwtxyar0wa9a98d8nndujk5akh56sjgedca

👏👏

Are you familiar with blossom?

https://github.com/hzrd149/blossom

I am now. Thanks for the link 👍🏻

Looks very similar to Bittorrent. Do you know what the differences are, which BT deficiencies they are trying to solve?

Blossom is not peer2peer in the same sense as BT. It's basically treating binary data the same way nostr isntreating notes: we put them on servers, but it is trivial to mirror them on other servers and for clients to look them up. Smart as hell!

The note bellow of yours contain an image hosted on a blossom server. If that server was to go down, your peers clients could ask all the blossom servers it knows for the same file. That's why it is nice to setup multiple blossom destibations in your client. You can manage your blossom list using clients like amtehyst and others like bouquet allow you to manage your blossom media and ensure redundancy.

https://bouquet.slidestr.net/

Hope it helps!

nostr:nevent1qqsfahghn7qef2xzryd7epnylnj9glnrpt0gqwv63mcqwjw9v2qczzqppemhxue69uhkummn9ekx7mp0qgs8xrdueyy580ccffcn2zgl3drtnkayhnmnzng94l02q9qy6chcm9srqsqqqqqp2a6467

Right, but I'm linking directly to a server, `blossom.primal.net`. I assume that if they shut down, that image will no longer show up in my post, because I'm using `http` and not `blossom` links, is that correct?

i guess you found your answer in the other post :lovemega:

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.