#ipfs

/

      • jbenet
        whyrusleeping so what are you trying to dial? how do you find the address?
      • whyrusleeping
        im providing an address, i just have a test program that creates two dht objects and tries to make them connect to eachother on the local host
      • jbenet
        In kademlia, FindNode returns the (id, ip, port) tuple. For us, it returns (nodeid, multiaddrs)
      • ahh
      • whyrusleeping
        i have "/ip4/127.0.0.1/tcp/1234"
      • jbenet
        just seed it with an id then
      • whyrusleeping
        okay
      • jbenet
        because we'll seldom end up in cases with an address and not an id
      • whyrusleeping
        cool
      • so how to we get an ID in the first place? like when were starting up
      • a public "tracker" type machine?
      • jbenet
        nodes should probably identify themselves on first connecting (meaning, send their public key, so you can hash it and see it's legitimate) but this could be optional (i.e. i could cache your public key after meeting you once, even if i disconnect, so this may make sense as a peer identity protocol to execute
      • whyrusleeping not quite, we need bootstrap nodes
      • whyrusleeping
        okay
      • that makes good sense actually...
      • jbenet
        well known nodes that we distribute addresses for. bootstrap is a problem for all these systems (bittorrent, bitcoin, etc), but luckily, it's easy enough to have a well known list of bootstrap nodes
      • rictic has quit
      • whyrusleeping
        yeah, and then having nodes identify upon connection answers the other half of my question
      • thanks!
      • jbenet
        yep. it probably makes sense to put that into an "identify" module or something, rather than the swarm object
      • (swarm will be shared by ipfs core)
      • by/through
      • whyrusleeping
        okay, i actually was just sketching it out in the dht thinking that it was a terrible place to have it
      • jbenet
        hahah
      • yeah, would it be useful for me to make a better sketch of where i think these things make sense to go?
      • obviously always up for debate to get to the best ideas,
      • whyrusleeping
        i think an 'identify' package makes the best sense
      • rictic joined the channel
      • toqueteos
        there it goes jbenet a little contribution, i found that doing the craziest thing haha
      • whyrusleeping
        jbenet: i think im going to break the swarm.Dial method into two methods, so we can perform the identification before adding it into the swarms connection list and starting the fanIn
      • otherwise we have to figure out how to work through the swarm channels to get the messages during the identification process
      • toqueteos
        whyrusleeping: maybe a "chan chan Whatever" is the solution there
      • whyrusleeping
        ah nevermind... i can use the other Dial method to acheive what i want... lol
      • jbenet
        whyrusleeping it's possible to keep the unidentified connections separately, and only add them to the swarm once they're verified
      • *shrug*
      • whyrusleeping
        yeah, thats what im gonna do now
      • toqueteos
        jbenet am i missing something?
      • there's nothing wrong with 0x00 as appcode
      • but the AppCode func checks "code > 0" which doesn't catch 0x00
      • jbenet
        OH
      • derp
      • i read it the exact opposite way
      • toqueteos
        hahaha
      • no problem at all
      • jbenet
        merged!
      • >.< the node impl has the same bug https://github.com/jbenet/node-multihash/blob/m...
      • I'll fix it later cause i need to republish to npm
      • toqueteos
        well.. it's all thanks to goconvey and test coverage
      • jbenet
        I'm sick of manual semver, we need static analysis semver
      • toqueteos
        for repo version you say?
      • jbenet
        for package version
      • like
      • go doesn't have a pm, and so people use go deps and similar things
      • but in node one publishes things to npm
      • at a particular version
      • toqueteos
        oh, for the package.json, isn't there any auto hook for that? or some uberhipster service for that?
      • jbenet
        semver is nice because it encodes important API information into the versioning
      • probably
      • toqueteos
        there's some similar thing for go http://stackoverflow.com/questions/11354518/gol...
      • jbenet
        and we could do static analysis to generate semver automatically.
      • toqueteos
        but it's quite.. well "hacky"
      • jbenet
        i want to live in a world where all code is published automatically and versioned semantically and dependencies are managed for you-- soooooooon.
      • toqueteos
        second time i see a gif on github
      • wouldn't that system explode into an awful lot of urls with modifiers?
      • jbenet
        maybe, it's not completely specified yet, but there's something there that I'll be trying out once we have a solid ipfs live
      • much more important stuff to do atm.
      • ipfsbot
        [go-ipfs] whyrusleeping pushed 1 new commit to dht: http://git.io/0rmpmw
      • go-ipfs/dht 9a4fe8c Jeromy Johnson: begin planning of identification process
      • whyrusleeping
        ^^^ changing workstations ^^^
      • JohnLaibach joined the channel
      • toqueteos has quit
      • tperson_ joined the channel
      • lewiscowper has quit
      • rictic_ joined the channel
      • lewiscowper joined the channel
      • rictic has quit
      • rictic_ is now known as rictic
      • hmm... interesting side effect. if a node connects to you and you try to get its address, you wont get any useful information, because your computer will pick some random port to connect on
      • so building a peer object from a connection accepted through a listener is kindof obnoxious
      • bren2010
        whyrusleeping, doesn't Kademlia use UDP? Why would the port change? o.0
      • whyrusleeping
        kademlia might use udp, but ipfs can use any protocol
      • were starting with tcp, because... tcp
      • bren2010
        ... Why not just use UDP?
      • whyrusleeping
        because it does *really* matter that we resolve an address at this point, and using tcp means changing a lot of code i didnt want to touch yet
      • its just a strange thing were going to have to take into account later
      • using udp*
      • JohnLaibach has quit
      • JohnLaibach joined the channel
      • bren2010
        I'm really sorry, but I still don't follow. =/
      • whyrusleeping
        so, when i dial another node, that nodes listener generates a net.Conn, right?
      • calling RemoteAddr on that net.Conn yields the address and port that I connected from, which is randomly chosen by my operating system
      • bren2010
        Well.. no. Not with UDP at least
      • JohnLaibach has quit
      • You have one UDP conn that you can read from many addresses / write to many addresses.
      • whyrusleeping
        yeah, i know thats how udp works
      • im saying im working with tcp
      • so in the case of TCP, checking the remote addr is pointless
      • as for "why not use UDP", the ipfs dht uses multiaddrs for communication, this allows us to communicate over a larger variety of protocols
      • jbenet chose to start with tcp
      • bren2010
        Using multihashes is already dodgy. Why multiaddrs? =\
      • whyrusleeping shrugs
      • whyrusleeping
        extensibility?
      • bren2010
        It's not like UDP is platform specific or going to be gone in the near future
      • I have kind of the same issue with using multihashes: sha256 is rated secure for the next 200 years. If that's not enough, you can use sha512.
      • whyrusleeping
        youre gonna have to ask jbenet that, i got involved after those decisions were amde
      • fiatjaf has quit
      • tperson_ has quit
      • rictic has quit
      • chas has quit
      • came across a strange error... http://play.golang.org/p/_GH8rig2fu
      • jbenet
        whyrusleeping: on tcp port, ah yeah. There should be a way to bind the TCP port before you send out. Not sure if Go does this for you, but it is possible to multiplex streams over the same TCP port. Though not sure if you can both accept+dial in linux. It's not _typically_ used this way, but the network stack should be able to do it.
      • bren2010: on UDP, it's not enough. UDP doesn't connect all nodes. Even with ICE (STUN + TURN) there are many connection pairs that are impossible. Moreover, the real transport target is WebRTC, which sometimes connects over TCP. IPFS is to be transport independent. There are some networks where nodes don't even use UDP (sit on top of IP directly). You might
      • think that this is yak shaving, but this is the type of thing that makes protocols non-universal. And I'm going for a universal thing that can be used _anywhere_.
      • bren2010 multiaddr allows us to speak many transports without having to specifically implement support for that everywhere.
      • compare this to --say -- traditional bittorrent implementations which don't have a port in the address spec (started with only TCP), so they don't know for sure which protocol to start with. Today, clients that speak both TCP + UDP try both. This also brings itself to bear in picking candidates for ICE. This is all brain damaged. make the protocols used
      • explicit in the address.
      • The space is not an issue, because multiaddr binary packs -- most protocols use string addresses.
      • (and many good protocols today are using string urls, like udp://<host>:<port>, but this falls short of a universal format, which multiaddr is. Yes, i'm changing a lot of things, but I'm making things better and none of these affect adoption, it just means a bit more code on our end.)
      • bren2010 what's dodgy about multihash or multiaddr?
      • i'm willing to take a bet that sha256 is broken before 200 years pass.
      • JohnLaibach joined the channel
      • or sha256
      • bren2010 i think a general thing to keep in mind here is that once you go deep enough into the literature, and into building systems, there comes a point when you realize lots of things are hacks upon hacks -- or just failed short of something solid. protocols weren't handed down from the gods, they were made by people, and people make mistakes. I've noticed
      • some, and i'm doing my part to clean up some of this mess
      • JohnLaibach has quit
      • tilgovi joined the channel
      • JohnLaibach joined the channel
      • JohnLaibach has quit
      • amiller has quit
      • amiller joined the channel
      • tilgovi has quit
      • tilgovi joined the channel
      • tilgovi has quit
      • JohnLaibach joined the channel
      • JohnLaibach has quit
      • mikelevins has quit
      • ipfsbot
        [go-ipfs] jbenet pushed 3 new commits to master: http://git.io/L_Kp1g
      • go-ipfs/master dcd0bac verokarhu: disable mount command on windows for now
      • go-ipfs/master fef46e4 verokarhu: mount command on windows returns an error instead of nil and adjusted unix-only code
      • go-ipfs/master 41a725c Juan Batiz-Benet: Merge pull request #21 from verokarhu/master...
      • toqueteos joined the channel
      • JohnLaibach joined the channel
      • JohnLaibach has quit
      • JohnLaibach joined the channel
      • JohnLaibach has quit
      • JohnLaibach joined the channel
      • JohnLaibach has quit
      • JohnLaibach joined the channel