[WIP] propose: browser nodes can connect to any node out of the box

proposals/browser-nodes-can-connect-to-any-node-out-of-the-box.md

@@ -0,0 +1,120 @@
+# Browser nodes can connect to any node out of the box
+
+Authors: @vasco-santos
+
+Initial PR: https://github.com/protocol/web3-dev-team/pull/70
+
+<!--
+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. 
+-->
+
+One of the key environments for the web3 is the browser. Browser nodes have several connectivity challenges that result from their environment, with the most relevant being:
+- unable to listen for incoming dials;
+- no support for TCP;
+- security policies require dials with WSS and DNS addresses.
+
+Circuit relays have been used to work around these limitations. Browser nodes can establish a connection with them and bind to them to receive incoming dials. They can also be used to "translate" a connection from Websockets to TCP and consequently, enable browser nodes to dial GO nodes.
+
+##### Problem Statement
+
+One of the critical pieces in the puzzle is the lack of ability from browser nodes to connect with GO nodes out of the box (majority of the network). By default, GO nodes do not listen on Websockets, nor have DNS + SSL configured. In addition, GO nodes do not bind to relays out of the box. This creates a network fragmentations and results in problems creating pubsub overlay, getting IPNS records, among others.
+
+Having browser nodes to connect with go nodes out of the box essentially means one of:
+- go nodes listen on webrtc by default + we can use limited relays to also negotiate webrtc conns + we deploy nodes that can act as limited relay and have dns + wss addresses (which means not all DHT servers will be capable of doing so out of the box)
+- go nodes listen on websockets address by default + we find a solution for out of the box certificates for announcing dns+wss multiaddr
+
+#### Assumptions &amp; hypotheses
+_What must be true for this project to matter?_
+<!--(bullet list)-->
+
+- Dapp developers want browser nodes to exchange pubsub messages across the public network
+- Dapp developers want to find IPNS records on the network
+- Dapp developers want to fetch content from GO nodes
+
+#### User workflow example
+_How would a developer or user use this new capability?_
+<!--(short paragraph)-->
+
+#### 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?
+-->
+
+We had some really good discussions yesterday about the state of Pubsub/IPNS in each runtime environment  + what are the gaps for building dapps on our stack out of the box.
+
+#### 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-->
+
+#### What does done look like?
+_What specific deliverables should completed to consider this project done?_
+
+####  What does success look like?
+_Success means impact. How will we know we did the right thing?_
+
+<!--
+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.-->