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 nostr:nprofile1qqsyfhqu9kuu877hhm5j2lkwk5478nuvgza00d3lgmjkkk9px8r57zcprdmhxue69uhhg6r9vehhyetnwshxummnw3erztnrdakj7qgcwaehxw309ahx7um5wgh8xmmkvf5hgtngdaehgtcprfmhxue69uhkvun9v4kxz7fwwdhhvcnfwshxsmmnwshsdsn8sh looks promising too.

https://git.sovbit.dev/enki/torrent-gateway

Reply to this note

Please Login to reply.

Discussion

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.

🤣