Add webtorrent:// protocol handler

[feross]

Moved into it's own issue from #54 (comment)...

Since torrent streaming isn't supported by most popular torrent managers; developers and websites could make an integration for this without requiring users to rethink their default torrent configurations.

Websites that share torrent files generally have links such as 'Download Torrent' and 'Open Magnet'. Imagine an extra link saying 'Stream Torrent'. That's what I'd like to see.

Bonus suggestion: decide on a general torrent streaming protocol (i.e. str://<magnet>) with https://github.com/jaruba/PowderPlayer so that developers can simply add 'Stream Torrent` links that support any torrent app with the protocol!

[giuscri]

+1

[ungoldman]

Here's some info on that: electron/packager#59

See also @jden's https://www.npmjs.com/package/register-protocol-handler (currently win32 only)

[junosuarez]

Thanks for the mention, @ungoldman - disclaimer, that was kind of experimental and I don't know if it's actually being used anywhere currently, ymmv.
Electron does something that I think works crossplatform for this

[Flet]

Probably http://electron.atom.io/docs/api/protocol/ ?

[ungoldman]

Looks like the github issue had better google juice than the atom docs, thanks for finding that Flet! That looks a lot more up to date.

[feross]

@jden @Flet @ungoldman The protocol module only works for the URL requests inside Electron. There are OS-specific ways to make this work. Here's how I did it for OS X: https://github.com/feross/webtorrent-app/pull/164/files#diff-9109eccc4c03527f26f8ead0327367e8R175

[feross]

Opened an issue to ask Electron to make this easier: electron/electron#4857

[feross]

@jden Your module is nice and simple, but it has a native dependency to link to the .NET API, and it fails to install on non-Windows platforms, obviously.

I'm going to try using winreg to modify the registry. I've used this package before for webtorrent-cli, to locate the path to launch VLC. winreg is great because it just calls out to the REG command line program with child_process, so it's pure JavaScript. No native deps.

[feross]

@jden Okay, here's the approach I went with: https://github.com/feross/webtorrent-app/blob/2b555e12b868b0610838e55f98a0b1d6705f49d6/main/register-protocol-handler.js#L7-L46

What do you think? If you're down, we can replace your package register-protocol-handler-windows with this approach and then WebTorrent.app can depend on it.

If not, that's fine too. I can just publish this as a separate package.

[junosuarez]

@feross oh, nice, I was unaware of the pure registry solution. Thanks for linking to the msdn article in the comments! I'd happily take this as a patch to register-protocol-handler-windows.

[jaruba]

@feross @iadj

Bonus suggestion: decide on a general torrent streaming protocol (i.e. str://) with https://github.com/jaruba/PowderPlayer so that developers can simply add 'Stream Torrent` links that support any torrent app with the protocol!

The way google brought me here from a totally unrelated search is above my comprehension.. So? Are we making a new standard protocol for streaming torrents? (we can't name it webtorrent:// though.. lol)

Should probably include https://github.com/mafintosh/playback in our world domination plans too.

[bnjmnt4n]

Playback currently uses playback://<magnet-link>.

[jaruba]

@demoneaux and I have pow://, a default protocol for streaming makes sense, what we're doing by each having our own custom protocol, doesn't..

[jaruba]

Imagine if there was utorrent:, qbittorrent:, transmission:, and so on, instead of all using magnet: :)

Someone's gotta make sense of this mess at one point, creating a default protocol for streaming torrents is the proper way of doing things.

[feross]

I see value in our app-specific protocol handlers (webtorrent:, playback:, etc.) for some situations. For example, if I want to post links to a GitHub issue that open up in WebTorrent Desktop.

So, the real question is -- do we need a new protocol handler specifically for streamable torrents? We already have magnet: for generic torrents. Is it sufficient to just take over magnet:? Or are there a significant number of users who want two torrent clients, one for normal torrents and another for streaming torrents?

[jaruba]

From my experience, I've seen many that prefer using uTorrent in combination with a streamer. And some users get frustrated as you can only match magnet: to one handler.

Whether or not a new standard protocol handler just for streaming will be embraced by web developers is the real question here. But that should not be our concern, as giving it as an option to developers can only be a good thing.

[feross]

Some options:

• stream-magnet
• magnet-stream
• stream
• play-magnet
• magnet-play

[jaruba]

i like play-magnet: :)

stream: is too general

[feross]

Another option:

• magnet-play

Has the advantage of starting with magnet- so it will look like a magnet link to users.

[feross]

Upvote this comment if you prefer stream-magnet.

[feross]

Upvote this comment if you prefer magnet-stream.

[feross]

Upvote this comment if you prefer play-magnet.

[feross]

Upvote this comment if you prefer magnet-play.

[feross]

@jaruba Are there other developers of (legitimate) torrent streaming apps who we can ask for their opinion?

Hey @mafintosh, @freeall (Playback devs) -- do you have thoughts on this?

[jaruba]

@feross

Are there other developers of (legitimate) torrent streaming apps who we can ask for their opinion?

Maybe @Ivshti with Stremio.. If we don't include the Popcorn Time forks and friends.

I can pipe more developers into this effort as they come at WebChimera.js as I'm one of the maintainers there, but until now.. I've only seen players for local media / live streams and Popcorn Time alternative starters.

[freeall]

@feross I like api's that uses names as it makes it easier to understand and debug - as an example it's easier to read and understand github.com/feross than github.com/5234 (or whatever your user id might be).

Btw, stream+magnet sounds good

[jaruba]

@feross

I'm fine with stream+magnet, as for ix being short for index, I'd rather use idx, but I get why you'd want to keep it 2 letter like the rest, so how about at=5?

[anonymlol]

How about id instead of ix for index? Or nr for file number.

edit: I'm fine with stream+magnet, too.

[jaruba]

@anonymlol id would be confusing, as it's short for identifier, not index

[dcposch]

Done
#640

Shipped in v0.8.1

[JohnDoee]

@dcposch How is this done ?

It's called stream-magnet, was that the final choice ?
Also, where's index support ?

[feross]

Re-opening this issue as we still haven't implemented support for the ix property.

[feross]

@JohnDoee Yep, the final name we settled on was stream-magnet. It shipped in WebTorrent Desktop 0.8.1. Changelog here: https://github.com/feross/webtorrent-desktop/releases/tag/v0.8.1

[jbenet]

I was summoned here months ago. Sorry my intertubes were clogged.

In general, when referencing ipfs protocols, pls use unix path notation
(/ipfs/...) and pretend the prefix fs: if you absolutely need a
standard URI.

In this case (just from above) I think it's possible to make
stream-magnet:/ipfs/... work, but I haven't had a chance to look at it in
detail, sorry.

Either way, exciting stuff! :)
On Wed, Jul 27, 2016 at 00:59 Feross Aboukhadijeh notifications@github.com
wrote:

@JohnDoee https://github.com/JohnDoee Yep, the final name we settled on
was stream-magnet. It shipped in WebTorrent Desktop 0.8.1.
https://github.com/feross/webtorrent-desktop/releases/tag/v0.8.1

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#83 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIcoTZIRsJm2i9zbOw7k1gh6SZ0gkKYks5qZuXAgaJpZM4HrfuY
.

[Raulvo]

I am interested in support for Ace Stream. I have tried to put the hash in acestream:// URLs in a magnet link format but WebTorrent did not download anything.

[feross]

@Raulvo Please open a new issue. You posted in an old, unrelated issue.

[Daniel-Abrecht]

we still haven't implemented support for the ix property

I'm for using so= instead, as described in the draft rfc here:
http://www.bittorrent.org/beps/bep_0053.html

Also, maybe this should be part of webtorrent instead of webtorrent-desktop?

And I think a possibility to specify a file by path would also be quiet handy.

[feross]

@Daniel-Abrecht Oh, nice. This draft looks new. Let's support it and consider removing ix support: webtorrent/webtorrent#1395

[github-actions]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?