mirror of
https://github.com/logos-messaging/pm.git
synced 2026-01-02 14:13:09 +00:00
Upgrade to provided template
This commit is contained in:
fryorcraken
parent
0bafc86a57
commit
62aef27efa
@ -78,6 +78,8 @@ N/A
|
||||
| Status Network | Support usage of Sepolia | Yes |
|
||||
| Vac-ACZ | Assist with using zerokit in the Browser | Yes |
|
||||
| Vac-ACZ Think Tank | Assist in determining best libraries to use for cryptography in new Chat SDK | Pending |
|
||||
| Infra | Maintain Waku fleet, apply config changes requests, deploy new nodes for metrics | TODO |
|
||||
| Vac-SC | Support of functional extension of RLN Smart Contract | TODO |
|
||||
|
||||
##### Optional link to Full Dependency - href
|
||||
|
||||
|
||||
@ -92,13 +92,13 @@ In order of priority.
|
||||
| Priority | Milestone | End Date | core res | js-waku | nwaku | app-chat |
|
||||
|----------|-----------------------------------------------------------------------------------------|----------|----------|---------|-------|-------------|
|
||||
| 1 | [Define Incentivisation for RLNaaS](define_incentivisation_for_rlnaas.md) | 31 Jul | 1.5 | | | |
|
||||
| 2 | [Improve DevEx: API, TWN, Metrics, Docs](improve_devex_api_twn_metrics_docs.md) | TBD | TBD | TBD | TBD | TBD |
|
||||
| 2 | [Improve DevEx: API, TWN, Metrics, Docs](improve_devex_api_twn_metrics_docs.md) | TBD | TBD | TBD | TBD | 0.16.. |
|
||||
| 3 | [Introduce mixnet for message sending](introduce_mixnet_for_message_sending.md) | 30 Sep | 1*3m | | | |
|
||||
| 4 | [Formalize and Expand Waku Web Apps](formalize_and_expand_waku_web_apps.md) | 19 Dec | | | | 1.5*6m |
|
||||
| 4 | [Formalize and Expand Waku Web Apps](formalize_and_expand_waku_web_apps.md) | 19 Dec | | | | 1.5 |
|
||||
| 5 | [Create Chat SDK MVP](create_chat_sdk_mvp.md) | TBD | | | | 2 dev/1 res |
|
||||
| 6 | [Integrate RLN with Waku API](integrate_rln_with_waku_api.md) | TBD | TBD | 1*2m | TBD | |
|
||||
| 7 | [Streamline DevEx: Mobile, Rust and Web dev](streamline_dev_ex_local_dev_rust.md) | TBD | TBD? | TBD | TBD | |
|
||||
| 8 | [Extend Chat SDK with Group Conversations](extend_chat_sdk_with_group_conversations.md) | TBD | | | | TBD |
|
||||
| 8 | [Extend Chat SDK with Group Conversations](extend_chat_sdk_with_group_conversations.md) | TBD | | | | 1 dev/1 res |
|
||||
| 9 | Incentivisation follow-up | TBD | TBD | | | |
|
||||
| 10 | [Nim Usage Improvements](nim_usage_improvements.md) | TBD | | | TBD | |
|
||||
|
||||
|
||||
@ -7,16 +7,25 @@
|
||||
- {external services consumed (Vac/IFT)}
|
||||
- {infrastructure}
|
||||
|
||||
{Milestone Narrative - what do we get once done}
|
||||
|
||||
{Milestone Description - what do we get once done}
|
||||
## Strategic Objective
|
||||
|
||||
**FURPS**:
|
||||
TODO: Clarify with Leonard
|
||||
|
||||
## FURPS
|
||||
|
||||
- [{Feature Name}]({path/to/furps/file}): {list of furps: F1, etc}
|
||||
|
||||
**deliverables**:
|
||||
## Risks
|
||||
|
||||
## {Name of deliverable 1 - eg "improve feature X for the browser"}
|
||||
| Risk | (Accept, Own, Mitigation) |
|
||||
|--------|-------------------------------|
|
||||
| [Risk] | [how to we address this risk] |
|
||||
|
||||
## Deliverables
|
||||
|
||||
### {Name of deliverable 1 - eg "improve feature X for the browser"}
|
||||
|
||||
**Owner**: {one waku subteam}
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Create Chat SDK MVP
|
||||
|
||||
**Estimated date of completion**: 19 Aug 2025
|
||||
**Estimated date of completion**: 30 Sep 2025
|
||||
|
||||
**Resources Required for 2025H2**:
|
||||
- 1 App/Chat Researcher
|
||||
@ -15,32 +15,34 @@ interaction speed.
|
||||
|
||||
Motivations for development of a new chat protocol are described [here](https://forum.vac.dev/t/chatsdk-motivations/501).
|
||||
|
||||
**Risks**:
|
||||
|
||||
- (Schedule)(High) - Lack of Nim experience: Nim is a new language to many who will be performing this work, and will
|
||||
require skill-up to be effective. Delays and high bug counts are possible due to underestimating effort required to
|
||||
become proficient. Leveraging existing Nim knowledge in the team will help mitigate this risk.
|
||||
- (Organizational)(Medium) - Direction Alignment: Currently the chat use case does not have a Security Model and Privacy
|
||||
Model defined from which to drive development. These will need to be drafted while work begins. Given these documents
|
||||
will have wider impact in the org and community there is a risk that consensus will take longer than anticipated,
|
||||
stalling development. Mitigation involves documenting the targeted approach and socializing it as early as possible.
|
||||
Following the Protocol Design Framework outlined for chat use cases will help decompose work areas making partial consensus easier to reach.
|
||||
- (Schedule)(Medium) - Cryptographic Primitives: There is an assumption that the cryptographic libraries needed for the
|
||||
success of this project are available and in a usable state. To mitigate, early tasks will involve spikes to find
|
||||
appropriate libraries and de-risk their usage their state. Extra time spent preparing crypto libraries / porting will
|
||||
result in delays.
|
||||
- (Technical)(Low) - Uncertain Performance: Performance targets for bandwidth are hard to quantify at this stage. They
|
||||
are listed as `P1` in the FURPS. While these targets appear reasonable (125 bytes per second per user) that remains to
|
||||
be seen. This is hard to mitigate as the SDK cannot be profiled until late in the development cycle, making
|
||||
adjustments difficult.
|
||||
|
||||
This milestone is complete when a development preview of the Chat SDK is published and made available to the community.
|
||||
|
||||
**FURPS**: [ChatSDK](/FURPS/application/chat_sdk.md)
|
||||
## Strategic Objective
|
||||
|
||||
**GitHub Milestone and deliverables**: <TODO>
|
||||
TODO: Clarify with Leonard
|
||||
|
||||
## ChatSDK Developer Preview
|
||||
## Risks
|
||||
|
||||
| Type/Level | Risk | (Accept, Own, Mitigation) |
|
||||
|-----------------------|--------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Schedule/High | Lack of Nim experience | Nim is a new language to many who will be performing this work, and will require skill-up to be effective. Delays and high bug counts are possible due to underestimating effort required to become proficient. Leveraging existing Nim knowledge in the team will help mitigate this risk. |
|
||||
| Organisational/Medium | Direction Alignment | Currently the chat use case does not have a Security Model and Privacy Model defined from which to drive development. These will need to be drafted while work begins. Given these documents will have wider impact in the org and community there is a risk that consensus will take longer than anticipated, stalling development. Mitigation involves documenting the targeted approach and socializing it as early as possible. Following the Protocol Design Framework outlined for chat use cases will help decompose work areas making partial consensus easier to reach. |
|
||||
| Schedule/Medium | Cryptographic Primitives | There is an assumption that the cryptographic libraries needed for the success of this project are available and in a usable state. To mitigate, early tasks will involve spikes to find appropriate libraries and de-risk their usage their state. Collaboration with ACZ Think Tank. Extra time spent preparing crypto libraries / porting will result in delays. |
|
||||
| Technical/Low | Uncertain Performance | Performance targets for bandwidth are hard to quantify at this stage. They are listed as `P1` in the FURPS. While these targets appear reasonable (125 bytes per second per user) that remains to be seen. This is hard to mitigate as the SDK cannot be profiled until late in the development cycle, making adjustments difficult. |
|
||||
|
||||
## FURPS
|
||||
|
||||
[ChatSDK](/FURPS/application/chat_sdk.md)
|
||||
|
||||
## Risks
|
||||
|
||||
| Risk | (Accept, Own, Mitigation) |
|
||||
|--------|-------------------------------|
|
||||
| [Risk] | [how to we address this risk] |
|
||||
|
||||
## Deliverables
|
||||
|
||||
### ChatSDK Developer Preview
|
||||
|
||||
**Owner**: App/Chat Research
|
||||
|
||||
@ -74,8 +76,7 @@ This milestone is complete when a development preview of the Chat SDK is publish
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
|
||||
## ChatSDK Bindings
|
||||
### ChatSDK Bindings
|
||||
|
||||
**Owner**: App/Chat Dev
|
||||
|
||||
@ -92,12 +93,12 @@ For library ChatSDK:
|
||||
- S4. library can be used in Rust applications; import via git path.
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Specs: API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
- [ ] Docs: links to README.md or docs.waku.orgAPI definition? (TBD)
|
||||
|
||||
## Create Segmentation Library
|
||||
### Create Segmentation Library
|
||||
|
||||
**Owner**: App/Chat Dev
|
||||
|
||||
@ -129,7 +130,7 @@ For library ChatSDK:
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Create Rate Limit Manager
|
||||
### Create Rate Limit Manager
|
||||
|
||||
**Owner**: App/Chat Dev
|
||||
|
||||
|
||||
@ -15,5 +15,15 @@ including RLN proofs as a service, Store, Filter and Lightpush.
|
||||
This milestone encapsulates the efforts to distribute rewards for running RLN Relay nodes and getting paid for providing Waku services.
|
||||
This is the first step to providing a sustainable way to scale the Status application.
|
||||
|
||||
**FURPS**:
|
||||
- [Incentivisation](/FURPS/core/incentivisation.md): F1-3, U1-2, R1-3, P1, for S1
|
||||
## Strategic Objective
|
||||
|
||||
TODO: Clarify with Leonard
|
||||
|
||||
## FURPS
|
||||
- [Incentivisation](/FURPS/core/incentivisation.md): F1-3, U1-2, R1-3, P1, for S1
|
||||
|
||||
## Risks
|
||||
|
||||
| Risk | (Accept, Own, Mitigation) |
|
||||
|--------------------------------------------|-----------------------------------------------|
|
||||
| Heavy on research and unknowns, UX impacts | Identify concrete deliverables, dogfood early |
|
||||
@ -1,6 +1,6 @@
|
||||
# Extend Chat SDK with Group Conversations
|
||||
|
||||
**Estimated date of completion**: 18 Nov 2025
|
||||
**Estimated date of completion**: 19 Dec 2025
|
||||
|
||||
**Resources Required for 2025H2**:
|
||||
- 1 App/Chat Research
|
||||
@ -11,22 +11,28 @@ participants in a given group chat.
|
||||
|
||||
The features to said group chat will be limited, and extended with further milestones.
|
||||
|
||||
**Risks**:
|
||||
Support to plug Status Communities on top of this SDK is **not** expected.
|
||||
Further group size scaling and extension of membership management API would be needed.
|
||||
|
||||
- (Schedule)(Medium) - Task Dependency: This task is dependent on [ChatSDK - Developer Preview](create_chat_sdk_mvp.md).
|
||||
Delays there will translate into delays to this milestone.
|
||||
- (Technical)(Medium) - Lack of Libraries: There currently does not exist the required libraries in Nim to build group
|
||||
chat. This will involve evaluating the potential of calling an existing library via FFI or implementing it from
|
||||
scratch. This can be mitigated by vetting existing library potential should occur early or finding security reviewers
|
||||
for nim implemented cryptography.
|
||||
- (Technical)(Low) - Group chat is prone to bugs, even when using existing encryption protocols. Extra time has been
|
||||
allocated to testing and debugging in an effort to mitigate this, however it still remains a risk.
|
||||
## Strategic Objective
|
||||
|
||||
**FURPS**: [Group Chat](/FURPS/application/group_chat.md)
|
||||
TODO: Clarify with Leonard
|
||||
|
||||
**GitHub Milestone and deliverables**: <TODO>
|
||||
## FURPS
|
||||
|
||||
## Add Group Chat
|
||||
[Group Chat](/FURPS/application/group_chat.md)
|
||||
|
||||
## Risks
|
||||
|
||||
| Type/Level | Risk | (Accept, Own, Mitigation) |
|
||||
|------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Schedule/Medium | Milestone Dependency | This milestone is dependent on [ChatSDK - Developer Preview](create_chat_sdk_mvp.md). Delays there will translate into delays to this milestone. |
|
||||
| Technical/Medium | Lack of NimLibraries | There currently does not exist the required libraries in Nim to build group chat. This will involve evaluating the potential of calling an existing library via FFI or implementing it from scratch. This can be mitigated by vetting existing library potential should occur early or finding security reviewers for nim implemented cryptography. |
|
||||
| Technical/Low | Group chat is prone to bugs, even when using existing encryption protocols. Extra time has been allocated to testing and debugging in an effort to mitigate this, however it still remains a risk. |
|
||||
|
||||
## Deliverables
|
||||
|
||||
### Add Group Chat
|
||||
|
||||
**Owner**: App/Chat Research
|
||||
|
||||
@ -55,8 +61,7 @@ The features to said group chat will be limited, and extended with further miles
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
|
||||
## Group Chat Bindings
|
||||
### Group Chat Bindings
|
||||
|
||||
**Owner**: App/Chat Dev
|
||||
|
||||
|
||||
@ -17,11 +17,23 @@ Explore Codex x Waku integration, in Qaku and one other application.
|
||||
Develop 10 Waku Web Apps PoC, and push them to the community to "teach them how to hunt" as well as inspire developers
|
||||
to build over Waku.
|
||||
|
||||
**FURPS**: See deliverables
|
||||
## Strategic Objective
|
||||
|
||||
**Deliverables**:
|
||||
TODO: Clarify with Leonard
|
||||
|
||||
## [Forum PoC](https://github.com/waku-org/pm/issues/292)
|
||||
## FURPS
|
||||
|
||||
## Risks
|
||||
|
||||
| Risk | (Accept, Own, Mitigation) |
|
||||
|----------------------------------------------------|----------------------------------------------------------------|
|
||||
| Logos Core Readiness | Get involed early with Logos Core, tinker and provide feedback |
|
||||
| Experimental application spam protection for Forum | Focus on MVP to get user feedback early |
|
||||
| Spec writing by non-researchers | Push for early specs, to enabling feedback and mentoring |
|
||||
|
||||
## Deliverables
|
||||
|
||||
### [Forum PoC](https://github.com/waku-org/pm/issues/292)
|
||||
|
||||
**Owner**: App/Chat Dev
|
||||
|
||||
@ -33,14 +45,14 @@ to build over Waku.
|
||||
- R1-2
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Specs: link to specs
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## [Codex for Message Archival PoC](https://github.com/waku-org/pm/issues/293)
|
||||
### [Codex for Message Archival PoC](https://github.com/waku-org/pm/issues/293)
|
||||
|
||||
TODO
|
||||
TODO - Hanno is defining some FURPS and we can review.
|
||||
|
||||
**Owner**: {one waku subteam}
|
||||
|
||||
@ -55,7 +67,7 @@ TODO
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## [Reliable Qaku & library](https://github.com/waku-org/pm/issues/287)
|
||||
### [Reliable Qaku & library](https://github.com/waku-org/pm/issues/287)
|
||||
|
||||
**Owner**: App/Chat Dev
|
||||
|
||||
@ -74,7 +86,7 @@ TODO
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Build Ten Waku Web Apps
|
||||
### Build Ten Waku Web Apps
|
||||
|
||||
**Owner**: App/Chat Dev
|
||||
|
||||
@ -82,7 +94,7 @@ TODO
|
||||
|
||||
**Output**: 10 working Waku Web apps of various sort.
|
||||
|
||||
- The apps needs to be functioning and deployed, PoC level.
|
||||
- The apps need to be functioning and deployed, PoC level.
|
||||
- Broadcast to the community must happen (Logos/Waku Discord, Logos/Vac Forums, conference talks, Twitter, etc).
|
||||
|
||||
**Checklist**:
|
||||
@ -92,7 +104,7 @@ TODO
|
||||
- ~[ ] Docs: links to README.md or docs.waku.org (TBD)~
|
||||
- [ ] Promote the app
|
||||
|
||||
## Build One Waku Logos Core App
|
||||
### Build One Waku Logos Core App
|
||||
|
||||
**Owner**: App/Chat Dev
|
||||
|
||||
@ -100,7 +112,7 @@ TODO
|
||||
|
||||
**Output**: 1 working Logos Core App.
|
||||
|
||||
- The apps needs to be functioning, PoC level.
|
||||
- The app needs to be functioning, PoC level.
|
||||
- Broadcast to the community must happen (Logos/Waku Discord, Logos/Vac Forums, conference talks, Twitter, etc).
|
||||
- May use Waku SDK or Chat SDK.
|
||||
|
||||
@ -111,7 +123,7 @@ TODO
|
||||
- ~[ ] Docs: links to README.md or docs.waku.org (TBD)~
|
||||
- [ ] Promote the app
|
||||
|
||||
## Open Forum to Web3 Users and Anons
|
||||
### Open Forum to Web3 Users and Anons
|
||||
|
||||
**Owner**: App/Chat Dev
|
||||
|
||||
|
||||
@ -11,18 +11,37 @@
|
||||
Proceed with a number of improvements to the developer experience on Waku, for both internal and external purposes.
|
||||
This includes:
|
||||
|
||||
- improving The Waku Network reliability for Logos apps and other web apps
|
||||
- simplifying the Waku API
|
||||
- measuring Waku usage across all integrations
|
||||
- review and setting strategy for Waku documentation
|
||||
- Improving The Waku Network reliability for Logos apps and other web apps
|
||||
- Simplifying the Waku API
|
||||
- Measuring Waku usage across all integrations
|
||||
- Review and setting strategy for Waku documentation
|
||||
- Testing quic as new transport
|
||||
|
||||
**deliverables**:
|
||||
## Strategic Objective
|
||||
|
||||
## [Global Network Metrics](https://github.com/waku-org/pm/issues/295)
|
||||
TODO: Clarify with Leonard
|
||||
|
||||
## FURPS
|
||||
|
||||
TODO (see deliverables)
|
||||
|
||||
## Risks
|
||||
|
||||
| Risk | (Accept, Own, Mitigation) |
|
||||
|---------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------|
|
||||
| Define collaboration with BI for metrics | Communicate |
|
||||
| Browser reliability is a multi-prong problem (js-waku/libp2p, nwaku/nim-libp2p) | Strong collaboration |
|
||||
| No "documentation" expert or dedicated resources | outsource help from doc experts in IFT, focus on setting guidelines for all Waku CCs to follow |
|
||||
|
||||
|
||||
## Deliverables
|
||||
|
||||
### [Global Network Metrics](https://github.com/waku-org/pm/issues/295)
|
||||
|
||||
**Owner**: App/Chat Dev
|
||||
|
||||
TODO: Pablo to confirm dependency on BI and what they do vs what we do.
|
||||
|
||||
**Feature**: [Network Metrics Tracker](/FURPS/application/network_metrics_tracker.md)
|
||||
|
||||
**FURPS**:
|
||||
@ -34,7 +53,7 @@ This includes:
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## [Scalable Data Sync in Browser](https://github.com/waku-org/pm/issues/280)
|
||||
### [Scalable Data Sync in Browser](https://github.com/waku-org/pm/issues/280)
|
||||
|
||||
**Owner**: js-waku
|
||||
|
||||
@ -51,7 +70,7 @@ For S2. For Web apps as a developer library.
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## [Waku Sync](https://github.com/waku-org/pm/issues/132)
|
||||
### [Waku Sync](https://github.com/waku-org/pm/issues/132)
|
||||
|
||||
**Owner**: core research
|
||||
|
||||
@ -65,7 +84,7 @@ For S2. For Web apps as a developer library.
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Define and Implement Light Push Error codes in nwaku
|
||||
### Define and Implement Light Push Error codes in nwaku
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
@ -86,7 +105,7 @@ Includes spec delivery
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Implement Light Push Error codes in The Browser
|
||||
### Implement Light Push Error codes in The Browser
|
||||
|
||||
**Owner**: js-waku
|
||||
|
||||
@ -106,7 +125,7 @@ Spec delivery not included.
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Introduce Waku API in the Browser
|
||||
### Introduce Waku API in the Browser
|
||||
|
||||
**Owner**: js-waku
|
||||
|
||||
@ -135,7 +154,7 @@ For S3. Browser; distribution via npmjs.com.
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Introduce Waku API in nwaku
|
||||
### Introduce Waku API in nwaku
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
@ -166,7 +185,7 @@ For:
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Review Documentation and Define Guidelines
|
||||
### Review Documentation and Define Guidelines
|
||||
|
||||
**Owner**: core research
|
||||
|
||||
@ -179,7 +198,7 @@ For:
|
||||
- [ ] How to contribute to documentation: location, format
|
||||
- [ ] Setup an initial structure to enable the guideline
|
||||
|
||||
## Trial QUIC
|
||||
### Trial QUIC
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
@ -194,7 +213,7 @@ For:
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Optimise Browser Bootstrapping
|
||||
### Optimise Browser Bootstrapping
|
||||
|
||||
**Owner**: js-waku
|
||||
|
||||
|
||||
@ -21,13 +21,24 @@ Introduce RLN proof generation and validation in the Browser. RLN API should be
|
||||
|
||||
Finally, migrate to Status network L2 testnet and improve UX issues discovered via dogfooding such as rate of RPC Calls.
|
||||
|
||||
**FURPS**:
|
||||
## FURPS
|
||||
|
||||
- [{Feature Name}]({path/to/furps/file}): {list of furps: F1, etc} TODO
|
||||
TODO
|
||||
|
||||
**deliverables**:
|
||||
## Risks
|
||||
|
||||
## Implement RLN membership management in nwaku library
|
||||
| Risk | (Accept, Own, Mitigation) |
|
||||
|-------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Not all required improvements are yet identified | Dogfooding of the H1 delivery will enable identification of needed improvements, meaning this milestone may change in term of scope and schedule. |
|
||||
| Dependencies on Nim Web3 library | Previous upgrade of nim web3 libraries have lead to various issues. The dependencies of said library is increasing, meaning potential delay in development. |
|
||||
| Uncertainty regarding zerokit and wasm in the browser | UX-related property are yet to be explored with the new RLN smart contract. WASM loading and execution may have considerable impact on UX. Collaboration with Vac/ACZ will be required to adapt zerokit for the browser. |
|
||||
| Smart Contract Changes & Expertise | We expect functional extension of RLN smart contract to potentialy store multiple roots, and maybe other improvement depending on dogfooding. The Solidity knowledge in the team is limited/non-existent so we would need to rely on Vac-SC or upskill. |
|
||||
| API Refactoring | Extracting RLN as a validation plugin may ensue some API refactoring that may take longer than initially estimated. A conservative estimate will be done. |
|
||||
| FFI to FFI interaction | The intent will be to have RLN and Waku SDK as 2 separate libraries that can be initialized in any language (e.g Golang). The nim to nim via FFI may raise unforeseen issues . |
|
||||
|
||||
## Deliverables
|
||||
|
||||
### Implement RLN membership management in nwaku library
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
@ -42,7 +53,7 @@ Finally, migrate to Status network L2 testnet and improve UX issues discovered v
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Implement RLN Onchain Tree Proof generation and verification in the Browser
|
||||
### Implement RLN Onchain Tree Proof generation and verification in the Browser
|
||||
|
||||
**Owner**: js-waku
|
||||
|
||||
@ -57,7 +68,7 @@ Finally, migrate to Status network L2 testnet and improve UX issues discovered v
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Extract RLN as a plug-in library from nwaku
|
||||
### Extract RLN as a plug-in library from nwaku
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
@ -72,7 +83,7 @@ Finally, migrate to Status network L2 testnet and improve UX issues discovered v
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Deploy RLN Contracts to Status L2 testnet
|
||||
### Deploy RLN Contracts to Status L2 testnet
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
@ -87,7 +98,7 @@ Finally, migrate to Status network L2 testnet and improve UX issues discovered v
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Improve RLN UX by reducing Web3 RPC calls
|
||||
### Improve RLN UX by reducing Web3 RPC calls
|
||||
|
||||
TODO: other improvements may be flagged as we dogfood the previous RLN milestone.
|
||||
|
||||
|
||||
@ -7,11 +7,24 @@
|
||||
|
||||
A PoC implementation to improve anonymity in Waku message publishing by mixing Waku Lightpush requests and responses.
|
||||
|
||||
**FURPS** (see deliverables)
|
||||
## Strategic Objective
|
||||
|
||||
**GitHub Milestone and deliverables**:
|
||||
TODO: Clarify with Leonard
|
||||
|
||||
## [Integrate libp2p mix into lightpush](https://github.com/waku-org/nwaku/issues/3280)
|
||||
## FURPS
|
||||
|
||||
See deliverables.
|
||||
|
||||
## Risks
|
||||
|
||||
| Risk | (Accept, Own, Mitigation) |
|
||||
|-----------------------------------------|--------------------------------------------------------------------|
|
||||
| Dependency on nim-libp2p | Strong collaboration, integrate early, get involved behind the API |
|
||||
| Impact on latency and other UX elements | Run simulations and studies to understand impact |
|
||||
|
||||
## Deliverables
|
||||
|
||||
### [Integrate libp2p mix into lightpush](https://github.com/waku-org/nwaku/issues/3280)
|
||||
|
||||
**Owner**: core research
|
||||
|
||||
@ -23,7 +36,6 @@ A PoC implementation to improve anonymity in Waku message publishing by mixing W
|
||||
- F3. Client nodes can send light push requests over the mixnet before delivery to a service node.
|
||||
- F4. Client nodes can receive a response to a light push request over the mixnet.
|
||||
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
|
||||
@ -10,21 +10,35 @@
|
||||
Improve usage of Nim related tooling and design patterns by proceedings with PoCs to discover potential gains and caveats.
|
||||
This includes adoption of Nimble, usage of VSCode plugin and iteration on C-Binding methodology.
|
||||
|
||||
**FURPS**:
|
||||
## Strategic Objective
|
||||
|
||||
- [{Feature Name}]({path/to/furps/file}): TODO
|
||||
TODO: Clarify with Leonard
|
||||
|
||||
**deliverables**:
|
||||
## FURPS
|
||||
|
||||
## Dogfood VSCode Plugin and Nimsuggest
|
||||
TODO
|
||||
|
||||
## Risks
|
||||
|
||||
| Risk | (Accept, Own, Mitigation) |
|
||||
|---------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Maturity of tooling | This milestone focusing on trying out fresh Nim tooling, hence it may not be possible to output a PoC, but instead raising a series of upstream issues. |
|
||||
| Actual value/impact | The direct value on dev ex is not always clear, especially for Nimble. There is hope on bette contributor experience, but the end impact may mostly be on improving Nim tooling by providing constructive feedback. |
|
||||
|
||||
## Deliverables
|
||||
|
||||
### Dogfood VSCode Plugin and Nimsuggest
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
**No FURPS**
|
||||
|
||||
**Output**: Open issues and report on nimsuggest crashes and poor performance when used with nwaku codebase.
|
||||
**Output**:
|
||||
- [ ] Test nimsuggest in the nwaku codebase
|
||||
- [ ] Create reproducible setup for crashes and poor performance, open upstream issues.
|
||||
- [ ] Optional: provide a plan to make nwaku better compatible with nimsuggest (eg. no git submodule, less macros, etc)
|
||||
|
||||
## Migrate nwaku to Nimble PoC
|
||||
### Migrate nwaku to Nimble PoC
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
|
||||
@ -15,13 +15,25 @@ relying on external connectivity; as well as opting in and out of RLN, and inclu
|
||||
|
||||
Finalize the integration of nwaku in Status application by setting up nwaku-based build for Mobile platforms.
|
||||
|
||||
**FURPS**:
|
||||
## Strategic Objective
|
||||
|
||||
- [{Feature Name}]({path/to/furps/file}): {list of furps: F1, etc}
|
||||
TODO: Clarify with Leonard
|
||||
|
||||
**deliverables**:
|
||||
## FURPS
|
||||
|
||||
## Edge Mode in Nwaku
|
||||
TODO
|
||||
|
||||
## Risks
|
||||
|
||||
| Risk | (Accept, Own, Mitigation) |
|
||||
|-------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| nwaku performance | Performance of nwaku in comparison to go-waku will be measured by DST during H2 and may raise issues that will become blockers for pratical usage of nwaku in Mobile. |
|
||||
| Publishing to crates.io | One of the challenge to publish libwaku on crates.io is the package size. Several strategy may be developed and tried to find a way to distribute Nim-based Rust crates. |
|
||||
| Local dev harness | Creating a local dev environment may be a challenge due to the nature of Waku and RLN, as we would need to locally coordinate bootstrap and blockchain emulation. |
|
||||
|
||||
## Deliverables
|
||||
|
||||
### Edge Mode in Nwaku
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
@ -36,7 +48,7 @@ Finalize the integration of nwaku in Status application by setting up nwaku-base
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Nwaku in Status Mobile
|
||||
### Nwaku in Status Mobile
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
@ -51,7 +63,7 @@ Finalize the integration of nwaku in Status application by setting up nwaku-base
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Waku Rust SDK
|
||||
### Waku Rust SDK
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
@ -66,7 +78,7 @@ Finalize the integration of nwaku in Status application by setting up nwaku-base
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Local RLN Dev Harness
|
||||
### Local RLN Dev Harness
|
||||
|
||||
**Owner**: ? (nwaku? core-research?) TODO
|
||||
|
||||
@ -81,7 +93,7 @@ Finalize the integration of nwaku in Status application by setting up nwaku-base
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)\
|
||||
|
||||
## Local Web Dev Harness
|
||||
### Local Web Dev Harness
|
||||
|
||||
**Owner**: js-waku
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user