Who works on this, the expected outcome and way of working are some of the first things to be decided on. Here’s a proposal following separate and a collective conversation with @arnetheduck @andre @iurimatias @oskarth and @kim to understand the work required. Full notes here.
Please share any thoughts on who needs to be involved and in what capacity (contributor, stakeholder) and what responsibilities this team should have (i.e. what you expect in terms of deliverables, communication and way of working).
Proposal: Production team Stimbus
Set up an independent team to work on a shim layer that can be interfaced with through an API and gradually phase out status-go.
1 or 2 members from the teams:
- Vac (Waku)
For contributors, Nimbus integration needs to be their number 1 priority and main allocation. Contributors bring their knowledge of requirements for respective clients, but beyond that do not represent interests of any client team. As the layer needs to be client agnostic, independence of the production team is key. Anyone with relevant expertise can join this effort as long as there is agreement on other critical work not being at risk (Mobile, Desktop, ETH2, Vac, Governance, etc.)
TBD is how the team will be lead. Could be an individual or rotation, can also be decided by the team.
- Mobile and Desktop team (read: @andre and @iurimatias )
- Security team (read: @petty )
- Infra (read: @jakubgs )
- Research (read: @arnetheduck)
- Vac (read: @oskarth )
- Leadership (read: @jarradhope )
- Planning (read: @hester )
- Collect and curate common features for shim layer (check lib-status on what’s necessary)
- Specify features for shim layer
- Assure review by stakeholders of feature specs
- Integrate high prio features (Messaging > nim-waku, shim layer)
- Assure quality control of implementation
- Experiment with naive Lightclients node of Eth1 on Desktop
Within 2 weeks
Critical features used by clients (replaced status-go) by end of calendar year. Critical features TBD