<jbenet>
krl: what if we make the viewer be javascript on top of a raw page?
<jbenet>
krl: i've always been annoyed that default directory listings on the web are html pages, cause i can't curl it into unix tools.
pinbot has quit [Ping timeout: 244 seconds]
<jbenet>
krl: this wouldn't quite fix it... but may get closer
<jbenet>
aww pinbot :(
atomotic has quit [Read error: Connection reset by peer]
guest965 has quit [Ping timeout: 252 seconds]
<krl>
jbenet: curl it into unix tools?
<krl>
how would js solve this?
<krl>
otherwise, yes i think making it more client side makes sense, keeping the gateway code free of template wrangling
Encrypt has joined #ipfs
<krl>
i'll get to that in a minute
<Encrypt>
o/
<krl>
but hmm, this would maybe require the readonly gateway thing?
<jbenet>
well, wouldn't _quite_ work, but what i'm thinking is have something like the actual listing is (inside html sadly but) in one div on the page but formatted as text or whatever, and then js that loads can transform it into the pretty index.
<jbenet>
not sure it's worth it--
<jbenet>
(because browsers without js would be hosed)
<jbenet>
then again... browsers without js...
guest965 has joined #ipfs
<krl>
could fall back to the uglies inside noscript
<krl>
but regarding curling the gateway, there's actually no need since you have ipfs ls
<jbenet>
krl: true
<krl>
that's more of an old web problem ;)
<Encrypt>
Simply create an alert: "Enable JS please."
<Encrypt>
:}
<krl>
but ok, how is the gateway readonly api being implemented btw?
<krl>
i see an overlap here with the gateway/api distinction in general
<krl>
i'm kind of leaning towards that it would be nice to basically have window.ipfs be set automagically
<cryptix>
'enable js please' is horrible
<krl>
or root.ipfs, whatever. something so that you don't have to bother as you're writing a webui-panel, or js for your ipfs-web page
<cryptix>
elima_: i think that add want's a multipart form
<krl>
and btw, electron works now, addressed the tray crash bug, now we just need to think about installers
<krl>
setting up to test on windoze atm
<Blame>
morning!
<elima_>
cryptix, hmm maybe, though that's not what the code suggests.. multipart is selected if content-type (mediatype) specifies so
<elima_>
it seems that a required argument 'path' is not being resolved from the URL I'm trying, but I'm not sure what the expected syntax is, and found no doc on it
<jbenet>
elima_ that's odd-- the path shouldn't be required. but try adding ?arg=foo at the end
<elima_>
jbenet, tried curl -v -X PUT -H "Content-Type: text/plain" --data "Hello world!" "http://localhost:5001/api/v0/add?arg=foo" -> same error "File argument 'path' is required"
<Blame>
ran on my machine
<jbenet>
elima should look at what the cli sends when doing `echo foo | ipfs add` with daemon on.
<Blame>
got same error.
<jbenet>
can check by inspecting the http request sent out-- can do it by launching the daemon, editing the config to change the api url, and then setting up a netcat server there or something
<jbenet>
krl: awesome, can i try it out on osx?
<elima_>
jbenet, ok I will try to inspect it that way, thanks!
<whyrusleeping>
jbenet: its just npms recursive import thing
guest449 has joined #ipfs
guest4491 has quit [Ping timeout: 276 seconds]
tilgovi has joined #ipfs
lmatteis has joined #ipfs
lmatteis has quit [Client Quit]
<bret>
windows pathing is a bitch
williamcotton has joined #ipfs
tilgovi has quit [Ping timeout: 246 seconds]
nessence has quit [Remote host closed the connection]
<bret>
does ipfs have funding?
Encrypt has joined #ipfs
Tv` has joined #ipfs
guest4491 has joined #ipfs
guest449 has quit [Ping timeout: 272 seconds]
domanic has joined #ipfs
<daviddias>
mafintosh you around? I'm looking for the multistream module you mentioned on issue #13
<mafintosh>
daviddias: if the newline is part of the length we can just use length-prefixed-message which just reads a varint prefixed message from a stream
<mafintosh>
daviddias: so we'd just need to wrap that in a simple through stream
<daviddias>
reading length-prefixed-message. Your idea is to wrap in a through stream to do the byte count for the writer and also have a thing to declare the header of the stream (which is just one more write in the beginning), right? And then on multistream-select, we will just need a way to get those headers and see if the last one writing wasn't the one writing now,
<daviddias>
also push the header again plus unique Id (for SPDY streams for example)
<daviddias>
doing that :)
guest449 has joined #ipfs
guest4491 has quit [Ping timeout: 255 seconds]
inconshreveable has joined #ipfs
Encrypt has quit [Quit: Quitte]
chriscool has joined #ipfs
guest4491 has joined #ipfs
guest449 has quit [Ping timeout: 246 seconds]
williamcotton has quit [Ping timeout: 272 seconds]
Taek has quit [Quit: No Ping reply in 180 seconds.]
Taek has joined #ipfs
guest4491 has quit [Remote host closed the connection]
williamcotton has joined #ipfs
grncdr has joined #ipfs
grncdr has quit [Ping timeout: 256 seconds]
grncdr has joined #ipfs
inconshr_ has joined #ipfs
inconshreveable has quit [Ping timeout: 265 seconds]
grncdr has quit [Quit: Leaving.]
Wallacoloo has joined #ipfs
grncdr has joined #ipfs
lohkey has quit [Remote host closed the connection]
vonzipper has quit [Remote host closed the connection]
insanity54 has quit [Remote host closed the connection]
Luzifer has quit [Remote host closed the connection]
jbenet has quit [Remote host closed the connection]
mappum has quit [Remote host closed the connection]
<daviddias>
btw mafintosh , https://github.com/mafintosh/length-prefixed-message is pretty cool :) Will you publish it on npm? Would like to avoid having to have git dependencies. Also I'm looking in a way to make it support uint64 to make it compatible with the go encoding/binary we are using
<tperson>
Is that the package he was talking about on that issue?
Wallacoloo has quit [Ping timeout: 256 seconds]
<tperson>
Doesn't look like he owns it though, it's forked from sorribas
<daviddias>
tperson yes it is. I'm just creating a stream wrapper, add a way to stream headers and call it node-multistream to conform with the spec.
<daviddias>
tperson true, but sorribas implementation is has a different way of working
williamcotton has joined #ipfs
williamcotton has quit [Ping timeout: 250 seconds]
niran has joined #ipfs
<bret>
daviddias: congrats on completion your thesis
<bret>
completing*
<daviddias>
thank you bret :)
<bret>
are you still working at &yet?
<daviddias>
not anymore, left +- one month ago
<bret>
sindresorhus has joined #ipfs
Encrypt has joined #ipfs
oleavr has joined #ipfs
insanity54 has joined #ipfs
jbenet has joined #ipfs
Bioblaze has quit [Remote host closed the connection]
<tperson>
If &yet wasn't in the Tri-Cities I would of probably applied there.
lohkey has joined #ipfs
mafintosh has joined #ipfs
prosodyContext has joined #ipfs
tibor has joined #ipfs
<kbala>
whyrusleeping: would you like help with the packaging tool you mentioned?
<kyledrake>
I'm trying to figure out if there's a simple way to download an entire site into a directory using it's IPFS directory hash.
<jbenet>
kyledrake: ipfs get -o desiredName <hash>
<jbenet>
or <path>
<jbenet>
bret: yeah, we've some. i started a company to develop it and other protocols. http://ipn.io
Luzifer has joined #ipfs
vonzipper has joined #ipfs
grncdr has quit [Quit: Leaving.]
<jbenet>
daviddias mafintosh that should work-- though need to make sure (a) the varint style matches, (b) we only use that during the headers-- nested protocols will do their own thing / msg prefixing.
grncdr has joined #ipfs
www has joined #ipfs
<daviddias>
ah! I was seeing it as two layers, where multistream would do the first unwrap
<jbenet>
daviddias: yeah-- we could do length-prefixed everything-- i have that as a WIP in https://github.com/jbenet/multistream/tree/master/msg-stream -- but some protocols do their own packetizing-- i.e. dont need to varint prefix http2, spdy, or QUIC streams, etc.
<jbenet>
so someone will complain about double length wrapping
<jbenet>
so i opted for making "multistream" just force the header and that's it.
Encrypt has quit [Quit: Quitte]
<daviddias>
So, how the receiver endpoint, since once the header is sent, there is no way to tell when will that stream segment will end, or we just keep unwrapping (which will result in some weird formats) everything till something looks like a new header?
<jbenet>
daviddias: yeah we can't do EOF with base multistream :( -- it took me a while to come to terms with that -- packetizing (or cryptographic magic values, as some protocols do) is the only way to know when a stream has ended from above (i.e. "from below" = the children just exits and yields back control).
<jbenet>
the bad thing about magic values (and i started on this) is that it is error prone-- no longer universal. if you happen to pipe part of the same stream inside (say as debug info) you may accidentally trigger weird unwrapping
EricJ2190 has joined #ipfs
Wallacoloo has joined #ipfs
<jbenet>
yeah, so it is very unlikely that a protocol header would ever really _need_ a varint. (if you need more than uint64 bytes for a header, probably doing it wrong). i just tend to prefer forward-safe choices. -- we could abandon it in this case, i think whyrusleeping prefers fixed size here too. (though with a varint, most headers will only be one byte.
<jbenet>
but that's not a huge win because the rest of the header will be pretty verbose)
<daviddias>
yeah, then we would have to have transform streams in the middle to encode bad chars. Wouldn't an extra byte with a flag for "header", resolve the issue? Notifying the multistream-select that "is time to select"
<whyrusleeping>
whats going on here?
therealplato has quit [Ping timeout: 258 seconds]
<jbenet>
not seeing that o/ -- i see it as "multistream-select" is a child protocol like any other, it just happens to know how to nest other protocols. take a look at the muxer whyrusleeping wrote
<mafintosh>
daviddias: checkout sorribas/length-prefixed-message instead of my fork. That uses varint prefixed messages
robmyers has joined #ipfs
<daviddias>
thanks jbenet mafintosh , will look into it first then
Blame has joined #ipfs
rht__ has quit [Quit: Connection closed for inactivity]
Wallacoloo has quit [Quit: Leaving.]
therealplato has joined #ipfs
<ipfsbot>
[go-ipfs] chriscool created update-cheggaaa-pb (+1 new commit): http://git.io/vIYAi
<ipfsbot>
go-ipfs/update-cheggaaa-pb 24de361 Christian Couder: Godeps: update cheggaaa/pb to the latest version...
<kbala>
jbenet: what should i aim to do now? should i just write the test scenario scripts for iptb?
<whyrusleeping>
kbala: thats one way you could start going about things
<whyrusleeping>
and might be a good course of action
<whyrusleeping>
another thing would be to look at extracting the bitswap code so you can just create a bunch of bitswap instances and simulate different network conditions
<kbala>
got it, i'll get to work on those
grncdr has quit [Quit: Leaving.]
chriscool has quit [Ping timeout: 272 seconds]
grncdr has joined #ipfs
Bioblaze has joined #ipfs
therealplato has quit [Read error: Connection reset by peer]
therealplato has joined #ipfs
<whyrusleeping>
kbala, the first thing we want is some fine grained tests around expected bitswap behavior
<kbala>
whyrusleeping: what would an example test be?
<jbenet>
ideally we want a scripting tool, kind of like the dhtHell scripts
<jbenet>
so that it's trivial to write complicated scenarios
<jbenet>
whyrusleeping can you point kbala to good examples of that?
<rschulman>
jbenet: Yeah, but will it be any faster dling from you than from ubuntu.com? :)
flugsio has joined #ipfs
atrapa has joined #ipfs
atrapa has quit [Client Quit]
<Luzifer>
wow. this time 12h time until the server is blocked :(
<whyrusleeping>
jbenet: yeah
<whyrusleeping>
(re: my patch/patch PR)
atrapado has quit [Quit: Leaving]
elima_ has quit [Ping timeout: 265 seconds]
<jbenet>
whyrusleeping: tests so it doesnt happen again? i wanna merge it cause i wanna use it
<jbenet>
rschulman: probably not.
<whyrusleeping>
i can get to tests sometime tomorrow, busy today
<jbenet>
Luzifer: you mean unblocked?
<jbenet>
Luzifer: would it help for me to apologize to them and tell them we're working on it?
<Luzifer>
jbenet: nope. 12h to fix the problem or the server will get disconnected from the network… I already put in a statement about what happened and referenced the last issue…
<Luzifer>
(disconnected = blackholed in the core-router)
<whyrusleeping>
i dont understand why we are trying to dial so much...
<Luzifer>
I don't understand 604 connects within 2m20s
<whyrusleeping>
if your node is already fully connected.. and its idle
<whyrusleeping>
thats just absurd
<whyrusleeping>
something is broken in the dialing code...
<whyrusleeping>
thats blatantly a bug in something
<whyrusleeping>
you dial the same address and fail multiple times
<whyrusleeping>
within a minute
<jbenet>
It's symmetric nats.
therealplato has quit [Ping timeout: 264 seconds]
<jbenet>
and yeah-- we should do that o/
<jbenet>
that's pretty silly.
<Luzifer>
that container is connected to 37 peers all over the world (increasing) so no need to find an initial network or something...
therealplato1 has quit [Ping timeout: 265 seconds]
<Luzifer>
at least the successful recheck gives me another 10h time... I hope my statement will get accepted again… otherwise I need to take down the container until we got a solution :(
<jbenet>
Luzifer: its not about an initial network, it's about finding the shortest connection to a peer. i've detailed the problem in that issue already and the steps to fix it, we just need to take them.
<jbenet>
(there are probably other things to fix too, like not dialing same addresses over and over)
inconshreveable has quit [Ping timeout: 265 seconds]
<jbenet>
but whats on the issue should really help already.
<Luzifer>
Hope so...
<jbenet>
Luzifer: sinking the iptables like filter into go-ipfs will give the strongest protection. we can try to increase prio, but we're very overloaded with other important thigns
therealplato has joined #ipfs
* whyrusleeping
tries to remember everything on his TODO list
Wallacoloo has quit [Ping timeout: 265 seconds]
<Luzifer>
I gave that up... My list is too big to remember. Some parts which are important are nagging me automatically and the rest... The rest is a huge pile of tasks slowly migrating to a pile of dust...
<Luzifer>
And then there are tasks quite important but that big I don't even start to work on it and it's getting worse every time I skip them... :(