mirror of https://github.com/logos-co/roadmap.git
72 lines
4.1 KiB
Markdown
72 lines
4.1 KiB
Markdown
|
---
|
||
|
|
title: 2023-10-09 Waku Weekly
|
||
|
|
tags:
|
||
|
|
- waku-updates
|
||
|
|
date: 2023-10-09
|
||
|
|
lastmod: 2023-10-09
|
||
|
|
draft: false
|
||
|
|
---
|
||
|
|
---
|
||
|
|
### nwaku
|
||
|
|
|
||
|
|
**[feat: Implement /admin Rest Api endpoint](https://github.com/waku-org/nwaku/issues/2075)** {E:REST API service node}
|
||
|
|
|
||
|
|
- _achieved_: /admin Rest API endpoint implemented
|
||
|
|
- _next_: Restructure openapi descriptions and producing swagger ui like live document of all rest interfaces. Restructure Rest API schema types.
|
||
|
|
|
||
|
|
**[chore: notify user if docker-compose fails](https://github.com/waku-org/nwaku/issues/2064)** {enhancement}, {E:3.2: Basic DoS protection in production}
|
||
|
|
|
||
|
|
- _achieved_: discussed the issue with colleagues, implemented the solution and closed the issue
|
||
|
|
|
||
|
|
**[feat: allowing users to choose port 0 for dynamically allocated ports](https://github.com/waku-org/nwaku/issues/2042)** {enhancement}
|
||
|
|
|
||
|
|
- _achieved_: analyzed code and found the different data structures affected by the dynamic port allocation. Considered the implications of different approaches to solve the issue, discussed and translated the different options into code.
|
||
|
|
Started the implementation of the chosen solution, with part of the solution already working.
|
||
|
|
- _next_: complete the first working version of the solution, improve its design/architecture, and test.
|
||
|
|
|
||
|
|
**[feat: Service peer selection on specific shards](https://github.com/waku-org/nwaku/issues/1941)** {E:1.4: Sharded peer management and discovery}
|
||
|
|
|
||
|
|
- _achieved_: Filter, Store, Light push REST APIs discovery handler (a rework of the previous solution)
|
||
|
|
|
||
|
|
**[setting up static sharding fleet for Status](https://github.com/waku-org/nwaku/issues/1914)** {E:Static sharding}
|
||
|
|
|
||
|
|
- _achieved_: fleet has been deployed, PostgreSQL setup has been tested.
|
||
|
|
- _next_: Do some basic dogfooding with Status Desktop.
|
||
|
|
|
||
|
|
**[PostgreSQL](https://github.com/waku-org/nwaku/issues/1888)** {E:2.1: Production testing of existing protocols}, {E:PostgreSQL}
|
||
|
|
|
||
|
|
- _achieved_: Applied performance comparison between _SQLite_ and _Postgres_ but in this case, making direct requests from a `go-waku` unittest that @richard-ramos had prepared.
|
||
|
|
After directly comparing the _Store_ protocol, noticed that the bottle neck is within the database itself. i.e. the _SQLite_ database performs better than _Postgres_, given that we have a very simple schema and simple queries, without joins. Adding indexes to the _Postgres_ database didn't help very much. For example, given the same query, _SQLite_ takes 1ms whereas _Postgres_ takes 6ms.
|
||
|
|
- _next_:
|
||
|
|
- Wrap up the _Store_ testing environment and install it into our sandbox machine, `metal-01.he-eu-hel1.wakudev.misc.statusim.net`, so that anyone can proceed from this point (two databases with the same dataset of ~2 million rows .) in case someone is keen on analyzing performance or debug in a more realistic testing scenery. This will include concurrent queries from multiple nodes, where PostgreSQL is expected to perform better.
|
||
|
|
- Start extracting the database creation and indexes creation to outside the code base.
|
||
|
|
|
||
|
|
**[chore: add retention policy with GB or MB limitation](https://github.com/waku-org/nwaku/issues/1885)** {enhancement}, {E:PostgreSQL}
|
||
|
|
|
||
|
|
In review: the database bug to delete limited messages/rows
|
||
|
|
Upcoming/working: updated retention policy + test + missing tes on timestamp based retention policy
|
||
|
|
Undergoing: MUID concept on message level
|
||
|
|
|
||
|
|
**[feat: provide a way to define advertised addresses](https://github.com/waku-org/nwaku/issues/1797)** {enhancement}
|
||
|
|
|
||
|
|
- _achieved_: went over the code and found the root cause of the issue and a preliminary solution
|
||
|
|
- _next_: finish discussing the approach to the solution and implement it
|
||
|
|
|
||
|
|
---
|
||
|
|
### js-waku
|
||
|
|
|
||
|
|
**[Static Sharding](https://github.com/waku-org/js-waku/issues/1310)** {E:Static sharding}
|
||
|
|
|
||
|
|
- _achieved_: PR open for allowing peer management for multiple pubsub topics/shard
|
||
|
|
- _next_: getting reviews & releasing
|
||
|
|
|
||
|
|
**[Peer Management: Connection and Disconnection](https://github.com/waku-org/js-waku/issues/914)** {track:restricted-run}, {E:2.1: Production testing of existing protocols}
|
||
|
|
|
||
|
|
- _achieved_: investigated & closed #1412
|
||
|
|
- _next_: look into addressing deliberate vs accidental disconnections
|
||
|
|
|
||
|
|
---
|
||
|
|
### go-waku
|
||
|
|
|
||
|
|
- Team attended EthRome
|