zbyte64 has quit [Remote host closed the connection]
zbyte64 has joined #ipfs
zbyte64 has quit [Remote host closed the connection]
zbyte64 has joined #ipfs
captain_morgan has joined #ipfs
ulrichard has joined #ipfs
lkcl has quit [Ping timeout: 244 seconds]
captain_morgan has quit [Ping timeout: 244 seconds]
lkcl has joined #ipfs
captain_morgan has joined #ipfs
ygrek has quit [Ping timeout: 244 seconds]
reit has joined #ipfs
<haad>
thanks kumavis for debugging and the PRs!
jholden has joined #ipfs
kaotisk has quit [Read error: Connection reset by peer]
kaotisk has joined #ipfs
jholden has quit [Ping timeout: 245 seconds]
dignifiedquire has joined #ipfs
captain_morgan has quit [Ping timeout: 268 seconds]
bastianilso__ has joined #ipfs
zbyte64 has quit [Remote host closed the connection]
zbyte64 has joined #ipfs
zbyte64 has quit [Ping timeout: 248 seconds]
bastianilso__ has quit [Quit: bastianilso__]
chovy has quit [Ping timeout: 256 seconds]
bastianilso__ has joined #ipfs
polezaivsani has joined #ipfs
<polezaivsani>
good morning interplanetary folks!
mvollrath has quit [Ping timeout: 268 seconds]
ylp1 has joined #ipfs
ianopolous has quit [Ping timeout: 260 seconds]
s_kunk has quit [Ping timeout: 260 seconds]
<dignifiedquire>
good morning
kaotisk has quit [Read error: Connection reset by peer]
kaotisk has joined #ipfs
Mateon1 has joined #ipfs
rendar has joined #ipfs
<haad>
morning o/
<geoah>
good morning people! :D
maxlath has joined #ipfs
herzmeister has quit [Quit: Leaving]
herzmeister has joined #ipfs
<daviddias>
morning! :)
s_kunk has joined #ipfs
<daviddias>
haad: even better is to continue in IRC
<haad>
yeah :)
<daviddias>
even better ist o continue in github * :D
<haad>
daviddias: so do you have strong objection to keep it in a class
<daviddias>
nevertheless, quick answer is that you don't need a class to have access to other functions
<haad>
no, let's discuss here instead of github (it's too async, want to talk this through real-time :))
<daviddias>
haad: it is a style change, there is no benefits which sounds the bikeshed alert
<haad>
daviddias: it's not just a style change, it adds bunch of boilerplate
<daviddias>
and we use the module.exports pattern for functions everywhere
<haad>
daviddias: how would you export multiple functions? module.exports = { function1: {}, function2: {}, ... }?
<haad>
the benefit with a class is exactly that: the functions are wrapped in one place and they're all exported instead of having to wrap them into ^
<daviddias>
it is just an object, what I see as a pattern is exports = module.exports and then
<daviddias>
exports.create = function create () ...
<daviddias>
exports.func2 = ...
lindybrits has joined #ipfs
<dignifiedquire>
are you going to call new on it, and is it going to carry meaningful state?
<haad>
daviddias: that then requires the user to export everything individually which imo is not a good pattern for a module (ie. better way is to const DAGNode = require('dag-node) vs. create = require('dag-node).create)
<haad>
dignifiedquire: nope, hiding "new"
<haad>
dignifiedquire: ah nvm
<haad>
dignifiedquire: no, no new on it
<daviddias>
with what I'm saying (and what we do everywhere
<dignifiedquire>
then no class
<daviddias>
it still is const dagPB = require('ipld-dag-pb')
<daviddias>
and then you can get all of those functions under dagPB.factory for example
<daviddias>
this is just syntax, underneath is the same thing
jholden has joined #ipfs
<haad>
fine I'll change that
<haad>
it's unnecessary boilerplate imo
<haad>
daviddias: pushed
<haad>
daviddias: renamed dag-node-factory to dag-node-utils as "factory" doesn't make sense anymore
<dignifiedquire>
been thinking also lots about the documentation
<dignifiedquire>
need to make a decision about that soon, so we can start working onit
<daviddias>
haad was not happy with documentation.js, but I believe you have some ideas about theming, the best is to show people how it works in a project
<haad>
daviddias: pushed one more change to address the "util" comment.
<dignifiedquire>
I tried compiling but it really doesn't work for a serizalier that is so language specific
<dignifiedquire>
because it has has to understand all the javascript types
<daviddias>
dignifiedquire: brave!
<daviddias>
haad: checking ;)
<dignifiedquire>
I also made an experiment where I compiled rust-cbor to asm.js using emscripten
<dignifiedquire>
but as I said for cbor you really need to understand the types of the language
<haad>
daviddias: I think generally there's room for improvement to the APIs (IPLD and DAGNode's case) but I'm not gonna bikeshed it now as it's not gonna get us closer to releasing this.
<haad>
daviddias: I'd like to discuss the IPLD format API (https://github.com/ipld/interface-ipld-format#ipld-format-utils). is that the repo to open the issue in? is there a discussion somewhere where the API was discussed and the reasoning behind it?
<haad>
ok, pushed again. let's do one more round of CR daviddias dignifiedquire?
<daviddias>
haad: to change interface-ipld-format now is opening an issue and going through review of everyone
bastianilso__ has quit [Quit: bastianilso__]
sametsisartenep has joined #ipfs
<haad>
daviddias: ok, then before I do that, can you explain what you mean in this comment https://github.com/ipld/js-ipld-resolver/pull/60#issuecomment-254094608 with "I realized that we only (and benefit from) having an interface for serialize, deserialize and cid detached from the format class". I don't quite understand why the serialize/deserialize/cid are in util instead of the class?
<daviddias>
it is the only functions that IPLD Resolver needs
<daviddias>
and we don't want to have instances of every IPLD format
<daviddias>
some formats are just a binary packed thing
<daviddias>
and we need to operate over them in a 'functional like api'
<daviddias>
also deserialize never made sense to be part of the class
robattil1 has quit [Quit: WeeChat 1.6]
<haad>
but the resolver is coupled with the util, so it can't really do decoupled serialization?
<daviddias>
??
tmg has quit [Ping timeout: 256 seconds]
<haad>
for example in dag-pb, the resolver calls dag-pb.util.serialize
<haad>
so the resolver is couple with that specific serialization function
<daviddias>
yep
<haad>
*coupled
<daviddias>
because we know the type through the CID
<haad>
??
robattila256 has joined #ipfs
<haad>
daviddias: I don't understand what you're saying. from what I can tell: we need to now the type of the IPLD object in order to know what resolver to use, and the resolver is coupled with the format, so there's no need to tie the serialize/deserialize functions to the util API, ie. we don't use them anywhere else - just the resolver uses them. no?
<daviddias>
you can't assume that every IPLD Format is going to have a instance in JavaScript
<daviddias>
for example
<daviddias>
dag-cbor is just json objects
<daviddias>
if serialize and cid were in the class
<daviddias>
then every json object had to be converted to a class
<daviddias>
which is really annoying, people will want to add json objects direclty to IPFS
<daviddias>
which is one of the value offers
<haad>
wouldn't that go through a json resolver or "type"?
tmg has joined #ipfs
<daviddias>
if a thinglike dag-json existed
<daviddias>
we could use the same strategy that we have for dag-cbor
<daviddias>
or go with what you are saying and then say to everyone "hey, this is the dag-json format, but you can't use JSON, you have to create instances and put json inside of those instances, because we need to add some functions to it"
robattila256 has quit [Ping timeout: 268 seconds]
<haad>
hmmm... I'm missing a lot of context here, but all that doesn't sound right. are you saying that to add an IPLD object to IPFS, one can say add({ json data here }) or add(DAGNode.create(...)) or add(ETHBlock.create(data))?
<haad>
ie. the user defines what type of an object it is?
<daviddias>
yep
<daviddias>
with the dag API
<daviddias>
that is correct
<daviddias>
that is one of the main points of IPLD
<haad>
and how does IPLD then know which resolver/serializer to use inside add() function?
<daviddias>
you tell it
<haad>
how?
<daviddias>
on the function call
<haad>
I as a user tell it smth like add(DAGNode.create(data), "protocol buffers")?
<haad>
or add(ETHBlock.create(data), "ethereum bloc")?
<daviddias>
that is a c&p from go-ipfs cli on master
<haad>
ah ok, so basically if I wanted to put a json object, I would say add({...}, "json"), correct?
<daviddias>
you probably would do
<daviddias>
add(<json object>, 'dag-cbor')
<daviddias>
so that it gets serialized to cbor
<graffen>
Hi guys, quick question, when I pin add /ipns/<domain> and it pins the current hash, I'm guessing I have to pin again if I publish new stuff under that ipns?
<daviddias>
so it is faster in the wire
<daviddias>
graffen: yeah it doesn't follow the changes
<haad>
daviddias: ok so, but basically the user tells what type it is and IPFS will resolve/serialize it based on that, correct?
<daviddias>
graffen: might be a good feature to add though :)
<daviddias>
haad: yep
<haad>
daviddias: if so, then what prevents us having a json resolver? the user doesn't have to convert json to any other type, so I'm not quite following what you said earlier that it's really annoying that you have to convert them to another type
<graffen>
daviddias: Cool, thanks, I gathered as much. I tried looking through the github issues about the subject but there never really was any conclusion on how it would work exactly. Sorry for the interruption in your convo :)
<haad>
brb -->
<daviddias>
we can have a json resolver
<daviddias>
dag-json
<daviddias>
you can make it today
<daviddias>
and then when you serialize it
<daviddias>
you JSON.stringify, cause that is the 'wire format of json'
<daviddias>
it will be super slow, but you can do it, IPFS supports it all
<daviddias>
we favour cbor for having a 1:1 mapping to JSON
robattila256 has joined #ipfs
<daviddias>
so you get the convience and experience of JSON with a format that is good for passing on the wire that doesn't require a schema (like protobufs do)
<daviddias>
graffen: hey, no problem at all, feel free to ask questions anytime :)
maxlath has quit [Ping timeout: 248 seconds]
M-cameron has joined #ipfs
<graffen>
daviddias: Thanks!
<richardlitt>
morning friends
maxlath has joined #ipfs
Alaura has joined #ipfs
<daviddias>
good morning richardlitt :D
bastianilso__ has joined #ipfs
chovy has joined #ipfs
<Alaura>
Gday.
<victorbjelkholm>
graffen: worth to keep in mind is that you'll need to republish the IPNS record once every 24h if you want it to stick around
<victorbjelkholm>
good morning richardlitt! Still in japan?
<graffen>
victorbjelkholm: Ah, that's good to know! And also explains why my website had a habit of dropping off the internet :D I'll probably set up a cron job on that machine to keep re-publishing it just to be sure
<victorbjelkholm>
graffen: been there as well so thought I mentioned it :p
<graffen>
Pretty nifty though, just being able to publish my site from an rpi at home and have it show up on the internet without much more work than that. This IPFS thing is growing on me, for sure!
<bronger>
Am I right that there is one IPNS name per node, and from here, one can resolve more deeply with IPLD?
<polezaivsani>
bronger, yep, that's right
<Alaura>
Question, does anyone know how to fix IPFS crashing the router by chance?
<dignifiedquire>
daviddias: haad started testing out documentation for js-ipfs-api ^^
anonymuse has quit [Remote host closed the connection]
mildred1 has quit [Ping timeout: 268 seconds]
anonymuse has joined #ipfs
appa has quit [Ping timeout: 248 seconds]
zombu2 has quit [Ping timeout: 245 seconds]
kshlm[m] has joined #ipfs
pfrazee has joined #ipfs
anonymuse has quit [Ping timeout: 256 seconds]
zombu2 has joined #ipfs
ligi has joined #ipfs
zbyte64 has joined #ipfs
mildred1 has joined #ipfs
appa has joined #ipfs
ligi has quit [Client Quit]
maxlath has quit [Ping timeout: 256 seconds]
zbyte64 has quit [Ping timeout: 268 seconds]
<victorbjelkholm>
dignifiedquire: hohoho, looking good! Is generated or manually?
<victorbjelkholm>
seems manual, judging by the amount of methods
<victorbjelkholm>
looks sweet though
<dignifiedquire>
victorbjelkholm: it's jsdoc, so yes you have to manually add comments to the methods
maxlath has joined #ipfs
<dignifiedquire>
and in js-ipfs-api you have to override a lot of stuff manually because how the code is structured, but in situations where we use es6 classes for example the boilerplate is less
<pinbot>
now pinning /ipfs/Qma2GMXdMWLRvDxVh9H2U9VpxAQVhiDYgwL4a6CNSv527X
<dignifiedquire>
victorbjelkholm: it's a bit slow for me
<dignifiedquire>
victorbjelkholm: well we promised to deliver awesome api docs this quarter so I gotta get somewhere sooner rather than later :)
anonymuse has quit [Remote host closed the connection]
<pinbot>
[host 3] failed to grab refs for /ipfs/Qma2GMXdMWLRvDxVh9H2U9VpxAQVhiDYgwL4a6CNSv527X: Post http://[fc4e:5427:3cd0:cc4c:4770:25bb:a682:d06c]:5001/api/v0/refs?arg=/ipfs/Qma2GMXdMWLRvDxVh9H2U9VpxAQVhiDYgwL4a6CNSv527X&encoding=json&stream-channels=true&r=true&: read tcp [fc82:e2d7:bdff:45f3:dd95:bb22:fce9:1ffb]:42301->[fc4e:5427:3cd0:cc4c:4770:25bb:a682:d06c]:5001: read: connection reset by peer
<dignifiedquire>
will also work on the template to make it better, but for now I'm just trying to get a decent chunk of documentation so I have something to experiment with
<victorbjelkholm>
haha, true dat! Looking cool though, know a lot of people waiting for proper api docs
anonymuse has joined #ipfs
<victorbjelkholm>
btw, minor thing, just making sure I didn't miss anything but we said we're gonna do callbacks for our examples, right?
<dignifiedquire>
technically we should have examples for both given that we expose both apis
<dignifiedquire>
imo
<dignifiedquire>
but promise examples are shorter to write and easier to read.. ;)
<victorbjelkholm>
that would be a hassle though, we should chose one a stick with it and I have a feeling that people used to callbacks would have a harder time to convert examples from promises to callbacks than people used to using promises converting it to callbacks
taaem has joined #ipfs
<victorbjelkholm>
+ it would waste space on the page, if we need to duplicate the examples just because callbacks/promises
<haad>
dignifiedquire: that ^ looks better! did you find a way to describe what a Promise resolves to? that was one of the downsides I remember (telling it returns a Promise doesn't help much if you don't what that promise resolves to)
pfrazee has quit [Remote host closed the connection]
<dignifiedquire>
haad: yeah there is this gigantic thread on the jsdoc repo about promise support, no integrated solution yet though as far as I understand
<haad>
hmmm ok
pfrazee has joined #ipfs
<haad>
dignifiedquire: async all the things, then :) no more of that problem
<haad>
*await all the things
<dignifiedquire>
that still needs to describe promises
<dignifiedquire>
as that is the return value of those functions
<haad>
sure, but you could bypass that by pretending they don't return a promise but a value :)
<dignifiedquire>
lol
<dignifiedquire>
pretending much these days are we ;)
bastianilso__ has joined #ipfs
ulrichard has quit [Remote host closed the connection]
polezaivsani has quit [Remote host closed the connection]
Lahey is now known as ugjka
pfrazee has quit [Ping timeout: 260 seconds]
<haad>
with javascript you have to pretend everything
<dignifiedquire>
:D
<haad>
which reminds me, did you see, Visual Studio for Mac :O
<haad>
only c#, f# and asp.net support and mobile for now
<dignifiedquire>
yeah the language support didn't blow me away
<dignifiedquire>
and I switched back to emacs from vscode because it was eating way too much resources on my small macbook
<haad>
oh well, perhaps in the future
<haad>
haha
apiarian has joined #ipfs
<haad>
I went from 10+ years with VS to Sublime, used JetBrains IDE for a while, but using Sublime pretty much exclusively now. VS (at least on windows) is still the best editor I've ever used...
<haad>
and debugger
<dignifiedquire>
haad: as you can see by the link you can make javascript
<dignifiedquire>
*fast
anonymuse has quit [Remote host closed the connection]
<haad>
absolutely
<dignifiedquire>
yeah I still use vscode for the debugger especially with the new chrome debugger extension in node
<haad>
it's worth to load up vscode?
<haad>
I should try that
<dignifiedquire>
yeah
bastianilso__ has quit [Quit: bastianilso__]
PseudoNoob has joined #ipfs
<haad>
dignifiedquire: does the intellisense work well for js in vscode?
<dignifiedquire>
very well it uses typescript under the hood so you can improve it if you want to
<dignifiedquire>
with installing type defs
grosscol has joined #ipfs
zbyte64 has joined #ipfs
anonymuse has joined #ipfs
bastianilso__ has joined #ipfs
ylp1 has quit [Quit: Leaving.]
espadrine has quit [Ping timeout: 250 seconds]
kenshyx has joined #ipfs
domanic has quit [Ping timeout: 250 seconds]
zbyte64 has quit [Ping timeout: 260 seconds]
zbyte64 has joined #ipfs
ugjka is now known as therealugjka
<kenshyx>
hello, latest js-ipfs-api doesnt work on electron :)
<daviddias>
dignifiedquire: nice!
<daviddias>
looks good
<kenshyx>
because of sha3 package from multihashing-async
<daviddias>
I like the "opt",
<Igel>
whats this multihashing-async
<kenshyx>
a dependency used by a dependency of js-ipfs-api
<kenshyx>
:))
<Igel>
ok -- i'll peak
<daviddias>
lgel it is multihashing, but using async API so that it is WebCrypto friendly
<daviddias>
kenshyx: can you open an issue with a error log?
<kenshyx>
its not even throwing an error
<kenshyx>
i can't instantiate the ipfsApi
<kenshyx>
it blocks
zbyte64 has quit [Ping timeout: 260 seconds]
<daviddias>
kenshyx: which platform?
<kenshyx>
I played a bit with the imports and it seems that electron doesn't like that native module
<dignifiedquire>
kenshyx: multihashing-async relies on being run through a bundler that understands the "browser" field in package.json when used in the browser
<dignifiedquire>
kenshyx: so if you are using it in the renderer process you will have to use a bundler like webpack or browserify to preprocess it
<dignifiedquire>
if you use it in the node process it should work just fine
<kenshyx>
I'm using it from main process
<dignifiedquire>
hmm then file a bug with sha3 that sounds like a bug on their side then
<kenshyx>
I tried to rebuild all the native modules with the electron headers
<frood>
ola: not exactly what I'm looking for. Is there a way to put a link to an external resource in an ipld object, where I would typically put a hash link?
<frood>
and allow clients to decide whether/how to handle that?
pfrazee has quit [Remote host closed the connection]
pfrazee has joined #ipfs
ulrichard has quit [Remote host closed the connection]
se3000 has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
danemacmillan has left #ipfs ["WeeChat 1.0.1"]
pfrazee has quit [Ping timeout: 252 seconds]
Oatmeal has quit [Ping timeout: 240 seconds]
galois_d_ has joined #ipfs
Kane` has quit [Remote host closed the connection]
galois_dmz has quit [Ping timeout: 260 seconds]
maxlath has joined #ipfs
ylp has quit [Ping timeout: 260 seconds]
dmr has quit [Quit: Leaving]
ylp has joined #ipfs
zbyte64_ has joined #ipfs
zbyte64_ has quit [Read error: Connection reset by peer]
zbyte64 has quit [Ping timeout: 260 seconds]
zbyte64 has joined #ipfs
Mizzu has quit [Quit: WeeChat 1.6]
zbyte64 has quit [Ping timeout: 245 seconds]
se3000 has joined #ipfs
anonymuse has quit [Remote host closed the connection]
zbyte64 has joined #ipfs
bastianilso__ has quit [Quit: bastianilso__]
palkeo has quit [Quit: Konversation terminated!]
<lgierth>
whyrusleeping: know how we're using strings as path arguments to the new coreapi funcs? i'd like to accept cid.Cid and possibly other types for paths. one option is to accept interface{}, and let a new cid.Parse() or so func for making it into a proper Cid
zbyte64 has quit [Ping timeout: 265 seconds]
<whyrusleeping>
hrm... yeah
<lgierth>
does that sounds obviously stupid? it's kinda throwing out the type system of course
<whyrusleeping>
could accept an interface
<whyrusleeping>
then you could handle a string, a Path, and a Cid
<whyrusleeping>
type Ref interface{}
<lgierth>
and datastore keys or whatever
<whyrusleeping>
or something
<whyrusleeping>
datastore keys? that one seems weirder
<lgierth>
yeah that one probably doesn't make much sense
<lgierth>
anyhow, cool
Oatmeal has joined #ipfs
mildred3 has joined #ipfs
rgrinberg has joined #ipfs
mildred2 has quit [Ping timeout: 252 seconds]
<lgierth>
from a pure api standpoint, i think it will actually be useful in the future to be able to use arbitrary things as lookup keys
<lgierth>
implementations MUST understand cid and /ipfs paths
<lgierth>
implementations SHOULD understand /ipns (it implies having a namesys)
<lgierth>
ideally everything fits in cid obviously
<lgierth>
but who knows, coreapi impls could understand how to resolve a banana to a canonical cid
zbyte64_ has joined #ipfs
<lgierth>
or use some local service, etc.
<mguentner>
what is the purpose of "MimeType" in unixfs?
<lgierth>
mguentner: it's a placeholder for future handling of file metadata, but none of that is implemented
<lgierth>
i think there's timestamps and permissions in there too somewhere
<mguentner>
well...I am coming from the design flaw that (go-)ipfs has no execute bit which would be kinda useful when building a unixfs :).So I am trying to figure out how to add/fix that. Now this MimeType confused me a bit...
<lgierth>
yep executable bit is definitely the most painful to not have
<lgierth>
there was a discussion about unixfs metadata, let me see
<lgierth>
help is most welcome
<mguentner>
yeah...so the choice is either to build something nasty (tar) around the delivery system or instead fixing it where it should be fixed