there really isn't any good way to do a table with checkboxes inside the cells in Github flavored markdown.

True. You have to get creative with emojis, see for example:

• Awesome Async Crypto + Less magic to 'run in the browser' ipfs/js-ipfs#485
• https://github.com/ipfs/ipfs/blob/master/IMPLEMENTATION_STATUS.md

@mgoelzer you missed porting:

• https://github.com/ipfs/ipfs/blob/master/ROADMAP-TO-1.0.0.md#ipfs-dht
• https://github.com/ipfs/ipfs/blob/master/ROADMAP-TO-1.0.0.md#ipfs-pubsub

@mgoelzer any ETA to get this doc finished? I mean, the first pass with the table and all the content items that belong to libp2p so that we can iterate over it.

@diasdavid What do you think about merging in the current state so we can iterate? I fixed up all the fruits and table structure. The initial description section lists some known deficiencies in the current doc.

Alternative is to keep iterating in this PR. Either works for me.

Also, these items are intentionally missing:

• https://github.com/ipfs/ipfs/blob/master/ROADMAP-TO-1.0.0.md#ipfs-dht
• https://github.com/ipfs/ipfs/blob/master/ROADMAP-TO-1.0.0.md#ipfs-pubsub

They seem like IPFS milestones, and I'm trying to segregate IPFS stuff from pure libp2p stuff. I left those in the IPFS requirements doc.

@mgoelzer @diasdavid a few thoughts:

1. By Node, do we mean Host in libp2p terminology?
2. Personally I consider the enumerated technologies/protocols listed as concrete implementations rather than interfaces.
3. Do we have criteria or a definition for done for each module? If not, I wonder if the term available would be more appropriate, as it conveys that an implementation exists, but does not set any expectations on feature completeness. To me, done also implies some kind of closure, which may be applicable in the context of specific feature sets we aim for with 1.0 for each module.

By Node, do we mean Host in libp2p terminology?

It is actually the other way. Host is a legacy term, the correct term is libp2p Node.

Personally I consider the enumerated technologies/protocols listed as concrete implementations rather than interfaces.

Agreed. Same that I was going with #39 (comment)

[screenshot]

@diasdavid Yes, I had the same reaction as you. impl(emented) is already implied for every row in the table, unless otherwise stated, and the word interfaces doesn't make much sense in the section headings. I (intentionally) left those alone because I wanted a verbatim copy of the original text in https://github.com/mgoelzer/ipfs/blob/master/ROADMAP-TO-1.0.0.md, thus making this PR a pure move-and-reformat with no change in semantics, which tend to be non-controversial.

That said, if the terms have no meaning to you, then they probably aren't of significance to anyone else. I'm fine with taking them out.

@raulk

Do we have criteria or a definition for done

I suppose nothing is ever truly "done" in software, but I think of it as meaning we have an implementation that is suitable for downstreams to use in production software. If these modules were independently SemVer2 versioned, we could use that to imply an additional statement about our commitment not to break backwards compat, but the libp2p project is not at that stage of maturity yet. There's a lot of fundamental innovation that still needs to happen.

wonder if the term available would be more appropriate

I totally agree with the principle of what you're saying, and I'm very tempted to make the change to Available, but the Done/InProgress/Missing/NotPlanned emoji convention is being used elsewhere in PL projects. I'm somewhat reluctant to redefine one term here. I don't have super strong feelings though.

By Node, do we mean Host in libp2p terminology?

Yes, they are the same. This is a long standing problem, and unfortunately it's not the only place where you'll find language implementation divergence as you dig in deeper. Juan has been suggesting for a while that we adopt a standardized interface (e.g., see here), specified in a golang-like DSL, but it's harder than it sounds because different languages have fundamentally different paradigms and idioms. An example would be channels in Go vs callbacks in JS vs Sync/Send traits and std::thread in Rust, all of which achieve a similar goal (concurrency, or the appearance of it in single-threaded runtimes) but are more than just syntactically different; there's an actual conceptual difference. So, this turns out to be a somewhat hard coordination problem.

I pushed a new commit to remove "interface", "impl" and "implementation" per #39 (comment).

Did not change "Node" to "Host" per #39 (comment)

Did not change "Done" to "Available" based on consistency-with-IPFS argument in #39 (comment) (I'm open to changing this later though)

I'd like to merge this, merge ipfs/ipfs#334, and then we can iterate on this one and let IPFS iterate on its analogous list. In subsequent PRs, I'd like to (1) verify the accuracy of the fruits, (2) fill in Performance Milestones TODO item with 10^6 and 10^9 node goals, and (2) add some docs requirements line items.

@diasdavid Forgot to respond to this:

@mgoelzer you missed porting:
https://github.com/ipfs/ipfs/blob/master/ROADMAP-TO-1.0.0.md#ipfs-dht
https://github.com/ipfs/ipfs/blob/master/ROADMAP-TO-1.0.0.md#ipfs-pubsub

I have another branch that adds on to this PR where I have included those. My next PR will be based off of that, with some additional stuff mentioned above.