Add high-level go-ipfs architecture diagram

[momack2]

No description provided.

[ericronne]

A few quick thots/qs, from one who has (less than?) a bare minimum of background on this system ...

• What do the colors signify? Do we need a key?
• Looks like the colored arrows are meant to map to the three talk bubbles? If so, it might help users if we reinforced that connection by using the exact colors throughout. Eg if the ipfs.get bubble was thickly outlined in the purple of the arrows — and also had a purple arrow connecting it to the API box — it might be easier to follow the flow.
• That said, if there's a way to better align with the ipfs brand colors, that'd be awesome. (See page 22 of the brand book)
• The diagram @daviddias referenced has the advantage of black-and-white simplicity, but color is handy for scannability and visual grouping.
• Most boxes may not require outlines. If you think they help, though, try using a darker version of the fill color. That will minimize noise.
• @momack2 if you wanted to walk me through this in a hangout at some point, i might be able to offer better-informed notions :)
• Do you plan to update the pubsub diagrams at some point as well, for consistency?

[momack2]

Thanks for the feedback, @ericronne! Updated the color palette to match the brand book (excepting the libp2p part, which is intentionally a libp2p color), and also make the stylistic updates re outlines and clarity of what each arrow color means. LMK if that seems better!

I'd be happy to do a walkthrough - but also am transcribing a lot of knowledge from Steven/Jeromy into this doc that I'm not the best person to explain. I can give a sense as to purpose/audience though - which is folks who are onboarding on IPFS as deep users and hopefully future contributors who want to grok how the pieces fit together and make sense of all the different repos/libraries that make up the sub-areas of IPFS (so they can hopefully help improve them!)

[ericronne]

That feels much easier to follow @momack2 👍
I forked it just now and made some text semibold, which might help key elements stand out (also tweaked a couple alignment issues). Copy if you like. Since the ability to edit online is important, your approach feels like a good compromise. It would be nice to create a template from scratch at some point.

[momack2]

Thanks Eric! Merged those in (and also deleted modules unused by our add / get / request pathways. I think the main communication point here is "how do the systems fit together for basic requests" - so wanted to narrow in on that aim.

[momack2]

Agree that we shouldn’t have any diagrams that communicate incorrect or misleading information. I’d point out that the js-ipfs diagram is for a different stack / system - and therefore having two different architecture diagrams that diverge for each notably different implementation can make sense. As long as all diagrams are correct and not misleading then I think having multiple is fine (especially across different repos / systems)! :)

…

On Mon, Oct 28, 2019 at 11:25 PM David Dias ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In README.md <#6727 (comment)>: > @@ -431,6 +431,10 @@ Some places to get you started on the codebase: - PubSub: https://github.com/libp2p/go-libp2p-pubsub - [IPFS : The `Add` command demystified](https://github.com/ipfs/go-ipfs/tree/master/docs/add-code-flow.md) +### Map of IPFS Subsystems +**WIP**: This is a high-level architecture diagram of the various sub-systems of go-ipfs. To be updated with how they interact. Anyone who has suggestions is welcome to comment [here](https://docs.google.com/drawings/d/1OVpBT2q-NtSJqlPX3buvjYhOnWfdzb85YEsM_njesME/edit) on how we can improve this! To clarify, I believe that we are in agreement in which: - 👍🏽 to having multiple diagram that focus on different specific parts of the stack (i.e. subsystems or interactions) - 👎🏽 on having multiple diagrams called IPFS Architecture and having them communicate information that is in conflict - 👎🏽 on having a diagram that focuses on a subsystem that introduces something that is not coherent with the overall picture Did I get it write? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6727>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEXAF7EIDYTB2IYGKV2YITQQ7JNTANCNFSM4JE754BA> .

[momack2]

Can has approving review? I can merge without it but want to model good contributor practice. 😜

[daviddias]

👏🏽👏🏽 Thank you for creating this diagram! go-ipfs overall documentation is getting HAWT 🔥🔥

[alanshaw]

I can’t speak 100% to the accuracy of it but it looks great and it is clear what components are in use when you add/get. The only thing I don’t understand is the libp2p “request”...? 🤔

[momack2]

@alanshaw - This is when you're getting a request from another node for data you have (via one of the various libp2p methods like pubsub/DHT). If there's a better name I'm happy to add it!