mirror of https://github.com/logos-co/roadmap.git
102 lines
4.4 KiB
Markdown
102 lines
4.4 KiB
Markdown
---
|
||
title: 2024 Milestones
|
||
date: 2024-06-04
|
||
---
|
||
## Gantt Chart
|
||
|
||
[[waku/2024-gantt]]
|
||
|
||
## Milestones and Deliverables
|
||
|
||
### Store Service Upgrade
|
||
|
||
https://github.com/waku-org/pm/milestone/27
|
||
|
||
Due Date: 2024-09-20
|
||
|
||
With this milestone, the store protocol becomes more easily usable for reliability purposes.
|
||
Moreover, nwaku PostgreSQL implementation will enable better disk space management and enable operators to hard cap the used disk space.
|
||
|
||
### Direct Message Reliability
|
||
|
||
Due Date: 2024-09-02
|
||
|
||
https://github.com/waku-org/pm/milestone/28
|
||
|
||
With this milestone, connectivity issues in Status Mobile and Desktop are solved and tested.
|
||
Usage of store v3-beta casts a wide net on potential message loss, at the cost of bandwidth overhead (but still lower than current usage of storev2).
|
||
|
||
Review of MVDS usage for all direct messages is done to ensure that critical messages (request to join, contact request, 1:1 messages, private group) are delivered.
|
||
|
||
### End-to-end reliability protocol
|
||
|
||
https://github.com/waku-org/pm/milestone/29
|
||
|
||
Due Date: 2024-09-02
|
||
|
||
To solve reliability is to solve two problems:
|
||
|
||
1. High heuristic that messages are received and sent
|
||
2. Ability to know whether messages are received or sent
|
||
|
||
Problem (1) can never be 100% reliable in a network environment. The previous milestones focused on it.
|
||
|
||
To solve (2), is to create an end-to-end protocol, sender to recipient, that enables the ability to know whether recipient(s) have received messages.
|
||
|
||
With this milestone, we design and deliver a first PoC for an end-to-end reliability protocol.
|
||
This protocol will be specified and implemented in the Status app for Status Communities chat rooms.
|
||
|
||
### Static Sharding - dedicated shards
|
||
|
||
https://github.com/waku-org/pm/milestone/30
|
||
|
||
Due Date: 2024-09-30
|
||
|
||
Creating a new community on its dedicated shard would be tested and working, including assigning a pre-shared key for opt-in message signing (weak DoS protection).
|
||
|
||
Community creation on a default shard (32) to remain (up to app team to hide button or not) to enable mass creation of communities on shared shard for QA testing purposes.
|
||
|
||
Vac QA and DST are asked to look at Status Communities behaviour, whereas previously the focus was on direct messages reliability (one layer lower).
|
||
|
||
Finally, telemetry service will be updated to include bandwidth usage statistics, with a fine breakdown to understand top bandwidth consumers (control msg, chat msg, etc). Additionally, the DST team is asked to run simulations with a focus on bandwidth usage.
|
||
|
||
### Bandwidth optimization and protocol review
|
||
|
||
https://github.com/waku-org/pm/milestone/31
|
||
|
||
Due Date: TBD
|
||
|
||
Bandwidth measurement from the previous milestone may lead to improvement that should be tackled with this milestone. This should be done in tandem with tackling low-hanging/high value items of the [Status Community protocols potential scaling problems](https://github.com/vacp2p/research/issues/177).
|
||
|
||
Finally, usage of content topics should be reviewed to align with Waku’s recommendation, clear migration strategy, caveat and benefits should be outlined, such as future usage of auto-sharding and reduction of topics used by a single user for more efficient use of services.
|
||
|
||
### Scale up number of Communities
|
||
|
||
https://github.com/waku-org/pm/milestone/32
|
||
|
||
Due Date: TBD
|
||
|
||
Proceed with next steps to scale up the number of communities with a focus on testing and configure rendezvous which would enable a large number of communities on their own shard, with the caveat of a more federated global topology.
|
||
The rendezvous nodes of a community would be a centralised infra to a community.
|
||
|
||
Also proceed with enhancing of the current decentralised discovery protocol to pave the way towards less centralised topology.
|
||
|
||
### Nwaku in Status Desktop (Relay, *nix)
|
||
|
||
https://github.com/waku-org/pm/milestone/33
|
||
|
||
Due Date: TBD
|
||
|
||
With this milestone, Status Desktop builds on Linux and Mac can use nwaku instead of go-waku.
|
||
Go-waku will still be used for Windows (Desktop) and Status Mobile.
|
||
|
||
### Scale 1:1 chat messages PoC
|
||
|
||
https://github.com/waku-org/pm/milestone/34
|
||
|
||
Due Date: 2024-11-30
|
||
|
||
Improved flexibility of the rate limit (from 1 msg/epoch to N msg/epoch), providing better dimensioning for bandwidth capping.
|
||
|
||
Moving from RLNv1 to RLNv2 to allow better bandwidth dimensioning in the network. This will allow a message allocation per hour or day per registered publisher, providing better statistical guarantees for network bandwidth usage.
|