Webtorrent-desktop: Add webtorrent:// protocol handler

[feross]

_Moved into it's own issue from https://github.com/feross/webtorrent-app/issues/54#issuecomment-193571322..._

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: https://github.com/electron-userland/electron-packager/issues/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: https://github.com/atom/electron/issues/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.

[Ivshti]

Stremio is going to launch a web-based version without torrent streaming functionality (only YouTube and HLS-based add-ons initially), so a thing like this may partially enhance it by adding some support, but it has to be done elegantly.

What's the problem with magnet-stream or stream-magnet name ?

Should we restrict ourselves to BitTorrent though? What about IPFS?

[jaruba]

Uh, maybe @xaiki from Butter, as that is planned to be a torrent + general web media streamer too
_from what I know_

[jaruba]

@Ivshti

What's the problem with magnet-stream or stream-magnet name ?

None, if your asking for a personal perspective, it's longer and play just sounds better then stream :)

[jaruba]

@Ivshti

Should we restrict ourselves to BitTorrent though? What about IPFS?

It is difficult to move so many different projects twords supporting IPFS, if not all support it, then it can't be a standard use case for the protocol..

[xaiki]

i get what @lvshti is thinking: maybe it could be stream://magnet:${hash} and stream://ipfs:${hash} but that would require to decide if we can stream after the app as launched, so it's probably better to have stream-magnet:// and stream-ipfs://, that's why i think the stream-${protocol} naming is more elegant.

[Ivshti]

I'm sure Alexandria would like the notion of IPFS.

IPFS is like BitTorrent on steroids, so it makes sense for products/projects pushing _new content_ over a p2p protocol.

But this is another discussion, in general I agree with @xaiki on this "wrap" thing

[jaruba]

Interesting perspective, that makes sense.

@DevonJames (Alexandria) you should give your opinion too.

@RSATom is there anyone that you think might be interested in this protocol? AceStream or maybe even someone from VLC?

[luigiplr]

i get what @lvshti is thinking: maybe it could be stream://magnet:${hash} and stream://ipfs:${hash} but that would require to decide if we can stream after the app as launched, so it's probably better to have stream-magnet:// and stream-ipfs://, that's why i think the stream-${protocol} naming is more elegant.

I think @xaiki makes a solid argument for the stream-${protocol} naming; upvoted.

[jaruba]

indeed, _changed my vote_ :))

[DevonJames]

Thanks for the ping @jaruba
@Ivshti Alexandria is using IPFS currently, we love it

my vote is also @xaiki's suggestion: stream-${protocol}:${hash}

[feross]

I'm fine with stream-magnet:.

@DevonJames Note that magnet links are actually not followed by // like http urls. The full prefix is magnet:?xt=urn:btih:<hash>.

Our apps can be flexible in accepting input (if desired), but I think we should stick with the current way that magnet links are formatted in our examples and documentation, so we don't confuse web developers. So, this is what a link would look like:

stream-magnet:?xt=urn:btih:6a9759bffd5c0af65319979fb7832189f4f3c35d&dn=sintel.mp4&tr=...

Does that sound reasonable?

So the "spec" if we have one is basically: Everything is the same as magnet: except use stream-magnet: instead.

[DevonJames]

@feross good point, updated :)

perhaps some from the IPFS team have opinions? @jbenet, @mafintosh, @whyrusleeping

[Houwert]

@jaruba make up your mind women.

[xaiki]

So the "spec" if we have one is basically: Everything is the same as magnet: except use stream-magnet: instead.

all in, if we're going to publish this as a spec i guess we should pre-reserve names for future use:
stream-magnet: stream-torrent: stream-ipfs: stream-http: stream-hls: stream-rtmp: come to mind.

[DevonJames]

So the "spec" if we have one is basically: Everything is the same as magnet: except use stream-magnet: instead.

In that it would allow also stream-rtmp: and stream-ipfs:, yeah

[freeall]

@feross Just looked through this issue and after I read your first post I thought Good idea, but instead of 'str' couldn't it be 'stream-magnet'. So when that was suggested later I was down. I'm not going to bikeshed whether it should be stream-magnet or magnet-stream - both are fine.

I agree that it's not good for scaling if everyone started using their own like transmission/utorrent/etc.

[JohnDoee]

I actually implemented something similar to this and went with stream+ because it'd conflict with nothing. It's allowed and nobody is using +. Example.

Want to turn a normal url into a streamable url ? slap a stream+ in front. Let the middleware rewrite the url and figure out where it should be sent. This also makes it generic and easy to support new applications.

[jaruba]

@JohnDoee

[feross]

@JohnDoee Do you have a magnet link example for stream+magnet? I only want to add a new protocol handler for magnet links -- not torrent files, so it would be helpful to see how you're using that in the wild today.

I think it's not necessary to have a protocol handler for torrent files (stream+torrent) that just tells the client to go and get the torrent file over http at the beginning. That should just be a magnet link.

Magnet links already support a way to specify a torrent file at an http location. I don't want to create new unnecessary standards if we can avoid it.

See this spec.

If the "xs=" parameter is present then a client SHOULD try to retrieve a .torrent file via the URL provided by the "xs=" parameter.

[feross]

So, @anonymlol actually already sent a PR implementing stream-magnet, so that's merged in master now. Still unreleased.

I'd like to standardize on only one of stream-magnet or stream+magnet. Supporting two is just silly. Have any existing programs adopted stream-magnet yet?

[JohnDoee]

stream-magnet should be fine, I don't think anyone adopted anything like this so far.

I did not know about the xs parameter and I agree, that's a good way to do it. My project is largely unused so I'll change to do what's decided here, as long as it's the same everywhere it should be fine.

What makes me a bit sad about this is the lack of ways to specify a file in a multi-file torrent. Something like sf=path/to/file would be great. You don't have to implement it but I need it and would be happy if a decision was made for a param name.

[feross]

@JohnDoee I'm actually a fan of stream+magnet:, the more I think about it! I just asked @mafintosh and he agrees too. It's almost like it represents a capability on top of magnet:. There's also git+ssh: as a precedent which is git over ssh.

What do people think of stream+magnet:?

[feross]

the lack of ways to specify a file in a multi-file torrent

Oh, you make a good point. We need a way to specify a specific file to stream in a multi-file torrent. Let's come up with a new magnet uri parameter for that.

I think file index might be better since it's shorter than specifying the whole file path. File order is deterministic in torrent files.

So how about: ix=5 for the 5th file in the torrent? ix being short for index.

[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
https://github.com/feross/webtorrent-desktop/pull/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 [email protected]
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
https://github.com/feross/webtorrent-desktop/issues/83#issuecomment-235485489,
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: https://github.com/webtorrent/webtorrent/issues/1395