Subject: [ppsp] FWI - raw UDP socket access in browsers

From: Dave Cottlehuber <[email-masked]>
Date: Wed, 5 Mar 2014 11:30:43 +0000

Hey folks,

I have been following these tickets/features with interest for a while;

firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=952927
chrome: http://developer.chrome.com/apps/sockets_udp

also, http://thenextweb.com/google/2013/06/27/google-adds-its-udp-replacement-quic-network-protocol-to-latest-chrome-build/ is intriguing. Keep an eye on it in https://groups.google.com/a/chromium.org/forum/#!forum/proto-quic

A+
--  
Dave Cottlehuber
Sent from my PDP11

---

From: Johan Pouwelse <[email-masked]>
Date: Fri, 7 Mar 2014 15:44:18 +0100

Hi All,
A plug-in is required for Chrome.

Only "Chrome Apps" have access to the UDP API it seems:
http://developer.chrome.com/apps/app_network
For Firefox, is this also "plug-in only"?
  -j

On 5 March 2014 12:30, Dave Cottlehuber <[email-masked]> wrote:
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp

---

From: Victor Grishchenko <[email-masked]>
Date: Fri, 7 Mar 2014 18:54:38 +0400

Actually, given WebRTC in the browser, UDP is not needed that much.
PPSP can be run over WebRTC, just use larger bins (64KB or so). Except
for LEDBAT, maybe.
But you'll have to keep the tab open to seed, that's uncool.

-- 
Victor

---

From: David Jonsson <[email-masked]>
Date: Fri, 7 Mar 2014 17:39:04 +0100

Is there any such WebRTC-implementation to try? Seems like the most
convenient choice.

David
 On Mar 7, 2014 3:55 PM, "Victor Grishchenko" <[email-masked]>
wrote:

> >> also,
> http://thenextweb.com/google/2013/06/27/google-adds-its-udp-replacement-quic-network-protocol-to-latest-chrome-build/is intriguing. Keep an eye on it in
> https://groups.google.com/a/chromium.org/forum/#!forum/proto-quic
> >>
> >> A+
> >> --
> >> Dave Cottlehuber
> >> Sent from my PDP11
> >>

---

From: Dave Cottlehuber <[email-masked]>
Date: Sat, 8 Mar 2014 09:15:40 +0000

For firefox it won't be a plugin, it will be native code + exposed js api;
there's no guarantee that this will be merged into the official ff release
though yet.

I hope to have a crack at building it form source next week.

WRT webrtc, you'll also have a full encrypted stack open between every
peer, similar to tcp, including sctp, dtls, udp underneath. I don't think
SCTP is going to be exposed directly in the browsers (i.e. in JS) but I'd
not expect a lot of additional code to do that.

A+
Dave

---

From: Jeff Thompson <[email-masked]>
Date: Sat, 08 Mar 2014 08:38:33 -0800

On 2014-03-08 1:15, Dave Cottlehuber wrote:
> For firefox it won't be a plugin, it will be native code + exposed js 
> api; there's no guarantee that this will be merged into the official 
> ff release though yet.

Hello Dave,

A related question.  What are the plans for Firefox to support ppsp 
URLs, so that an HTML page can have, for example
<img src="ppsp://ec677ff98abe4a0b2b5c122065c080f14ad4a272">
and Firefox (or an extension) will use PPSP to fetch and display an 
image (or other content type)?

Thank you,
- Jeff Thompson

---

From: Dave Cottlehuber <[email-masked]>
Date: Mon, 10 Mar 2014 22:07:20 +0100

> image (or other content type)?

Hey Jeff,

I would love to see this too. I had a brief chat with some IETF folk about the right way to organise this; it requires a bit of coordination across Mozilla, IANA, and a few other places. I’d love to have some help on this, atm I am still working on the Erlang peer before I get stuck into the javascript one. If there’s interest in doing this I am happy to give input based on what I’ve learned so far.

One of the other crazy ideas I had was that, as the leaf nodes don’t have to be identical chunk size, one could in theory cram an entire web site into a hash tree simply by putting the files into the appropriate lower level chunks with some structuring info, for example, I’m not sure how mime types etc would be transported, and there are a few other hitches, but in *theory* it’s all achievable :).

I would imagine it will need something like http://www.w3.org/TR/app-uri/ and these are defined by http://www.w3.org/TR/uri-clarification/ which refers to http://tools.ietf.org/html/rfc2717 and http://tools.ietf.org/html/rfc2718 ; I have had some offers of assistance in working through all this, with a recommendation that getting a few of the core browser developers onside with the proposal before doing all the paperwork.

Currently my priority is to finish the Erlang PPSP code first :-).

A+
--  
Dave Cottlehuber
Sent from my PDP11

---

From: Jeff Thompson <[email-masked]>
Date: Tue, 11 Mar 2014 08:27:27 -0700

Hi Dave,

Good news that there is some motion on this. I think I can contribute.  
I've had some experience implementing protocol handlers as a Firefox 
extension.  I wrote one to handle the NetInf ni protocol which has a 
hash-based URI similar to ppsp, and helped write one for the ndn 
protocol which has some more complex TCP communication behind the 
scenes.  These are able to render an entire web site in the space of 
documents referred to by URIs with the special protocol.

> I would imagine it will need something like http://www.w3.org/TR/app-uri/

This uses a universal app: URI with an application-specific UUID which 
has to be in every URI, for example app:<UUID>/<hash>. You prefer this 
to using the ppsp: protocol directly, for example ppsp:<hash> ?  This is 
how the examples look on ppsp.me:
http://www.ppsp.me/start.html

> I’m not sure how mime types etc would be transported

The NetInf people have thought about this when they wrote the "Naming 
Things with Hashes" RFC: http://tools.ietf.org/html/rfc6920 . They 
propose putting the content type in the URI, for example 
ppsp://2b2fe5f1462e5b7ac4d70fa081e0169160b2d3a6?ct=video/mpeg

Thanks,
- Jeff

---

From: yunfei zhang <[email-masked]>
Date: Sun, 23 Mar 2014 15:20:28 +0800

Hi Jeff, Dave and all,
   This is a good topic for the WG and after talking with Randell and
Michael, the authors of RTCWEB data channel protocol, we conclude that it
would be great if the WG, and of course the interested folks i ncluding
you, can have some preliminary implementations/analysis on the (maybe)
different means of incorporating PPSP into WebRTC before the WG goes
further on this topic.

BR
Yunfei

2014-03-11 23:27 GMT+08:00 Jeff Thompson <[email-masked]>:

> hash-based URI similar to ppsp, and helped write one for the ndn protocol
> which has some more complex TCP communication behind the scenes.  These are
> able to render an entire web site in the space of documents referred to by
> URIs with the special protocol.
>
>
> This uses a universal app: URI with an application-specific UUID which has
> to be in every URI, for example app:<UUID>/<hash>. You prefer this to using
> the ppsp: protocol directly, for example ppsp:<hash> ?  This is how the
> examples look on ppsp.me:
>  I'm not sure how mime types etc would be transported
>>
>
> propose putting the content type in the URI, for example ppsp://
> 2b2fe5f1462e5b7ac4d70fa081e0169160b2d3a6?ct=video/mpeg
>
> Thanks,
> - Jeff
>
>
>> I would love to see this too. I had a brief chat with some IETF folk
>> about the right way to organise this; it requires a bit of coordination
>> across Mozilla, IANA, and a few other places. I'd love to have some help on
>> this, atm I am still working on the Erlang peer before I get stuck into the
>> javascript one. If there's interest in doing this I am happy to give input
>> based on what I've learned so far.
>>
>> One of the other crazy ideas I had was that, as the leaf nodes don't have
>> to be identical chunk size, one could in theory cram an entire web site
>> into a hash tree simply by putting the files into the appropriate lower
>> level chunks with some structuring info, for example, I'm not sure how mime
>> types etc would be transported, and there are a few other hitches, but in
>> *theory* it's all achievable :).
>>
>> I would imagine it will need something like http://www.w3.org/TR/app-uri/and these are defined by
>> http://www.w3.org/TR/uri-clarification/ which refers to
>> http://tools.ietf.org/html/rfc2717 and http://tools.ietf.org/html/rfc2718; I have had some offers of assistance in working through all this, with a
>> recommendation that getting a few of the core browser developers onside
>> with the proposal before doing all the paperwork.
>>

---

From: Jeff Thompson <[email-masked]>
Date: Mon, 24 Mar 2014 20:37:52 -0700

I assume that a preliminary implementation would be a Firefox 
extension.  If the C++ code is current, it should be easy to compile an 
extension for a few platforms (Linux/OS X).  I see two projects on 
Github.  Are either of these current with the latest PPSP spec?
https://github.com/libswift/libswift
https://github.com/triblerteam/libswift

Thanks,
- Jeff T

On 2014-03-23 0:20, yunfei zhang wrote:
> Michael, the authors of RTCWEB data channel protocol, we conclude 
> that it would be great if the WG, and of course the interested folks i 
> ncluding you, can have some preliminary implementations/analysis on 
> the (maybe) different means of incorporating PPSP into WebRTC before 
> the WG goes further on this topic.
> BR
> Yunfei
>
>
> 2014-03-11 23:27 GMT+08:00 Jeff Thompson <[email-masked] 
> <mailto:[email-masked]>>:
>
>     Hi Dave,
>
>     Good news that there is some motion on this. I think I can
>     contribute.  I've had some experience implementing protocol
>     handlers as a Firefox extension.  I wrote one to handle the NetInf
>     ni protocol which has a hash-based URI similar to ppsp, and helped
>     write one for the ndn protocol which has some more complex TCP
>     communication behind the scenes.  These are able to render an
>     entire web site in the space of documents referred to by URIs with
>     the special protocol.
>
>
>     This uses a universal app: URI with an application-specific UUID
>     which has to be in every URI, for example app:<UUID>/<hash>. You
>     prefer this to using the ppsp: protocol directly, for example
>     ppsp:<hash> ?  This is how the examples look on ppsp.me
>     <http://ppsp.me>:
>     The NetInf people have thought about this when they wrote the
>     "Naming Things with Hashes" RFC:
>     http://tools.ietf.org/html/rfc6920 . They propose putting the
>     content type in the URI, for example
>         On 08. März 2014 at 17:38:46, Jeff Thompson ([email-masked]
>         <mailto:[email-masked]>) wrote:
>
>
>             Hello Dave,
>         I would love to see this too. I had a brief chat with some
>         IETF folk about the right way to organise this; it requires a
>         bit of coordination across Mozilla, IANA, and a few other
>         places. I'd love to have some help on this, atm I am still
>         working on the Erlang peer before I get stuck into the
>         javascript one. If there's interest in doing this I am happy
>         to give input based on what I've learned so far.
>
>         One of the other crazy ideas I had was that, as the leaf nodes
>         don't have to be identical chunk size, one could in theory
>         cram an entire web site into a hash tree simply by putting the
>         files into the appropriate lower level chunks with some
>         structuring info, for example, I'm not sure how mime types etc
>         would be transported, and there are a few other hitches, but
>         in *theory* it's all achievable :).
>
>         I would imagine it will need something like
>         http://www.w3.org/TR/app-uri/ and these are defined by
>         http://tools.ietf.org/html/rfc2717 and
>         http://tools.ietf.org/html/rfc2718 ; I have had some offers of
>         assistance in working through all this, with a recommendation
>         that getting a few of the core browser developers onside with
>         the proposal before doing all the paperwork.
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Arno Bakker <[email-masked]>
Date: Tue, 25 Mar 2014 09:09:45 +0100

On 25/03/2014 04:37, Jeff Thompson wrote:
> extension for a few platforms (Linux/OS X).  

Hi all

quick response: such a Firefox extension already exists under the name
SwarmPlayer 3000, which was demoed at one of the IETF meetings. The last
version supports VOD, and worked for Ogg containers.

We had it working with live Ogg with a different backend, so that is
definitely possible. It does require some maintenance, I had problems
getting it to work with newer XUL runner SDKs, and a refactored version
with nice HTTP fallback possibilities also ran into undiagnosed XUL
runner errors.

If there is interest, we can place the code in the libswift repo, see below.

I see two projects on
> https://github.com/libswift/libswift

This is where Riccardo and I maintain the reference implementation which
implements the -08 spec.

Nicer would be to add it to Firefox as a new protocol handler by default ;o)

Regards,
    Arno

---

From: Riccardo Petrocco <[email-masked]>
Date: Wed, 26 Mar 2014 06:25:10 +0100

Hi all,

Just to add to what Arno sad in the previous mail.

> This is where Riccardo and I maintain the reference implementation which

The repo needs a bit of cleaning and removing of unnecessary/old branches
(will soon be done).
Also, I'm currently finishing some work on the congestion and flow control
which I'll be merging soon.
If you want to use it please refer to the master and devel branch (most up
to date).
In a couple of weeks everything will be ready.

Regards,
Riccardo

---

From: Jeff Thompson <[email-masked]>
Date: Thu, 27 Mar 2014 09:14:47 -0700

> version supports VOD, and worked for Ogg containers.

Hello Arno,

SwarmPlayer seems hard-wired to display video. For a Firefox extension 
to use a ppsp link to fetch and display any content (images, HTML), it 
needs a way to report the MIME content type for Firefox. What do you 
think of the solution in RFC 6920 <http://tools.ietf.org/html/rfc6920> 
"Naming Things with Hashes" to include a ct parameter?  The URI would 
look like:
ppsp://5e2fe5f1462e5b7ac4d70fa081e0169160b2d3f1?ct=image/jpeg

Thanks,
- Jeff

---

From: Dave Cottlehuber <[email-masked]>
Date: Tue, 25 Mar 2014 09:34:37 +0100

> version supports VOD, and worked for Ogg containers.

Sounds great! Yes, I’d love to see this (and any other similar bits) published.

> Nicer would be to add it to Firefox as a new protocol handler by default ;o)

:) one step at a time perhaps!

Firefox’s JS-exposed UDP support should land ~ June timeframe, too. This would
be an interesting combo to battle it out.

--  
Dave Cottlehuber
Sent from my PDP11

---

From: Arno Bakker <[email-masked]>
Date: Mon, 31 Mar 2014 09:01:14 +0200

> ppsp://5e2fe5f1462e5b7ac4d70fa081e0169160b2d3f1?ct=image/jpeg

Hi Jeff et al

that looks like a nice standardized proposal. SwarmPlayer currently
needs some additional metdata parameters, e.g. Content Integrity
Protection method, chunk addressing method used (see -08, Sec. 12.1.1)
that we would need to define.

And anomalies like Firefox requiring a X-Content-Duration reply header
(=duration of video in seconds) from a protocol handler.

I will try to upload the SwarmPlayer code this wednesday.

CU,
    Arno