nwaku
feat: Implement /admin Rest Api endpoint {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 {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 {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 {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 {E:Static sharding}
- achieved: fleet has been deployed, PostgreSQL setup has been tested.
- next: Do some basic dogfooding with Status Desktop.
PostgreSQL {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-wakuunittest 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.
- Wrap up the Store testing environment and install it into our sandbox machine,
chore: add retention policy with GB or MB limitation {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 {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 {E:Static sharding}
- achieved: PR open for allowing peer management for multiple pubsub topics/shard
- next: getting reviews & releasing
Peer Management: Connection and Disconnection {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