mirror of https://github.com/logos-co/roadmap.git
Waku weekly
This commit is contained in:
fryorcraken.eth
parent
8cf79780a4
commit
4a8ae7b99d
|
|
@ -11,9 +11,9 @@ draft:
|
|||
## [Waku Network Can Support 10K Users](https://github.com/waku-org/pm/issues/12)
|
||||
|
||||
|
||||
Integration of static sharding in go-waku is continuing (see updates below).
|
||||
Testing of PostgreSQL enabled some performance improvement in the implementation that are being implemented.
|
||||
Internal instructions have been distributed to dogfood static sharding with the Waku team ([Waku Discord private channel](https://discord.com/channels/1110799176264056863/1166125031793901589/1166125169480306708)).
|
||||
- Integration of static sharding in go-waku is continuing (see updates below).
|
||||
- Testing of PostgreSQL enabled some performance improvement in the implementation that are being implemented.
|
||||
- Internal instructions have been distributed to dogfood static sharding with the Waku team ([Waku Discord private channel](https://discord.com/channels/1110799176264056863/1166125031793901589/1166125169480306708)).
|
||||
- _risks_:
|
||||
- Dependency on Vac/DST to conclude ~1k nodes simulations.
|
||||
- Implementation of static sharding in Status Communities and design decisions mostly driven by go-waku developer, with minimal input from Status dev ([1](https://github.com/status-im/status-go/pull/4161), [2](https://github.com/status-im/status-go/pull/4094), [3](https://github.com/status-im/status-go/pull/4093)). See [status-go#4057](https://github.com/status-im/status-go/issues/4057) for remaining work. Mitigation by on-boarding Chat SDK lead on 6 Nov to drive effort.
|
||||
|
|
@ -41,7 +41,7 @@ Internal instructions have been distributed to dogfood static sharding with the
|
|||
**[nwaku] [PostgreSQL](https://github.com/waku-org/nwaku/issues/1888)**
|
||||
|
||||
- _achieved_:
|
||||
- Time processing enhancement when performing _SELECT_ operations. There was an overhead caused by looping too many times over the returned rows, in order to convert the row types. By applying a "rowCallback" approach we can reduce in 30ms the time spent on the query under analysis.
|
||||
- Time processing enhancement when performing _SELECT_ operations. There was an overhead caused by looping too many times over the returned rows, in order to convert the row types. By applying a "rowCallback" approach we can reduce by 30ms the time spent on the query under analysis.
|
||||
- _next_:
|
||||
- The queries used in the comparison analysis still perform much better in _SQLite_ (< ~5ms) than in _Postgres_ (< ~15ms.) Therefore we need to push the investigation further to enhance that.
|
||||
|
||||
|
|
@ -64,6 +64,10 @@ Internal instructions have been distributed to dogfood static sharding with the
|
|||
- _achieved_: learnt about waku-simulator's inner workings and got the background required to integrate RLN to it. Added service that generates traffic to the nodes via their REST APIs. Investigated and tested different ways of approaching the RLN integration.
|
||||
- _next_: get RLN to work and add Grafana dashboards with RLN data
|
||||
|
||||
**[js-waku-examples] [feat: re-create rln-js](https://github.com/waku-org/js-waku-examples/issues/279)**
|
||||
|
||||
- _achieved_: addressed flaws in integration, completed rewriting;
|
||||
|
||||
**[research] [Tuning GossipSub's D parameter in Waku](https://github.com/waku-org/research/issues/44)**
|
||||
|
||||
* *achieved*: nwaku simulations showing the impact in message propagation delay when reducing gossipsub's D value. Main goal is to reduce bandwidth consumption in exchange of worsen propagation delay.
|
||||
|
|
@ -99,14 +103,16 @@ Internal instructions have been distributed to dogfood static sharding with the
|
|||
**[nwaku] [feat: add new message_hash column to the archive protocol](https://github.com/waku-org/nwaku/issues/2112)**
|
||||
|
||||
- _achieved_: On SQLite's schema transition (i.e. this PR) to `messageHash` feature complete PR posted (awaiting reviews), Gained insight into the connection and interplay between the store and archive components, and how they may be leveraged into making a sync protocol. Small stuff - bug fix on the jsWaku which was this PR dependent (that too was time-consuming since my first time interacting with JS code of waku), PR on vacuum on time-based retention policy, thought through the nitty gritty details of node based roles and incentives.
|
||||
- _next_: the sync protocol formulation totally based on the messages sync without any external factors into POV. additional stuff such as PostgreSQL PRs by Ivan to gain more aspects of the storage/archive.
|
||||
- _next_:
|
||||
- The sync protocol formulation totally based on the messages sync without any external factors into POV
|
||||
- Review PostgreSQL PRs by Ivan to gain more knowledge on the storage/archive feature.
|
||||
|
||||
### [2.1: Production testing of existing protocols](https://github.com/waku-org/pm/issues/49)
|
||||
|
||||
**[nwaku] [PostgreSQL](https://github.com/waku-org/nwaku/issues/1888)**
|
||||
|
||||
- _achieved_:
|
||||
- Time processing enhancement when performing _SELECT_ operations. There was an overhead caused by looping too many times over the returned rows, in order to convert the row types. By applying a "rowCallback" approach we can reduce in 30ms the time spent on the query under analysis.
|
||||
- Time processing enhancement when performing _SELECT_ operations. There was an overhead caused by looping too many times over the returned rows, in order to convert the row types. By applying a "rowCallback" approach we can reduce by 30ms the time spent on the query under analysis.
|
||||
- _next_:
|
||||
- The queries used in the comparison analysis still perform much better in _SQLite_ (< ~5ms) than in _Postgres_ (< ~15ms.) Therefore we need to push the investigation further to enhance that.
|
||||
|
||||
|
|
@ -119,6 +125,13 @@ Internal instructions have been distributed to dogfood static sharding with the
|
|||
|
||||
## [Support Many Platforms](https://github.com/waku-org/pm/issues/42) - 2024-04-30
|
||||
|
||||
### [Presentation Readiness ](https://github.com/waku-org/pm/issues/95)
|
||||
|
||||
**[js-waku] [feat: better support for development](https://github.com/waku-org/js-waku/issues/1665)**
|
||||
|
||||
- _achieved_: experimented with [Next.js app](https://github.com/waku-org/js-waku-examples/pull/281);
|
||||
- _next_: looking for ways to mitigate errors in console or catch others;
|
||||
|
||||
### [Ship RLN as part of non-native SDKs](https://github.com/waku-org/pm/issues/88)
|
||||
|
||||
**[go-waku] [refactor: add user_data to c-bindings](https://github.com/waku-org/go-waku/issues/788)**
|
||||
|
|
@ -130,3 +143,19 @@ Internal instructions have been distributed to dogfood static sharding with the
|
|||
**[go-waku] [feat: admin REST API](https://github.com/waku-org/go-waku/issues/814)**
|
||||
|
||||
- _achieved_: Implemented Admin REST API and updated the spec.
|
||||
|
||||
## Ecosystem Development
|
||||
|
||||
- _achieved_:
|
||||
- new tictactoe example with @waku/react
|
||||
- Progress on Devconnect planning
|
||||
- Organising dev ex calls
|
||||
- Shipping resources for hackathon
|
||||
- Reviewed Graphcast proposal for using relay
|
||||
|
||||
- _next_:
|
||||
- ipfs/waku example for file transfer
|
||||
- Waku tutorial videos
|
||||
- @waku/react hacker pain-point feedback report
|
||||
- Metrics dashboard
|
||||
- ETHLisbon
|
||||
|
|
|
|||
Loading…
Reference in New Issue