#ipfs

/

      • inconshreveable has quit
      • inconshreveable joined the channel
      • inconshreveable has quit
      • inconshreveable joined the channel
      • inconshreveable has quit
      • siraj joined the channel
      • inconshreveable joined the channel
      • inconshreveable has quit
      • inconshreveable joined the channel
      • siraj has quit
      • siraj joined the channel
      • inconshreveable has quit
      • inconshreveable joined the channel
      • inconshr_ joined the channel
      • inconshreveable has quit
      • pfraze has quit
      • inconshr_ has quit
      • inconshreveable joined the channel
      • inconshr_ joined the channel
      • inconshreveable has quit
      • siraj has quit
      • inconshr_ has quit
      • mildred joined the channel
      • siraj joined the channel
      • tilgovi joined the channel
      • ipfsbot
        [go-ipfs] jbenet force-pushed ipns from 0094840 to 26a481a: http://git.io/lCscKA
      • go-ipfs/ipns 235a767 Jeromy: implement namesys resolvers (thanks to bren2010 for dns and proquint)
      • go-ipfs/ipns b5fd949 Jeromy: fixes to make interface more usable
      • go-ipfs/ipns da1890e Jeromy: add run command
      • siraj has quit
      • tilgovi has quit
      • siraj joined the channel
      • siraj has quit
      • aweiteka joined the channel
      • [go-ipfs] jbenet pushed 8 new commits to ipns: http://git.io/ik8ftg
      • go-ipfs/ipns 728f17d Juan Batiz-Benet: cmd/ipfs/pin.go now uses MakeCommand...
      • go-ipfs/ipns 14a384d Juan Batiz-Benet: pin: add depth arg.
      • go-ipfs/ipns 1cfb0ff Juan Batiz-Benet: command output nit
      • flugsio joined the channel
      • siraj joined the channel
      • siraj has quit
      • mildred has quit
      • mildred joined the channel
      • aweiteka joined the channel
      • feross has quit
      • mappum has quit
      • mappum joined the channel
      • feross joined the channel
      • pfraze joined the channel
      • inconshreveable joined the channel
      • inconshr_ joined the channel
      • inconshr_ has quit
      • inconshreveable has quit
      • inconshreveable joined the channel
      • inconshreveable has quit
      • bengl has quit
      • bengl joined the channel
      • mildred has quit
      • aweiteka has quit
      • siraj joined the channel
      • inconshreveable joined the channel
      • jdiez has quit
      • jdiez joined the channel
      • jdiez is now known as Guest372
      • aweiteka joined the channel
      • domanic joined the channel
      • siraj has quit
      • siraj joined the channel
      • siraj
        string manipulation is much easier in go than objC.
      • ...everything is easier in go than objC lol
      • aweiteka has quit
      • aweiteka joined the channel
      • domanic has quit
      • jbenet has quit
      • mappum has quit
      • jbenet joined the channel
      • mappum joined the channel
      • mafintosh has quit
      • mikolalysenko has quit
      • ogd has quit
      • mafintosh_ joined the channel
      • ogd joined the channel
      • mikolalysenko_ joined the channel
      • wscott joined the channel
      • wscott
        hips9(puss
      • wscott has left the channel
      • inconshreveable has quit
      • domanic joined the channel
      • mafintosh_ is now known as mafintosh
      • mafintosh has quit
      • mafintosh_ joined the channel
      • m3s has quit
      • m3s joined the channel
      • whyrusleeping
        jbenet: on the topic of having dag nodes be mutable...
      • do you want to have the interfaces for mutable vs immutable?
      • So, would the DAG service return ImmutableNodes and then if you have a mutable node, can you get a 'mutable copy' from it?
      • jbenet
        yeah. And moreover once it becomes immutable, should not be able to change it underneath you.
      • Yeah, should be able to construct one from the other
      • whyrusleeping
        okay
      • this will be fun...
      • lol
      • jbenet
        (And could use same underlying data, though probably with copy on write or something)
      • whyrusleeping
        hmm... okay
      • jbenet
        (Copy on write may be overkill might be easiest to just copy over data once when transitioning
      • func (n *mutableNode) Immutable() Node { ... Construct immutableNode, copy all data ... }
      • And, Node interface is immutable, backed by immutableNode struct or whatever
      • (Could be backed by the same struct as long as the interfaces differ and there's a copy when making immutable)
      • whyrusleeping
        alright, ill sketch it out and see how it does
      • mafintosh_ is now known as mafintosh
      • inconshreveable joined the channel
      • jbenet: so, if i have a mutable node, and i want to add a child, should that child be of type Mutable?
      • or should that tree already be set
      • ?
      • mappum
        what's this about mutable nodes? how will that work?
      • whyrusleeping
        theyre just a tree, i can modify the tree in memory
      • nothing in ipfs is mutable, but in ipns, things are mutable
      • mappum
        ah, i see
      • jbenet
        And these are just to help construct the immutable final objects
      • Hm yeah probably two different trees altogether
      • whyrusleeping
        jbenet: we will also need mutable vs immutable links
      • jbenet
        Though... Thinking about it more, what's the exact set of ops that need to happen on a node such that it has to be mutable?
      • (This is getting really complex, so I question the real need for them)
      • Like say we're on ipns and we have an ipfs node and we can retrieve (immutable) nodes from it, where do we need the mutable nodes
      • ladekjaer has quit
      • whyrusleeping
        do you want to be able to edit files inside of /ipns/local?
      • i need to be able to change the data in the node and change its links
      • jbenet
        Why can't we do immutable nodes and construct new ones only on those parts that have changed? (Like git)
      • Constructing objs and copying a few buffers shouldn't be fine re: perf.
      • ladekjaer joined the channel
      • inconshreveable has quit
      • inconshreveable joined the channel
      • siraj
        @jbenet that seems like a better idea, having mutable and immutable nodes can quickly get confusing.
      • Immutable nodes should be like commit objects IMO
      • its easier to think of them that way
      • aweiteka has quit
      • inconshreveable has quit
      • jbenet
        siraj: that doesnt make sense to me-- what do you mean?
      • inconshreveable joined the channel
      • mildred joined the channel
      • siraj
        Having a mutable node is necessary because in IPNS we want to be able to edit the nodes data/links, then we make an interface to convert it into an immutable node in IPFS. You were questioning the need for mutable nodes - i agree, what if in IPNS the mutable nodes were instead immutable, instead of modifying data/links in the node we just build another immutable node on top of it like a git commit object and everything points
      • to that (like a HEAD) when its created. then there wouldn't be a need for an interface to convert mutable > immutable. it would all be immutable.
      • of course if we're already too far in the design of mutable ipns/immutable ipfs then it doesn't matter that much. its more for the sake of simplicity
      • jbenet
        nono, that's _exactly_ how it happens underneath the hood and with the final objects
      • this discussion is merely about the datastructures in code used to generate the final objects
      • siraj
        ah gotcha
      • mildred has quit
      • whyrusleeping
        jbenet: we do really only update the parts that change
      • but if we have A->{B,C,D} (A is the parent of B,C,D)
      • and we change B, then we have to update A, (since its hash changes)
      • thats what the update function was for