Add webtorrent:// protocol handler about webtorrent-desktop HOT 62 CLOSED

Upvote this comment if you prefer stream-magnet.

from webtorrent-desktop.

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.

from webtorrent-desktop.

@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:?

from webtorrent-desktop.

Upvote this comment if you prefer magnet-stream.

from webtorrent-desktop.

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.

from webtorrent-desktop.

Upvote this comment if you prefer magnet-play.

from webtorrent-desktop.

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.

from webtorrent-desktop.

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?

from webtorrent-desktop.

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.

from webtorrent-desktop.

+1

from webtorrent-desktop.

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

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

from webtorrent-desktop.

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

from webtorrent-desktop.

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

from webtorrent-desktop.

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.

from webtorrent-desktop.

@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

from webtorrent-desktop.

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

from webtorrent-desktop.

@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.

from webtorrent-desktop.

@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.

from webtorrent-desktop.

@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.

from webtorrent-desktop.

@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.

from webtorrent-desktop.

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

from webtorrent-desktop.

@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..

from webtorrent-desktop.

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.

from webtorrent-desktop.

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?

from webtorrent-desktop.

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.

from webtorrent-desktop.

Some options:

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

from webtorrent-desktop.

i like play-magnet: :)

stream: is too general

from webtorrent-desktop.

Another option:

• magnet-play

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

from webtorrent-desktop.

Upvote this comment if you prefer play-magnet.

from webtorrent-desktop.

@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?

from webtorrent-desktop.

@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.

from webtorrent-desktop.

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?

from webtorrent-desktop.

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

from webtorrent-desktop.

@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 :)

from webtorrent-desktop.

@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..

from webtorrent-desktop.

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

from webtorrent-desktop.

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.

from webtorrent-desktop.

indeed, changed my vote :))

from webtorrent-desktop.

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

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

from webtorrent-desktop.

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.

from webtorrent-desktop.

@feross good point, updated :)

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

from webtorrent-desktop.

@jaruba make up your mind women.

from webtorrent-desktop.

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

from webtorrent-desktop.

@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.

from webtorrent-desktop.

@JohnDoee

from webtorrent-desktop.

@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.

from webtorrent-desktop.

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?

from webtorrent-desktop.

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.

from webtorrent-desktop.

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.

from webtorrent-desktop.

@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

from webtorrent-desktop.

@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?

from webtorrent-desktop.

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

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

from webtorrent-desktop.

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

from webtorrent-desktop.

Done
#640

Shipped in v0.8.1

from webtorrent-desktop.

@dcposch How is this done ?

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

from webtorrent-desktop.

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

from webtorrent-desktop.

@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

from webtorrent-desktop.

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
#83 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIcoTZIRsJm2i9zbOw7k1gh6SZ0gkKYks5qZuXAgaJpZM4HrfuY
.

from webtorrent-desktop.

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

from webtorrent-desktop.

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.

from webtorrent-desktop.

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

from webtorrent-desktop.

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

from webtorrent-desktop.