Send individual nodes to daemon

[ehmry]

I wanted to be able to send data to a daemon in a way that does not require the daemon have access to the data on local disk, so I added a command to core for adding a block over RPC.

https://github.com/ehmry/go-ipfs/compare/add_node

There are a few reasons I wanted this,

• I would prefer my daemon run in restricted virtual filesystem space.
• I might be pushing data from a mobile machine to a more stationary seed node.
• I might be encrypting data in my application before publishing.

I've got a utilty that pushes nodes to a daemon, and another utilty for pulling them from a daemon.
So far I've only tested them by piping music in and out of them.

This is just rough draft of what I want, and a RFC.

On a side note, perhaps the RPC interface would be best wrapped in a more traditional manner so that success reponses can be differentiated from errors?

There is of course http://golang.org/pkg/net/rpc/jsonrpc/, though I'm not sure if its too Go centric to reimplent clients in something like javascript.

[whyrusleeping]

this could be pretty easily implemented as a flag to ipfs add, i.e.

echo "mydata" | ipfs add -i

where the 'i' flag could specify to read from 'stdin' and stream the block over.

[whyrusleeping]

Or even:

ipfs add --remote myfile.txt

could read in and send blocks as opposed to just sending the filename over

[ehmry]

For whatever reason on this branch 'ipfsadd' and 'ipfscat' can add and cat from a single machine, but the blocks don't propagate between peers. Whatever, its a proof-of-concept.

[jbenet]

good call, we'll need the API to allow adding blocks. Will be useful for #132 as well.

[llSourcell]

@ehmry protobuf > json http://blog.codeclimate.com/blog/2014/06/05/choose-protocol-buffers/

[whyrusleeping]

@llSourcell but allowing the user to choose is better than either on its own.

[ehmry]

I like the idea of perhaps a protobuf API on a plain socket and an JSON HTTP API.

[llSourcell]

@whyrusleeping true. @ehmry that would some ideal

[jbenet]

Please see #132 for API considerations. the APIs should allow format choice in both cases. (yes, also protobufs over http, and json over raw tcp)

[ehmry]

Superceded by #132