<Kubuxu>
I will research it on my own. Will post results.
<lidel>
Thanks, sounds useful.
anticore has quit [Quit: bye]
<The_8472>
handling raw ipfs paths in browsers is quite difficult because they are indistinguishable from URI fragments relative to the page's base URI
<The_8472>
which might be tolerable on ipfs pages themselves but not on http pages linking to ipfs paths
Encrypt has quit [Quit: Quitte]
dignifiedquire has joined #ipfs
<ipfsbot>
[webui] RichardLitt opened pull request #142: Converted majority of BS elements (webpack...feature/140-convert-react-bs) http://git.io/vEiuS
pfraze has joined #ipfs
Guest31169 has joined #ipfs
Guest31169 has quit [Changing host]
Guest31169 is now known as gwillen
corvinux has joined #ipfs
<Kubuxu>
That is why for the time we will be using fs:/
ralphtheninja has joined #ipfs
<Kubuxu>
for long time I think
Senji has quit [Read error: Connection reset by peer]
Senji has joined #ipfs
corvinux has quit [Remote host closed the connection]
<lgierth>
the gateway is only meant for transitional backwards compatibility
<The_8472>
POST to the gateway?
<lgierth>
yeah
<The_8472>
see, no need for APIs
<Kubuxu>
what about your local identity, signing files
<lgierth>
eventually we'll have ipfs ship with browsers
<lgierth>
i.e. an ipfs node as an addon or plugin
<Kubuxu>
storing files on your IPNS
<Kubuxu>
lgierth: I would prefer one in my computer not in browser
<Kubuxu>
I close the browser and it stops sending files, publishing IPNS and so on.
<lgierth>
the identity of the browser one can be derived from the computer one
<Kubuxu>
It could
<lgierth>
you can do both of course
<The_8472>
http sign <hash> -> send to your local gateway ?
<lgierth>
or just point the addon to a node running on your computer, outside of the browser
<The_8472>
that way XHR can be used
<The_8472>
no need for injecting custom JS to the page
<Kubuxu>
How does that differ from exposing the API? also the api is http to gateway.
<The_8472>
no need for injecting custom JS to the page
<lgierth>
The_8472: yeah but you lose all of the p2p niceness
<lgierth>
imagine wikipedia comes with an embedded ipfs.js node
<The_8472>
why should it? there should be one single ipfs node on the computer
<lgierth>
why?
<The_8472>
everything else is just inefficient
<Kubuxu>
and you need gateway address either way, I don't want to say to each side I want to connect to this and this address and so on
<lgierth>
i don't see why the two options are exclusive
<The_8472>
because you don't want each browser tab to run its own p2p client
<Kubuxu>
I want just connect to site, it ask me for permissions and just works
<The_8472>
that thing would murder your storage, ram, router... everything
<lgierth>
The_8472: yep that's a valid point. there are ways around it
wiedi has quit [Ping timeout: 240 seconds]
<The_8472>
yes, that way around it boils down to one ipfs instance per computer
<The_8472>
or even per LAN if its your own
<lgierth>
ipfs.js can peer with that local node
<Kubuxu>
also the API is just HTTP calls, difference is that you don't have to remember them, dig through spec and so on, just use the API
<lgierth>
instead of dialing out over webrtc
<lgierth>
and if there is no such local node, it'll dial out
<lgierth>
or try a node in another tab
<The_8472>
lgierth, well, then you need to grant websites access to the local network.
<lgierth>
s/it will/it could/
<The_8472>
injecting into the page seems saner
<lgierth>
i'm just bouncing off ideas here
<lgierth>
we'll want an ipfs node to be lightweight enough for every process to have their own node
<lgierth>
"process" in the wider sense
<lgierth>
not that every such process neccessarily needs one
<The_8472>
is that really a node then? seems more like a client
<lgierth>
but there are cases where you don't want this additional dependency on the environment
<lgierth>
The_8472: no fixed set of what it'd do -- it could publish, seed, only leech, etc.
<lgierth>
another case is simply transition
<The_8472>
well, i think there should be a encouraged/default scenario to keep things sane. you really don't want dozens of independent instances in your network.
<lgierth>
"install ipfs on your computer" is not good enough for the transition phase ;) not even when there is a critical mass of ipfs nodes deployed
<lgierth>
for the regular user, that is
<The_8472>
well, bundling it as browser addon sounds better to me than putting it in each tab
<lgierth>
about default scenario, yep very trye
<lgierth>
yeah word
<lgierth>
every website shipping their own version of bundled ipfs can quickly become its own nightmare
<lgierth>
all of these options are transition steps
<lgierth>
they're not exclusive and we basically want and need all of them :P
<The_8472>
anyway, before we even get to that there are lots of things that need to be standardized, like write access/signing etc.
<lgierth>
haha yeah way to go
<lgierth>
the fs: stuff you're writing looks pretty cool
<lgierth>
i'll have to jump off the keyboard again, pack my stuff
<The_8472>
all those canonizations and redirects are still a tangled mess... not easy to clean up ^^
<Kubuxu>
The_8472: As you said: you can either expose the API or (API address and gateway address). In this case it is better to expose API but after tokens get in and we have to makes sure that it will be possible to make child of the API with different token. This way: some sane defaults can be made (fetching files, objects) and other applications can request additional permissions.
<The_8472>
yeah, but maybe that's something js-ipfs-api should implement?
<The_8472>
so the addon just has to inject it in a preconfigured way
voxelot has joined #ipfs
<Kubuxu>
It API with children is something that js-ipfs-api should implement
<Kubuxu>
browsers addons will have to become bridge between current world and world with browsers working with IPFS itself.
<Kubuxu>
also even if you wanted to store data on IPFS for the site later you have to store the hash somewhere and any data stored in IPFS should be treated as publicly available
cemerick has quit [Ping timeout: 260 seconds]
<The_8472>
you can encrypt it obviously
<The_8472>
that way it may be public and you can use it anywhere, but only if you have the key
<Kubuxu>
you can but again you have to store hash and the key and you will have (in future) ask user for additional permissions
<The_8472>
well, you can store that on your local ipfs node if you trust that one
<The_8472>
there obviously needs to be an encrypted-add
<The_8472>
and identity files ala ssh
<Kubuxu>
We don't understand each other. There is no localStorage, how do you even store hash for content you saved?
<The_8472>
ah, i see. i guess there needs to be a concept of "me" or "local" in the api? idk.
<lgierth>
can the addon store stuff?
<lgierth>
as opposed to a page with fs:
<The_8472>
sure
<lgierth>
ok cool
<lgierth>
and you can expose an api from the addon to a page?
jaboja has joined #ipfs
<The_8472>
yeah
<Kubuxu>
Yes, we will have to think about something
<lgierth>
then let the addon handle storage
<Kubuxu>
IDK if we can replace localStorage though (it would be great if we could as it is know interface for web devs).
<lgierth>
maybe have a look at localstorage polyfills from the earlier days
<The_8472>
well, my point is that we should encourage storing things in ipfs where possible
<The_8472>
but you do raise a valid question how to bootstrap the lookup
<The_8472>
"how to look for your own stuff"
<lgierth>
you can have the addon store it in a canonical ipfs node on the computer, or in some browser storage if there is no such node
<lgierth>
re: encouraging storing things in ipfs where possible ^
<Kubuxu>
Yes but you have to have a way to make data private for the site (two first segments define site IMHO).
<The_8472>
yeah, still need some uri to sync one browser to another. ipns + crypto key
<Kubuxu>
5MB limit is not much (limit of localstorage), if you need to store anything bigger then you have to use IPFS.
<lgierth>
one point to consider is that there is no "ipfs" in and off itself -- there's just various implementations, with go-ipfs being the most mature one
<lgierth>
The_8472: about syncing, you'll be able to pin /ipns records soon, and there's going to be pub/sub in the longer term
<Kubuxu>
The_8472: to keep data synced you can use IPNS and same pubkey
<Kubuxu>
just what you saud :p
<Kubuxu>
s/saud/said
<ipfsbot>
[go-ipfs] whyrusleeping force-pushed fix/multipart from 25d5a00 to 8011c37: http://git.io/vR7OX
<lgierth>
the two edge nodes aren't in there because they're in my backpack for 32c3 :) and they're not default bootstrappers (the ones marked as "gateway" are)
<Kubuxu>
heh
ralphtheninja has quit [Ping timeout: 246 seconds]
m0ns00n has joined #ipfs
sloom has quit [Quit: Lost terminal]
corvinux has quit [Remote host closed the connection]
corvinux has joined #ipfs
corvinux has quit [Remote host closed the connection]
<multivac>
dignifiedquire: 2015-12-25 - 23:57:22 <lgierth> ask dignifiedquire > can i pick up my friends' wristbands too? -- if you bring your friend along, yes. Otherwise - no.
<multivac>
dignifiedquire: 2015-12-27 - 05:35:27 <richardlitt> tell dignifiedquire I am afraid to touch stuff on webui until that PR is merged, as it is pretty massive.
<dignifiedquire>
so it needs to exist
<dignifiedquire>
-d lib means it will be outputed there
<dignifiedquire>
richardlitt: ^^
<lgierth>
M-davidar: it'd be super useful if multivac printed the .ask lines on /join too
hartor has quit [Quit: hartor]
hartor has joined #ipfs
<Stskeeps>
is there a way to tell ipfs to use <PUBLIC IP>:<some port> instead of the upnp generated one or whatisit?
<ipfsbot>
[go-ipfs] whyrusleeping pushed 1 new commit to fix/multipart: http://git.io/vEPUT
bauruine has quit [Remote host closed the connection]
bauruine has joined #ipfs
keorn has quit [Ping timeout: 260 seconds]
ralphtheninja has quit [Ping timeout: 276 seconds]
dignifiedquire has quit [Ping timeout: 264 seconds]
rombou has joined #ipfs
reit has joined #ipfs
computerfreak has quit [Remote host closed the connection]
<ipfsbot>
[go-ipfs] whyrusleeping created feat/disable-autogc-test (+1 new commit): http://git.io/vEPd5
<ipfsbot>
go-ipfs/feat/disable-autogc-test d207e8b Jeromy: disable auto repo gc tests temporarily...
tendie has joined #ipfs
<tendie>
Sup
I_can_FLY has joined #ipfs
<M-prosodyContext>
iso.h !
<I_can_FLY>
Hello, I was wondering if anyone would know how possible it would be to set up a live stream with IPFS. I've just started to look at IPFS, and figured I would ask here.
<I_can_FLY>
I know VOD is possible, but the two work differently.
<tperson>
There has been some talk about live streaming for about a year or so on and off, but I don't knoow how close anyone has come to really doing it. It's possible, but probably not with any implementation at the moment.
<tendie>
Probably
<I_can_FLY>
Well if VOD works, then potentially live streaming could work.
<The_8472>
that's strange logic
<I_can_FLY>
How so?
<The_8472>
vod is immutable content, a stream is... well... a stream of endlessly changing data. it's mutable
<I_can_FLY>
Depends on how the content is streamed.
<The_8472>
not really. every unit of time new data arrives. adding something is mutation.
<The_8472>
i'm not saying it's not possible. i'm just saying that "VOD works, therefore live streaming must work" does not seem logical to me
<tperson>
The last thing I remember hearing about a live stream implementation was to use the DHT as a pub/sub and using a tree struchure, where the root of the tree is the original producer. When joining you are pointed at a few peers down the chain that can provide you the next block of the video stream.
<I_can_FLY>
I didn't say it will work.
<The_8472>
<I_can_FLY> Well if VOD works, then potentially live streaming could work.
<I_can_FLY>
I said it should be possible.
<The_8472>
well, that thing. doesn't seem logical.
<I_can_FLY>
possible != will
<tperson>
Each new block of the stream is broadcasted and you talk to your designated peers to request the file.
<The_8472>
I_can_FLY, doesn't matter how you cushion it. B does not follow from A
<tperson>
whyrusleeping probably can talk in more detail of anything he's been working on for it, but I doubt he's touched ont he subject in a while.
<The_8472>
"a camp fire works, therefore nuclear reactors might be possible"