Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

propose: js projects configuration #82

Closed
wants to merge 1 commit into from
Closed

propose: js projects configuration #82

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
120 changes: 120 additions & 0 deletions proposals/82-js-configuration.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,120 @@
# [outcome or objective here]

Authors: @vasco-santos <!-- List authors' GitHub or other handles -->

Initial PR: https://github.com/protocol/web3-dev-team/pull/82 <!-- Reference the PR first proposing this document. Oooh, self-reference! -->

<!--
This template is for a proposal/brief/pitch for a significant project to be undertaken by a Web3 Dev project team.
The goal of project proposals is to help us decide which work to take on, which things are more valuable than other things.
-->
<!--
A proposal should contain enough detail for others to understand how this project contributes to our team’s mission of product-market fit
for our unified stack of protocols, what is included in scope of the project, where to get started if a project team were to take this on,
and any other information relevant for prioritizing this project against others.
It does not need to describe the work in much detail. Most technical design and planning would take place after a proposal is adopted.
Good project scope aims for ~3-5 engineers for 1-3 months (though feel free to suggest larger-scoped projects anyway).
Projects do not include regular day-to-day maintenance and improvement work, e.g. on testing, tooling, validation, code clarity, refactors for future capability, etc.
-->
<!--
For ease of discussion in PRs, consider breaking lines after every sentence or long phrase.
-->

## Purpose &amp; impact
#### Background &amp; intent
_Describe the desired state of the world after this project? Why does that matter?_
<!--
Outline the status quo, including any relevant context on the problem you’re seeing that this project should solve. Wherever possible, include pains or problems that you’ve seen users experience to help motivate why solving this problem works towards top-line objectives.
-->

The initial barrier when users interact with our stack is configuration. Based on anecdotal evidence while interacting with the community and analyzing issues, configuration is one of the biggest pain points for users, specially in libp2p where as a result of its modular nature users are required to immediately configure a node.

Our stack configurations are usually complex, inconsistent and require a lot of prior knowledge of the building blocks of the stack, as well as how these building blocks interact with each other.

With this project, we should improve the configuration experience for the users, as well as reduce its need to power users only. Within the user onboarding scope, configuration across the stack should be simple, complete and establishing a bridge to the concepts behind (visual explanations/illustrations would be rad!). In addition, our set of projects should provide typical configurations that users need for typical scenarios, so that users can start playing without a need for configuration. Finally, within the power users scope, we should land improvements to mitigate all the existing inconsistencies and improve developer experience.

The above scopes can turn this project proposal into two different projects.

#### Assumptions &amp; hypotheses
_What must be true for this project to matter?_
<!--(bullet list)-->

- Users cannot properly configure our stack autonomously
- Configuration get users blocked and turn them into inactive users

#### User workflow example
_How would a developer or user use this new capability?_
<!--(short paragraph)-->

One of two ways:
- Inexperienced/First users can use the stack out of the box, without any friction around configurations
- Power users can create their own configuration for a specific scenario autonomously

#### Impact
_How would this directly contribute to web3 dev stack product-market fit?_

<!--
Explain how this addresses known challenges or opportunities.
What awesome potential impact/outcomes/results will we see if we nail this project?
-->

#### Leverage
_How much would nailing this project improve our knowledge and ability to execute future projects?_

<!--
Explain the opportunity or leverage point for our subsequent velocity/impact (e.g. by speeding up development, enabling more contributors, etc)
-->

#### Confidence
_How sure are we that this impact would be realized? Label from [this scale](https://medium.com/@nimay/inside-product-introduction-to-feature-priority-using-ice-impact-confidence-ease-and-gist-5180434e5b15)_.

<!--Explain why this rating-->


## Project definition
#### Brief plan of attack

<!--Briefly describe the milestones/steps/work needed for this project-->

- We have been cataloging in libp2p all the problems of configuration we see from issues and have some discussions about potential solutions in https://github.com/libp2p/js-libp2p/issues/576. But the scope is much broader than libp2p

#### What does done look like?
_What specific deliverables should completed to consider this project done?_

TODO, we need to define the scope
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we can deal with the scoping challenge by limiting it to the libp2p work as round-1 to form stronger opinions about how to do this well and then do subsequent iterations/projects doing that elsewhere. The proposal in libp2p/js-libp2p#576 (comment) looks like a pretty solid suggestion for how to move forward and we could just adopt that as the basis of a plan (with updates to account for newer perspectives).
There's probably some overlap with #71 and some of the work we did in multiformats/ipld (e.g. see https://github.com/multiformats/js-multiformats/blob/master/src/basics.js for a "give me the common basics" version vs the "I'll build my own, thanks"). I imagine there's opportunities here to decouple code paths so that, in configuring your libp2p you're instantiating a set of dependent modules (& packages) that can be easily tree-shaken by a bundler.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think limiting to libp2p initially would be beneficial, it's the most challenging to configure at this point. A possible amendment, although it could be done as a followup, would be to setup deployment to automatically release the various configurations as ready to go libp2p modules, similar to https://github.com/carsonfarmer/libp2p-bundle, which would reduce the need to install any other modules to get up and running. The multiformats/ipld work is a great reference for potential structure here. If we built this out, we could later go through crypto and shake out the needed components for each of these bundles, namely browsers, to reduce size for those configs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with decoupling this into libp2p first as I think that is where most of the pain points are.

However, there are some issues on ipfs configuration "conflicts" with libp2p per ipfs/js-ipfs#3590 (comment), where we have multiple ways of configure things and then surprising end results might appear. This can probably be a maintenance task in ipfs or something that the onboarding team can have a look. What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can probably be a maintenance task in ipfs

That or it could eventually become a project. To keep the scope small here, starting with making libp2p easy to construct and then have a default build for Node.js and the browser that can be used on the public network out of the box would be a good starting point. This gets immediate value to new users so they can avoid configuration, and makes it easier for us to roll these changes into js-ipfs and improve its configuration later.


#### What does success look like?
_Success means impact. How will we know we did the right thing?_

TODO

<!--
Provide success criteria. These might include particular metrics, desired changes in the types of bug reports being filed, desired changes in qualitative user feedback (measured via surveys, etc), etc.
-->

#### Counterpoints &amp; pre-mortem
_Why might this project be lower impact than expected? How could this project fail to complete, or fail to be successful?_

#### Alternatives
_How might this project’s intent be realized in other ways (other than this project proposal)? What other potential solutions can address the same need?_

#### Dependencies/prerequisites
<!--List any other projects that are dependencies/prerequisites for this project that is being pitched.-->

#### Future opportunities
<!--What future projects/opportunities could this project enable?-->

## Required resources

#### Effort estimate
<!--T-shirt size rating of the size of the project. If the project might require external collaborators/teams, please note in the roles/skills section below).
For a team of 3-5 people with the appropriate skills:
- Small, 1-2 weeks
- Medium, 3-5 weeks
- Large, 6-10 weeks
- XLarge, >10 weeks
Describe any choices and uncertainty in this scope estimate. (E.g. Uncertainty in the scope until design work is complete, low uncertainty in execution thereafter.)
-->

#### Roles / skills needed
<!--Describe the knowledge/skill-sets and team that are needed for this project (e.g. PM, docs, protocol or library expertise, design expertise, etc.). If this project could be externalized to the community or a team outside PL's direct employment, please note that here.-->