# Media stacks strategy
# Actions
1. Blog post about integrating IPFS in tools (iow, my work for ffmpeg and mpv)
2. New repository for integrations (in ipfs-shipyard?) as a central place where people can submit tools for IPFS support
3. Reddit post to ask for suggestions on tools that would need IPFS support
3.1 Ask for which web frameworks need IPFS support
4. Investigate - say - top 10 `android tv dongles` to see what's running on them. How to get IPFS on there.
4.1 Get IPFS supported in software that runs mostly on those dongles. Likely KODI but to be determined.
5. (on browsers) Detect if IPFS is supported. Question is send to Igalia, they are going to make a draft?
6. In some popular browser video libraries, add IPFS support. To be determined which ones.
7. Continue work on CURL

Focus: Verifiable data support in client tools, for data already published on IPFS.

Secondary priority:
* Publishing workflows
* Editing tools and workflows (eg content-addressed datastores)

## Plan

* blog post
* add repo for integrations
* CTA asking for more tools
* post to reddit/forum/etc
* Kodi - highest priority :exclamation:

## Building blocks & ease of use
(pre-ipfs world) Say right now when a person wants to play a video file they look for a video player to install. Pressing double click (or single on mac) on that file plays the video in their player. Happy user, very easy.

Now a user gets a CID and from the place the user got it, it's clear the CID is a video file on the IPFS network. How to get to the same user friendlyness as playing a regular file?

A video file is just an example here. It applies to any IPFS resources (for example, opening a document in your favorite editor where it's data is stored on IPFS).

This is true both open source libraries/tooling (non-browser purposes) as well as in browser purposes to enable developers to easily make use of IPFS resources.

TODO: write as a set of user stories ("As a user, I...")

* how to ff/rew?
* how to pause/stop?
* how to ensure stream stops?

## Open source libraries/tools strategy
We can patch up, say, LibreOffice, Office, word, etc.. to support IPFS. But it would be "top level" implementations. Each their own implementation on how to get something from the IPFS network. For some applications this might be required but in general this is probably a bad idea and costing much more time then needed.

Enter the **low level approach**. Here we patch up lower level libraries. The idea is that patching the lowest possible library should give easy IPFS access to any project building on top of that library. There might still be work needed in higher level libraries but that's expected to be fairly small work.

### Audio & Video
In the audio/video world (playback), ffmpeg is the biggest single lowest level library out there. It has support for IPFS which allows for applications build on top of ffmpeg (think of any application that uses ffmpeg under the hood) to easily support IPFS resources. For applications on top of ffmpeg, it is now potentially a simple patch (a one-liner even for `mpv`) to enable IPFS support. Still more work is needed here. If a user gets a CID where it's known to be a video then the user should be able to play it like a file or url in their media player of choice (provided it's a fairly popular one).

* Unity
* audio streaming libraries/frameworks
* video streaming libraries/frameworks
*

### Files
See the other document about OS integration.

### Documents
See the other document about OS integration.

### Downloading files (cli)
On the command line that's often either wget or curl. Curl support is on it's way. Wget is, like curl, very much URL focused. It might potentially be possible to add IPFS support there too. I've not had any discussions with wget devs yet. Wget is a user facing tool though (you don't build stuff on top of it), curl on the other hand is a library too yet there it's build specifically in the tool side. So having IPFS support in curl still means you don't have IPFS support if you link against curl (note: don't we want to have this?)

### Potential tool braindump where IPFS might be interesting

Network utils
* nslookup (integrate with dnslink)
* dig (integrate with dnslink)
* ping (multiaddr support)
* More?

FS level tool integration
* ls (see the other document about OS integration)
* cat (see the other document about OS integration)
* cp (see the other document about OS integration)

Graphics / User-level tools
* Gimp
* Imagemagick
* GraphicsMagick

Audio
* Linux audio servers: JACK, OSS, ALSA, PulseAudio
* Network Audio System https://www.radscan.com/nas/nas-links.html
* PipeWire https://pipewire.org/

We have a quite clear distinction here in IPFS tooling support.
1. tooling to reach nodes on IPFS
2. tooling to get data from IPFS

The tooling to reach nodes (ping, nslookup, dig) are administrative tools. You could use them in scripts to automate things but other then that no applications are likely to be build "on top" of those tools. Having IPFS support in those does make IPFS very accessible.

The tooling to get data is also not very helpful to build applications with. It is with command line usage and scripting.

## IPFS CDN for mass video distribution
Like for non-browser usage, in a browser context there are also fundamental "libraries" where adding IPFS support would enable whole ecosystems to suddenly make easy use of IPFS.

Note, i just took some players from [this](https://medium.com/@johnksmithme/top-10-best-html5-video-players-in-2019-4d5434de50a1) page along with a couple others i found. There are many more video players out there!

Some of these players are commercial. With regards to broad open source IPFS enablement, these players are probably not that interesting. However, in terms of commercial support this might be a very interesting (think ipfs + filecoin)?

In general though, IPFS should be supported in widely used video players. It should also be clear to users what the advantages are. If this is a positive experience then you eventually get in the situation where potential new users would pick video players that support IPFS. Leading to more adoption, more... etc.. you get the point :)

### VPlayed (commercial) [link](https://www.vplayed.com/hls-html-player.php)
* iOS and Android support!
* Could be an interesting commercial usecase for IPFS

### jPlayer (oss) [link](http://jplayer.org/)
* iOS and Android support!

### JWPlayer (commercial) [link](https://www.jwplayer.com/)
* iOS and Android support!
* Could be an interesting commercial usecase for IPFS

### Video.js (oss) [link](https://videojs.com/)
* Browser only

### hls.js (oss) [link](https://hls-js.netlify.app/demo/)
* Browser only