I2P Streaming

[JulioCBaviera]

I2P currently supports multimedia content streaming using Icecast, Shoutcast or several other variants of the classic Unicast Transmission Control Protocol data delivery. Unfortunately if a group, organization or individual chose to deliver multimedia content using I2P, this would require substantial resources on the broadcasters end as well as consume large amounts of I2P network resources (bandwidth) - depending on the audience size.

Unfortunately, the implementation of a fully compliant RFC 5110 IEFF multicast architecture for the end user would require kernel level manipulation for network routing. Posix compliant systems can be adapted for multicast integration, however in the world of Microsoft - this adaptation comes at a very lengthy work around. Most end users of I2P are not fully immersed in the "Dark Art" of networking and in all reality - should not be forced to go through a lengthy process of network hacking to become fully integrated.

A RFC 5110 IEFF multicast architecture for "Live" content delivery within the framework of the I2P network itself is possible, but would require a long road ahead in terms of research and integration within the core network architecture.

Is there a solution that can truly liberate Live content delivery, while providing anonymity and an economical solution for resource consumption . . .

Webrtc adaptation of web torrenting requires the use of a compilation of Java / HTML solutions which is not ideal. Bram Cohen has adapted the Bittorrent protocol for live content delivery, however - that solution is closed source with no expected release of that information.

One must delve back further into the early Primordial days of the Internet to grasp a possible solution.

Gnutella / Napster provided a working Peer To Peer / Vis-à-vis / Point To Point - content delivery architecture. Unlike Bittorrent - a point to point system requires that each single person accessing a specific piece of content - to relay that content - in a single lineage data flow architecture. Bittorrent, however, creates a mesh of multiple consumers of the unique content that share that same content amongst everyone consuming it.

A Gnutella / Napster delivery system could be adapted for Live Multimedia content delivery that could be engineered to overcome single point data delivery failure. The use of modern Open Source multimedia codecs can also be used within the multimedia content delivery to maximize content definition and minimize resource requirements. Such codecs include the Opus audio codec and the AOMedia Video 1 (AV1) video codec. Both FFmpeg and VLC can be used for multimedia encoding using these open source multimedia codecs AND delivery protocols.

Who wants to be the first TRUE Peer To Peer Pirate of I2P

[zzz]

You're right there's a lot of challenges.
A lot of possibilities have opened up lately due to speedups in the streaming lib and the new ratchet encryption.

Orignal and his team are doing good work in making streaming media work better, and they have some interesting experiments going. They're playing with pseudo-multicast as well. True multicast is a much bigger challenge. We've discussed, for example, half-multicast in i2p at the OBGW. There's a really complex control protocol RFC that was suggested as a starting point but it looks like a nightmare. You can find orignal in IRC #ls2 and #i2pd-dev.

Agreed that webtorrent in the browser would be tough. The collapse of the i2p browser project late last year makes it a lot harder to do anything special.

The other place to look is MuWire. Especially the plugin which looks a little like a HTML media server. I'm not sure if it supports in-order downloads now but take a look. IRC #muwire

[zlatinb]

The other place to look is MuWire. Especially the plugin which looks a little like a HTML media server. I'm not sure if it supports in-order downloads now but take a look. IRC #muwire

The MuWire plugin does not support in-order (or "sequential") downloads but the standalone GUI does. It also has "preview" functionality which basically launches the default media player for the file type and plays whatever has been downloaded from the beginning of the file.

There is a TODO item for HTML5 media players for the plugin, which combined with Preview and sequential downloading would make it quite usable.

[eyedeekay]

I've actually got some of the basic WebTorrent issues worked out already, but at least one problem is "which friggin webtorrent." I met Feross at the virtual Distributed Camp this year, and we discussed for some time. There is desktop WebTorrent, which does old-school Bittorrent and Bittorrent in the browser. One goal here is to bridge Bittorrent and WebTorrent, and it would make sense that I2P would also need to be bridged. There is also biglyBT WebTorrent, which launches Chromium to do WebTorrent downloads and will happily bridge them to I2P. There is also Anacrolix LibTorrent, which can also bridge WebTorrent and Bittorrent, does not require Chromium(uses the Pion libraries for WebRTC) and which can use a SOCKS proxy to work with I2P. When configured in this way, with in-i2p trackers and servers for establishing peerconnections as well, WebTorrent seems to work over I2P, but obviously it cannot exit and bridge clearnet torrents anymore(But this is probably not hard to fix). Edit: The glaring argument for doing Feross' node WebTorrent, though, is that the preponderance of the WebTorrent ecosystem uses it, including gittorrent(and it's helper), which is probably better than resumable git clone. But it's also almost certainly the most work, it might even be easier to write a new gittorrent helper with Anacrolix.

However, if we for a moment assume BiglyBT is the best Bridge option and don't care that much about adapting another bridged WebTorrent desktop in the near future, then in a browser, with a bit of messing around, it's nearly usable. This has been a long-term goal of I2PIPB since at least last year. WebRTC can be forced to use a proxy, and since WebTorrent applications usually live in a browser, all you need is a way for the browsers to know an address for eachother, which is what they do with STUN/ICE/TURN servers. Those servers can be configured in about:config/user.js/prefs.js without a dedicated browser now, and it's possible to make it so applications use "our" preferred servers and not the app itself. Making the servers them pass I2P addresses back and forth requires modifying how the service works, so I did that with a thing I called "Blind Turn." Then you need a WebSocket I2P torrent tracker. Right now I have a sort of crude adaptation of that working. I have not used it to download files yet, but I have used it for distributed chat. It all needs much more testing and probably has bugs and inadequacies of all kinds to fix, but I do know that it can work and that unless otherwise forced to, it will use the configuration of the WebTorrent web application you are visiting, so if one of them uses sequential downloads, then it should pretty much be the same.

I'll try to put together a clearer assessment of how successful I've been at it soon, it has been a "Weekend Project" for the most part except where it may concern git, but I believe I am fairly close to successfully downloading over I2P with WebTorrent. My use case for it will primarily be something like CacheP2P, where web sites can supplement their content delivery using Bittorrent and a custom protocol handler by allowing all the visitors to help eachother download resources that are comparatively heavy.