IPFS Node Init: 1st Draft #83
Conversation
|
|
||
| ```json | ||
| "Bootstrap": [ | ||
| // mars.i.ipfs.io |
There was a problem hiding this comment.
note that comments are not valid JSON (unfortunately)
|
This looks pretty sweet @noffle. Really throughout specification of the init process, perfect to be followed by other implementations. The building blocks to implement this in JS are there (peer-info, peer-id, ipfs-repo that works in Node.js and the browser), let me know if you encounter any obstacle :) |
| "Version": { | ||
| "AutoUpdate": "minor", | ||
| "Check": "error", | ||
| "CheckPeriod": "172800000000000", // 48 hours |
There was a problem hiding this comment.
those three values arent currently used. should either do something with them or remove them
|
This looks good to me! thanks for documenting |
| -f|--force: whether to overwrite an existing repo config. Defaults to false. | ||
| -e|--empty-repo: whether to add+pin ipfs info help files to the repo. Defaults to false. | ||
| -b|--bits: # of bits to use in the generated RSA private key. Defaults to 2048. | ||
| ``` |
There was a problem hiding this comment.
there's an important difference between:
- an ipfs node (logical idea of what an ipfs node is)
- a commandline tool that inits an ipfs node (a projection of the abstract concept into a concrete implementation, in this case a cli tool based one)
the upshot is that we may need two docs:
- one doc that describes initializing an ipfs node, namely might specify "options", but not "commandline flags". for example,
IPFS_PATHenv var would NOT belong here. (may be too abstract for this doc). - a doc that describes how initializing an ipfs node happens through cli tools like go-ipfs and js-ipfs (more this doc)
There was a problem hiding this comment.
this is similar to how we have "a repo spec" (abstract) and an "fs-repo spec" (concrete)
|
good idea to document all this! we need to:
if we dont mean ALL impls to use it, only go-ipfs, i dont think it is very useful to have this separate from the go-ipfs codebase. if its go-ipfs specific, it should be represented by code and tests and maybe comments. |
|
|
||
| #### Bootstrap Peers | ||
|
|
||
| The default bootstrap peers form the following config tree: |
There was a problem hiding this comment.
Would be good to have a short writeup about what these are -- servers or nodes hosted by IPFS.
I sort of asked about this in another comment, but where are the points of differentiation between a logical node and [whatever this doc currently describes]?
Agreed.
Agreed. I intend for this document to generalize to any IPFS implementation. |
|
Thanks everyone. Based on @jbenet's comments, it sounds like this doc needs to be more abstract: covering initialization on a generic IPFS node that may/may not have things like a CLI or RSA keypairs or even standard out. |
|
I've integrated this doc as a comment for now, since it is too concrete to be a general "IPFS Node Init" specification. It however serves well enough as a "here's how to do init if you're writing an IPFS implementation that is very go-ipfs-like (unixfs, has a CLI). |
Heya! This aims to document how to initialize an IPFS node, based on the de facto code in go-ipfs. I'd love reviews & comments in particular from