IPFS WebComponents

[krl]

So, i've been doing a fair amount of research and experimentation, and i think i've come to a very nice point.

Instead of using the full-blown webcomponent stack, which seems to be unstable, hardly supported by browsers, and heavily tied-into different frameworks (polymer et al). Here i'm only using the custom element part. This gives us css namespacing and html imports, and not much more. Still enough to provide a demo of what is possible.

The biggest part is the JS imports over ipfs, which i think fits very well into the model we're envisioning. Please check out krl/ipfs-import for a demo and readme!

@jbenet @diasdavid (feel free to ping more ppl, not sure of all web github handles)

[dignifiedquire]

Link to the example: https://github.com/krl/ipfs-import

[harlantwood]

Nice work @krl.

[dignifiedquire]

So I've been thinking if we actually need anything from web components or any other spec and created this: https://github.com/Dignifiedquire/components-on-ipfs It's just a webpack config that resolves all assets, bundles them and allows you to serve them completely through IPFS.

Still thinking about sharing dependencies, but that could easily be handled via a script loader which loads from an ipfs url or somewhere else.

The main point I'm trying to make is that I think we do not need to restrict ourselves to any spec or specific loader/bundler, but rather can support a lot of them very easily and just provide recipes on how to best use those.

[jbenet]

looks interesting! -- @diasdavid we should probably review this together

The main point I'm trying to make is that I think we do not need to restrict ourselves to any spec or specific loader/bundler, but rather can support a lot of them very easily and just provide recipes on how to best use those.

:+1:

[daviddias]

I like the sound of that :) I feel that the end goal will always be 'How to use IPFS to load your Web Application', WebComponents became the first pick because they were nice, Standardised and the 'Component' name and its encapsulation features made it easier to transmit the message.

[jbenet]

we didnt discuss this in the hangouts today. let's try next week, or later this week.

[dignifiedquire]

we didnt discuss this in the hangouts today

well the hangout was already long enough so I didn't want to stretch everyone's attention even more. I won't be around next week so maybe we can have a chat this week?

[daviddias]

SGTM :)

[dignifiedquire]

I would like to have @krl in that discussion but I haven't seen anything from him in a while, any ideas what's up with him/when he will be around?

Timing wise, today I'm flexible, tomorrow is not so good for me.

[daviddias]

@mikeal has brought back the idea of making IPFS WebComponents with ipfs-elements. It uses js-ipfs-api to load content from an IPFS node

@mikeal any plan to make a js-ipfs standalone version?

[mikeal]

yup, i want it to work on the same element. i want it to actually default to that behavior. is there some demo content up that I can use for testing and getting this to work?

[lidel]

@mikeal try my fav test image: /ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR 🙃

Jokes aside, XKCD archive has a lot of images that are safe for use: /ipfs/Qmb8wsGZNXt5VXZh1pEmYynjB6Euqpq3HYyeAdw2vScTkQ

Other data sets can be found at https://archives.ipfs.io

[dignifiedquire]

@mikeal awesome you are picking this up. Now if you host the library itself & the html on IPFS then you are IPFS from top to bottom :)

[daviddias]

@mikeal, there is https://github.com/ipfs/js-ipfs/tree/master/examples/exchange-files-in-browser. In fact, both js-ipfs-api and js-ipfs implement the same API, it is just how the node gets started that is different. In js-ipfs you have to -> https://github.com/ipfs/js-ipfs#ipfs-core-use-ipfs-as-a-module

I see that you use ipfs.ls and Node.js Streams, we learned that Node.js Streams are really memory intensive and be a difference between having js-ipfs run the tab out of memory for files ~100MB, while pull-streams are lighter and you can load files with ~500MB and more. I'm currently working on exposing both APIs in both js-ipfs and js-ipfs-api so that users can consume the type of streams they want directly. Track here https://github.com/ipfs/interface-ipfs-core/pull/162 I'll ping back in this thread once it is done :)

[mikeal]

RE: Streams

I'm only using streams because render-media uses streams. I currently don't handle offsets, which means that seeking is currently broken.

At some point I'm going to need to re-write render-media and I'm not entirely sure which underlying pattern I'll use. Frankly, asking for an offset and getting a stream seems insane (it should just return a buffer) and in my other work I've been scaling everything down to a simple read() call that returns a promise.

[danimesq]

@krl @jbenet Updates?