Replies (20)
cc:
@Ryan hope this isnt just imagination now.
Yeah this doesn't look like at all what I was talking about. I was talking about something that would be more for video sharing and streaming, and would enable scaling once more users were watching and hosting copies of the files themselves. This is more like a Nostr based wormhole. Cool though.
But it can enable streaming video sharing, faster than torrents. This is more than a nostr based wormhole, this is like.a cross between Napster and torrents, since you can advertise your files to the network. Kind of like a public seedbox.
You'll see once the UI is up ๐
How does it handle multiple sources?
It doesn't yet, but it can theoretically by hashing the file and indexing the hash.
That will be necessary for video. A sizable video going viral shared from a home connection would quickly cripple the host. You'll need a way to pull chunks from various hosts and assemble them in the client. This is how torrents work, dividing the file into chunks, and hashing the chunks. Then clients can request the needed pieces from any host on demand.
Yes, just told you how it could work.. will get to it in time, I have other work too, im trying my best here ๐คฃ
I'm not sure I understand though, "hash it and index it" is pretty vague.
Say I host a video from my PC. Someone else views it, through a web Interface I'm assuming. What happens on the viewer's end to duplicate the file and contribute to the swarm? Is it automatic, or do they have to download and mirror the file manually?
So when the uploader uploads it the client can hash the file and use a nostr index like h while advertising so that we can search for it with nostr filters.
When someone is viewing a file we can search the network for who else has the same file, and even request for specific chunks from other peers. We're already chunking files in the PoC but its a little finicky.
So the viewer themselves doesn't become part of the swarm? If so that's a missed opportunity for quickly scaling the number of available sources.
Lots of work happening in this vein right now. This from
@Enki looks promising too.

Sovbit Git
torrent-gateway
A comprehensive unified content distribution system that seamlessly integrates BitTorrent protocol, WebSeed technology, DHT peer discovery, built-i...
That can happen too if we also hash chunks and broadcast them, and the viewer accepts that they would be rebroadcasting.
The protocol is simple the client side back breaking work is what will be required to do all this.
It can be the best idea ever, but if no clients integrate it doesn't matter. Even if only *some* major clients don't integrate it's probably a lost cause, because people won't use it due to lower reach. This happens often with Amethyst building in features, but damus & primal are nowhere to be seen.
I wish you luck though.
Thats how protocols work also thats what I like about the spec I've proposed here it can go from something as simple as a wormhole over nostr to a full blown torrent replacement. The clients can chose the complexity they wish to implement. TBH im just going to spec it out and only build out the parts I need for formstr.
The rest I may or may not build upon when I have time.
But the rest is here, waiting to be built upon, if someone wishes to continue.
I know my fair share about clients not adopting my useful specs (polls) ๐คฃ
So now I only build stuff that would atleast be useful for me regardless of other clients adopting it.
Christ, that code is so old. I need to actually commit something again.
๐คฃ

I think
@hzrd149 wanted to do something like this, forever, but somehow he just couldn't get around to it. Perhaps too much complexity, for little gain
If both peers are behind NATs you WOULD need a TURN server. Thats the only way as we understand it, one upgrade that could be done is to fallback to the ToR network if a direct route cannot be established, but that would suck for bandwidth