logos-co
/
roadmap
mirror of https://github.com/logos-co/roadmap.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

updates to date

This commit is contained in:
Corey 2023-08-03 11:58:55 -04:00
parent 1f7e9e3d93
commit 34cf2696f9
14 changed files with 1096 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
content/_index.md
View File

@ -8,4 +8,6 @@ This site attempts to inform the previous, current, and future work required to
- [Vac updates](tags/vac-updates)
- [Waku updates](tags/waku-updates)
- [Codex updates](tags/codex-updates)
- [Nomos updates](tags/nomos-updates)
- [Nomos updates](tags/nomos-updates)
- [Innovation Lab updates](tags/ilab-updates)
- [Comms updates](tags/acid-updates)

48
content/roadmap/acid/updates/2023-08-02.md Normal file
View File

@ -0,0 +1,48 @@
---
title: "2023-08-02 Acid weekly"
tags:
- "acid-updates"
date: 2023-08-03
lastmod: 2023-08-03
draft: false
---
## Leads roundup - acid
**Al / Comms**
- Status app relaunch comms campaign plan in the works. Approx. date for launch 31.08.
- Logos comms + growth plan post launch is next up TBD.
- Will be waiting for specs for data room, raise etc.
- Hires: split the role for content studio to be more realistic in getting top level talent.
**Matt / Copy**
- Initiative updating old documentation like CC guide to reflect broader scope of BUs
- Brand guidelines/ modes of presentation are in process
- Wikipedia entry on network states and virtual states is live on
**Eddy / Digital Comms**
- Logos Discord will be completed by EOD.
- Codex Discord will be done tomorrow.
- LPE rollout plan, currently working on it, will be ready EOW
- Podcast rollout needs some
- Overarching BU plan will be ready in next couple of weeks as things on top have taken priority.
**Amir / Studio**
- Started execution of LPE for new requirements, broken down in smaller deliveries. Looking to have it working and live by EOM.
- Hires: still looking for 3 positions with main focus on developer side.
**Jonny / Podcast**
- Podcast timelines are being set. In production right now. Nick delivered graphics for HiO but we need a full pack.
- First HiO episode is in the works. Will be ready in 2 weeks to fit in the rollout of the LPE.
**Louisa / Events **
- Global strategy paper for wider comms plan.
- Template for processes and executions when preparing events.
- Decision made with Carl to move Network State event to November in satellite of other events. Looking into ETH Lisbon / Staking Summit etc.
- Seoul Q4 hackathon is already in the works. Needs bounty planning.

319
content/roadmap/codex/updates/2023-07-21.md Normal file
View File

@ -0,0 +1,319 @@
---
title: "2023-07-21 Codex weekly"
tags:
- "codex-updates"
date: 2023-07-21
lastmod: 2023-08-03
draft: false
---
## Codex update 07/12/2023 to 07/21/2023
Overall we continue working in various directions, distributed testing, marketplace, p2p client, research, etc...
Our main milestone is to have a fully functional testnet with the marketplace and durability guarantees deployed by end of year. A lot of grunt work is being done to make that possible. Progress is steady, but there are lots of stabilization and testing & infra related work going on.
We're also onboarding several new members to the team (4 to be precise), this will ultimately accelerate our progress, but it requires some upfront investment from some of the more experienced team members.
### DevOps/Infrastructure:
- Adopted nim-codex Docker builds for Dist Tests.
- Ordered Dedicated node on Hetzner.
- Configured Hetzner StorageBox for local backup on Dedicated server.
- Configured new Logs shipper and Grafana in Dist-Tests cluster.
- Created Geth and Prometheus Docker images for Dist-Tests.
- Created a separate codex-contracts-eth Docker image for Dist-Tests.
- Set up Ingress Controller in Dist-Tests cluster.
### Testing:
- Set up deployer to gather metrics.
- Debugging and identifying potential deadlock in the Codex client.
- Added metrics, built image, and ran tests.
- Updated dist-test log for Kibana compatibility.
- Ran dist-tests on a new master image.
- Debugging continuous tests.
### Development:
- Worked on codex-dht nimble updates and fixing key format issue.
- Updated CI and split Windows CI tests to run on two CI machines.
- Continued updating dependencies in codex-dht.
- Fixed decoding large manifests ([PR #479](https://github.com/codex-storage/nim-codex/pull/497)).
- Explored the existing implementation of NAT Traversal techniques in `nim-libp2p`.
### Research
- Exploring additional directions for remote verification techniques and the interplay of different encoding approaches and cryptographic primitives
- https://eprint.iacr.org/2021/1500.pdf
- https://dankradfeist.de/ethereum/2021/06/18/pcs-multiproofs.html
- https://eprint.iacr.org/2021/1544.pdf
- Onboarding Balázs as our ZK researcher/engineer
- Continued research in DAS related topics
- Running simulation on newly setup infrastructure
- Devised a new direction to reduce metadata overhead and enable remote verification https://github.com/codex-storage/codex-research/blob/master/design/metadata-overhead.md
- Looked into NAT Traversal ([issue #166](https://github.com/codex-storage/nim-codex/issues/166)).
### Cross-functional (Combination of DevOps/Testing/Development):
- Fixed discovery related issues.
- Planned Codex Demo update for the Logos event and prepared environment for the demo.
- Described requirements for Dist Tests logs format.
- Configured new Logs shipper and Grafana in Dist-Tests cluster.
- Dist Tests logs adoption requirements - Updated log format for Kibana compatibility.
- Hetzner Dedicated server was configured.
- Set up Hetzner StorageBox for local backup on Dedicated server.
- Configured new Logs shipper in Dist-Tests cluster.
- Setup Grafana in Dist-Tests cluster.
- Created a separate codex-contracts-eth Docker image for Dist-Tests.
- Setup Ingress Controller in Dist-Tests cluster.
---
#### Conversations
1. zk_id _—_ 07/24/2023 11:59 AM
>
> We've explored VDI for rollups ourselves in the last week, curious to know your thoughts
2. dryajov _—_ 07/25/2023 1:28 PM
>
> It depends on what you mean, from a high level (A)VID is probably the closest thing to DAS in academic research, in fact DAS is probably either a subset or a superset of VID, so it's definitely worth digging into. But I'm not sure what exactly you're interested in, in the context of rollups...
1. zk_id _—_ 07/25/2023 3:28 PM
The part of the rollups seems to be the base for choosing proofs that scale linearly with the amount of nodes (which makes it impractical for large numbers of nodes). The protocol is very simple, and would only need to instead provide constant proofs with the Kate commitments (at the cost of large computational resources is my understanding). This was at least the rationale that I get from reading the paper and the conversation with Bunz, one of the founders of the Espresso shared sequencer (which is where I found the first reference to this paper). I guess my main open question is why would you do the sampling if you can do VID in the context of blockchains as well. With the proofs of dispersal on-chain, you wouldn't need to do that for the agreement of the dispersal. You still would need the sampling for the light clients though, of course.
2. dryajov _—_ 07/25/2023 8:31 PM
> I guess my main open question is why would you do the sampling if you can do VID in the context of blockchains as well. With the proofs of dispersal on-chain, you wouldn't need to do that for the agreement of the dispersal.
Yeah, great question. What follows is strictly IMO, as I haven't seen this formally contrasted anywhere, so my reasoning can be wrong in subtle ways.
- (A)VID - **dispersing** and storing data in a verifiable manner
- Sampling - verifying already **dispersed** data
tl;dr Sampling allows light nodes to protect against dishonest majority attacks. In other words, a light node cannot be tricked to follow an incorrect chain by a dishonest validator majority that withholds data. More details are here - [https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html "https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html") ------------- First, DAS implies (A)VID, as there is an initial phase where data is distributed to some subset of nodes. Moreover, these nodes, usually the validators, attest that they received the data and that it is correct. If a majority of validators accepts, then the block is considered correct, otherwise it is rejected. This is the verifiable dispersal part. But what if the majority of validators are dishonest? Can you prevent them from tricking the rest of the network from following the chain?
Dankrad Feist
[Data availability checks](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html)
Primer on data availability checks
3. _[_8:31 PM_]_
## Dealing with dishonest majorities
This is easy if all the data is downloaded by all nodes all the time, but we're trying to avoid just that. But lets assume, for the sake of the argument, that there are full nodes in the network that download all the data and are able to construct fraud proofs for missing data, can this mitigate the problem? It turns out that it can't, because proving data (un)availability isn't a directly attributable fault - in other words, you can observe/detect it but there is no way you can prove it to the rest of the network reliably. More details here [https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding "https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding") So, if there isn't much that can be done by detecting that a block isn't available, what good is it for? Well nodes can still avoid following the unavailable chain and thus be tricked by a dishonest majority. However, simply attesting that data has been publishing is not enough to prevent a dishonest majority from attacking the network. (edited)
4. dryajov _—_ 07/25/2023 9:06 PM
To complement, the relevant quote from [https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding "https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding"), is:
> Here, fraud proofs are not a solution, because not publishing data is not a uniquely attributable fault - in any scheme where a node ("fisherman") has the ability to "raise the alarm" about some piece of data not being available, if the publisher then publishes the remaining data, all nodes who were not paying attention to that specific piece of data at that exact time cannot determine whether it was the publisher that was maliciously withholding data or whether it was the fisherman that was maliciously making a false alarm.
The relevant quote from from [https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html "https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html"), is:
> There is one gap in the solution of using fraud proofs to protect light clients from incorrect state transitions: What if a consensus supermajority has signed a block header, but will not publish some of the data (in particular, it could be fraudulent transactions that they will publish later to trick someone into accepting printed/stolen money)? Honest full nodes, obviously, will not follow this chain, as they can’t download the data. But light clients will not know that the data is not available since they don’t try to download the data, only the header. So we are in a situation where the honest full nodes know that something fishy is going on, but they have no means of alerting the light clients, as they are missing the piece of data that might be needed to create a fraud proof.
Both articles are a bit old, but the intuitions still hold.
July 26, 2023
6. zk_id _—_ 07/26/2023 10:42 AM
Thanks a ton @dryajov ! We are on the same page. TBH it took me a while to get to this point, as it's not an intuitive problem at first. The relationship between the VID and the DAS, and what each is for is crucial for us, btw. Your writing here and your references give us the confidence that we understand the problem and are equipped to evaluate the different solutions. Deeply appreciate that you took the time to write this, and is very valuable.
7. _[_10:45 AM_]_
The dishonest majority is critical scenario for Nomos (essential part of the whole sovereignty narrative), and generally not considered by most blockchain designs
8. zk_id
Thanks a ton @dryajov ! We are on the same page. TBH it took me a while to get to this point, as it's not an intuitive problem at first. The relationship between the VID and the DAS, and what each is for is crucial for us, btw. Your writing here and your references give us the confidence that we understand the problem and are equipped to evaluate the different solutions. Deeply appreciate that you took the time to write this, and is very valuable.
### dryajov _—_ 07/26/2023 4:42 PM
Great! Glad to help anytime
9. zk_id
The dishonest majority is critical scenario for Nomos (essential part of the whole sovereignty narrative), and generally not considered by most blockchain designs
dryajov _—_ 07/26/2023 4:43 PM
Yes, I'd argue it is crucial in a network with distributed validation, where all nodes are either fully light or partially light nodes.
10. _[_4:46 PM_]_
Btw, there is probably more we can share/compare notes on in this problem space, we're looking at similar things, perhaps from a slightly different perspective in Codex's case, but the work done on DAS with the EF directly is probably very relevant for you as well
July 27, 2023
12. zk_id _—_ 07/27/2023 3:05 AM
I would love to. Do you have those notes somewhere?
13. zk_id _—_ 07/27/2023 4:01 AM
all the links you have, anything, would be useful
14. zk_id
I would love to. Do you have those notes somewhere?
dryajov _—_ 07/27/2023 4:50 PM
A bit scattered all over the place, mainly from @Leobago and @cskiraly @cskiraly has a draft paper somewhere
July 28, 2023
16. zk_id _—_ 07/28/2023 5:47 AM
Would love to see anything that is possible
17. _[_5:47 AM_]_
Our setting is much simpler, but any progress that you make (specifically in the computational cost of the polynomial commitments or alternative proofs) would be really useful for us
18. zk_id
Our setting is much simpler, but any progress that you make (specifically in the computational cost of the polynomial commitments or alternative proofs) would be really useful for us
dryajov _—_ 07/28/2023 4:07 PM
Yes, we're also working in this direction as this is crucial for us as well. There should be some result coming soon(tm), now that @bkomuves is helping us with this part.
19. zk_id
Our setting is much simpler, but any progress that you make (specifically in the computational cost of the polynomial commitments or alternative proofs) would be really useful for us
bkomuves _—_ 07/28/2023 4:44 PM
my current view (it's changing pretty often :) is that there is tension between:
- commitment cost
- proof cost
- and verification cost
the holy grail which is the best for all of them doesn't seem to exist. Hence, you have to make tradeoffs, and it depends on your specific use case what you should optimize for, or what balance you aim for. we plan to find some points in this 3 dimensional space which are hopefully close to the optimal surface, and in parallel to that figure out what balance to aim for, and then choose a solution based on that (and also based on what's possible, there are external restrictions)
July 29, 2023
21. bkomuves
my current view (it's changing pretty often :) is that there is tension between: 
- commitment cost
- proof cost
- and verification cost
 the holy grail which is the best for all of them doesn't seem to exist. Hence, you have to make tradeoffs, and it depends on your specific use case what you should optimize for, or what balance you aim for. we plan to find some points in this 3 dimensional space which are hopefully close to the optimal surface, and in parallel to that figure out what balance to aim for, and then choose a solution based on that (and also based on what's possible, there are external restrictions)
zk_id _—_ 07/29/2023 4:23 AM
I agree. That's also my understanding (although surely much more superficial).
22. _[_4:24 AM_]_
There is also the dimension of computation vs size cost
23. _[_4:25 AM_]_
ie the VID scheme (of the paper that kickstarted this conversation) has all the properties we need, but it scales n^2 in message complexity which makes it lose the properties we are looking for after 1k nodes. We need to scale confortably to 10k nodes.
24. _[_4:29 AM_]_
So we are at the moment most likely to use KZG commitments with a 2d RS polynomial. Basically just copy Ethereum. Reason is:
- Our rollups/EZ leader will generate this, and those are beefier machines than the Base Layer. The base layer nodes just need to verify and sign the EC fragments and return them to complete the VID protocol (and then run consensus on the aggregated signed proofs).
- If we ever decide to change the design for the VID dispersal to be done by Base Layer leaders (in a multileader fashion), it can be distributed (rows/columns can be reconstructed and proven separately). I don't think we will pursue this, but we will have to if this scheme doesn't scale with the first option.
August 1, 2023
26. dryajov
A bit scattered all over the place, mainly from @Leobago and @cskiraly @cskiraly has a draft paper somewhere
Leobago _—_ 08/01/2023 1:13 PM
Note much public write-ups yet. You can find some content here:
- [https://blog.codex.storage/data-availability-sampling/](https://blog.codex.storage/data-availability-sampling/ "https://blog.codex.storage/data-availability-sampling/")
- [https://github.com/codex-storage/das-research](https://github.com/codex-storage/das-research "https://github.com/codex-storage/das-research")
We also have a few Jupiter notebooks but they are not public yet. As soon as that content is out we can let you know ![🙂](https://discord.com/assets/da3651e59d6006dfa5fa07ec3102d1f3.svg)
Codex Storage Blog
[Data Availability Sampling](https://blog.codex.storage/data-availability-sampling/)
The Codex team is busy building a new web3 decentralized storage platform with the latest advances in erasure coding and verification systems. Part of the challenge of deploying decentralized storage infrastructure is to guarantee that the data that has been stored and is available for retrieval from the beginning until
GitHub
[GitHub - codex-storage/das-research: This repository hosts all the ...](https://github.com/codex-storage/das-research)
This repository hosts all the research on DAS for the collaboration between Codex and the EF. - GitHub - codex-storage/das-research: This repository hosts all the research on DAS for the collabora...
[](https://opengraph.githubassets.com/39769464ebae80ca62c111bf2acb6af95fde1b9dc6e3c5a9eb56316ea363e3d8/codex-storage/das-research)
![GitHub - codex-storage/das-research: This repository hosts all the ...](https://images-ext-2.discordapp.net/external/DxXI-YBkzTrPfx_p6_kVpJzvVe6Ix6DrNxgrCbcsjxo/https/opengraph.githubassets.com/39769464ebae80ca62c111bf2acb6af95fde1b9dc6e3c5a9eb56316ea363e3d8/codex-storage/das-research?width=400&height=200)
27. zk_id
So we are at the moment most likely to use KZG commitments with a 2d RS polynomial. Basically just copy Ethereum. Reason is: 
- Our rollups/EZ leader will generate this, and those are beefier machines than the Base Layer. The base layer nodes just need to verify and sign the EC fragments and return them to complete the VID protocol (and then run consensus on the aggregated signed proofs).
- If we ever decide to change the design for the VID dispersal to be done by Base Layer leaders (in a multileader fashion), it can be distributed (rows/columns can be reconstructed and proven separately). I don't think we will pursue this, but we will have to if this scheme doesn't scale with the first option.
dryajov _—_ 08/01/2023 1:55 PM
This might interest you as well - [https://blog.subspace.network/combining-kzg-and-erasure-coding-fc903dc78f1a](https://blog.subspace.network/combining-kzg-and-erasure-coding-fc903dc78f1a "https://blog.subspace.network/combining-kzg-and-erasure-coding-fc903dc78f1a")
Medium
[Combining KZG and erasure coding](https://blog.subspace.network/combining-kzg-and-erasure-coding-fc903dc78f1a)
The Hitchhiker’s Guide to Subspace  — Episode II
[](https://miro.medium.com/v2/resize:fit:1200/0*KGb5QHFQEd0cvPeP.png)
![Combining KZG and erasure coding](https://images-ext-2.discordapp.net/external/LkoJxMEskKGMwVs8XTPVQEEu0senjEQf42taOjAYu0k/https/miro.medium.com/v2/resize%3Afit%3A1200/0%2AKGb5QHFQEd0cvPeP.png?width=400&height=200)
28. _[_1:56 PM_]_
This is a great analysis of the current state of the art in structure of data + commitment and the interplay. I would also recoment reading the first article of the series which it also links to
29. zk_id _—_ 08/01/2023 3:04 PM
Thanks @dryajov @Leobago ! Much appreciated!
30. _[_3:05 PM_]_
Very glad that we can discuss these things with you. Maybe I have some specific questions once I finish reading a huge pile of pending docs that I'm tackling starting today...
31. zk_id _—_ 08/01/2023 6:34 PM
@Leobago @dryajov I was playing with the DAS simulator. It seems the results are a bunch of XML. Is there a way so I visualize the results?
32. zk_id
@Leobago @dryajov I was playing with the DAS simulator. It seems the results are a bunch of XML. Is there a way so I visualize the results?
Leobago _—_ 08/01/2023 6:36 PM
Yes, checkout the visual branch and make sure to enable plotting in the config file, it should produce a bunch of figures ![🙂](https://discord.com/assets/da3651e59d6006dfa5fa07ec3102d1f3.svg)
33. _[_6:37 PM_]_
You might find also some bugs here and there on that branch ![😅](https://discord.com/assets/b45af785b0e648fe2fb7e318a6b8010c.svg)
34. zk_id _—_ 08/01/2023 7:44 PM
Thanks!

60
content/roadmap/codex/updates/2023-08-01.md Normal file
View File

@ -0,0 +1,60 @@
---
title: "2023-08-01 Codex weekly"
tags:
- "codex-updates"
date: 2023-08-01
lastmod: 2023-08-03
draft: false
---
# Codex update Aug 1st
## Client
### Milestone: Merkelizing block data
- Initial design writeup https://github.com/codex-storage/codex-research/blob/master/design/metadata-overhead.md
- Work break down and review for Ben and Tomasz (epic coming up)
- This is required to integrate the proving system
### Milestone: Block discovery and retrieval
- Some initial work break down and milestones here - https://docs.google.com/document/d/1hnYWLvFDgqIYN8Vf9Nf5MZw04L2Lxc9VxaCXmp9Jb3Y/edit
- Initial analysis of block discovery - https://rpubs.com/giuliano_mega/1067876
- Initial block discovery simulator - https://gmega.shinyapps.io/block-discovery-sim/
### Milestone: Distributed Client Testing
- Lots of work around log collection/analysis and monitoring
- Details here https://github.com/codex-storage/cs-codex-dist-tests/pull/41
## Marketplace
### Milestone: L2
- Taiko L2 integration
- This is a first try of running against an L2
- Mostly done, waiting on related fixes to land before merge - https://github.com/codex-storage/nim-codex/pull/483
### Milestone: Reservations and slot management
- Lots of work around slot reservation and queuing https://github.com/codex-storage/nim-codex/pull/455
## Remote auditing
### Milestone: Implement Poseidon2
- First pass at an implementation by Balazs
- private repo, but can give access if anyone is interested
### Milestone: Refine proving system
- Lost of thinking around storage proofs and proving systems
- private repo, but can give access if anyone is interested
## DAS
### Milestone: DHT simulations
- Implementing a DHT in Python for the DAS simulator.
- Implemented logical error-rates and delays to interactions between DHT clients.

48
content/roadmap/innovation_lab/updates/2023-07-12.md Normal file
View File

@ -0,0 +1,48 @@
---
title: "2023-07-12 Innovation Lab Weekly"
tags:
- "ilab-updates"
date: 2023-07-12
lastmod: 2023-08-03
---
**Logos Lab** 12th of July
Currently working on the Waku Objects prototype, which is a modular system for transactional chat objects.
**Milestone**: deliver the first transactional Waku Object called Payggy (attached some design screenshots).
It is now possible to make transactions on the blockchain and the objects send notifications over the messaging layer (e.g. Waku) to the other participants. What is left is the proper transaction status management and some polishing.
There is also work being done on supporting external objects, this enables creating the objects with any web technology. This work will guide the separation of the interfaces between the app and the objects and lead us to release it as an SDK.
**Next milestone**: group chat support
The design is already done for the group chat functionality. There is ongoing design work for a new Waku Object that would showcase what can be done in a group chat context.
Deployed version of the main branch:
https://waku-objects-playground.vercel.app/
Link to Payggy design files:
https://scene.zeplin.io/project/64ae9e965652632169060c7d
Main development repo:
https://github.com/logos-innovation-lab/waku-objects-playground
Contact:
You can find us at https://discord.com/channels/973324189794697286/1118949151225413872 or join our discord at https://discord.gg/UtVHf2EU
---
#### Conversation
1. petty _—_ 07/15/2023 5:49 AM
the `waku-objects` repo is empty. Where is the code storing that part vs the playground that is using them?
2. petty
the `waku-objects` repo is empty. Where is the code storing that part vs the playground that is using them?
3. attila🍀 _—_ 07/15/2023 6:18 AM
at the moment most of the code is in the `waku-objects-playground` repo later we may split it to several repos here is the link: [https://github.com/logos-innovation-lab/waku-objects-playground](https://github.com/logos-innovation-lab/waku-objects-playground "https://github.com/logos-innovation-lab/waku-objects-playground")

75
content/roadmap/innovation_lab/updates/2023-08-02.md Normal file
View File

@ -0,0 +1,75 @@
---
title: "2023-08-02 Innovation Lab weekly"
tags:
- "ilab-updates"
date: 2023-08-02
lastmod: 2023-08-03
draft: false
---
**Logos Lab** 2nd of August
Currently working on the Waku Objects prototype, which is a modular system for transactional chat objects.
The last few weeks were a bit slower than usual because there were vacations, one team member got married, there was EthCC and a team offsite.
Still, a lot of progress were made and the team released the first version of a color system in the form of an npm package, which lets the users to choose any color they like to customize their app. It is based on grayscale design and uses luminance, hence the name of the library. Try it in the Playground app or check the links below.
**Milestone**: group chat support
There is a draft PR for group chat support for private groups and it is expected to be finished this week. At the end we decided to roll our own toy group chat protocol implementation because we did not find anything ready to use. It would have been great if we could have just used an existing implementation.
**Next milestone**: Splitter Waku Object supporting group chats and smart contracts
This will be the first Waku Object that is meaningful in a group chat context. Also this will demonstrate how to use smart contracts and multiparty transactions.
Deployed version of the main branch:
https://waku-objects-playground.vercel.app/
Main development repo:
https://github.com/logos-innovation-lab/waku-objects-playground
Grayscale design:
https://grayscale.design/
Luminance package on npm:
https://www.npmjs.com/package/@waku-objects/luminance
Contact:
You can find us at https://discord.com/channels/973324189794697286/1118949151225413872 or join our discord at https://discord.gg/ZMU4yyWG
---
### Conversation
1. fryorcraken _—_ Yesterday at 10:58 PM
> There is a draft PR for group chat support for private groups and it is expected to be finished this week. At the end we decided to roll our own toy group chat protocol implementation because we did not find anything ready to use. It would have been great if we could have just used an existing implementation.
While status-js does implement chat features, I do not know how nice the API is. Waku is actively hiring a chat sdk lead and golang eng. We will probably also hire a JS engineer (not yet confirmed) to provide nice libraries to enable such use case (1:1 chat, group chat, community chat).
August 3, 2023
2. fryorcraken
> > There is a draft PR for group chat support for private groups and it is expected to be finished this week. At the end we decided to roll our own toy group chat protocol implementation because we did not find anything ready to use. It would have been great if we could have just used an existing implementation. While status-js does implement chat features, I do not know how nice the API is. Waku is actively hiring a chat sdk lead and golang eng. We will probably also hire a JS engineer (not yet confirmed) to provide nice libraries to enable such use case (1:1 chat, group chat, community chat).
3. attila🍀 _—_ Today at 4:21 AM
This is great news and I think it will help with adoption. I did not find a JS API for status (maybe I was looking at the wrong places), the closest was the `status-js-api` project but that still uses whisper and the repo recommends to use `js-waku` instead ![🙂](https://discord.com/assets/da3651e59d6006dfa5fa07ec3102d1f3.svg) [https://github.com/status-im/status-js-api](https://github.com/status-im/status-js-api "https://github.com/status-im/status-js-api") Also I also found the `56/STATUS-COMMUNITIES` spec: [https://rfc.vac.dev/spec/56/](https://rfc.vac.dev/spec/56/ "https://rfc.vac.dev/spec/56/") It seems to be quite a complete solution for community management with all the bells and whistles. However our use case is a private group chat for your existing contacts, so it seems to be a bit overkill for that.
4. fryorcraken _—_ Today at 5:32 AM
The repo is status-im/status-web
5. _[_5:33 AM_]_
Spec is [https://rfc.vac.dev/spec/55/](https://rfc.vac.dev/spec/55/ "https://rfc.vac.dev/spec/55/")
6. fryorcraken
The repo is status-im/status-web
7. attila🍀 _—_ Today at 6:05 AM
As constructive feedback I can tell you that it is not trivial to find it and use it in other projects It is presented as a React component without documentation and by looking at the code it seems to provide you the whole chat UI of the desktop app, which is not necessarily what you need if you want to embed it in your app It seems to be using this package: [https://www.npmjs.com/package/@status-im/js](https://www.npmjs.com/package/@status-im/js "https://www.npmjs.com/package/@status-im/js") Which also does not have documentation I assume that package is built from this: [https://github.com/status-im/status-web/tree/main/packages/status-js](https://github.com/status-im/status-web/tree/main/packages/status-js "https://github.com/status-im/status-web/tree/main/packages/status-js") This looks promising, but again there is no documentation. Of course you can use the code to figure out things, but at least I would be interested in what are the requirements and high level architecture (does it require an ethereum RPC endpoint, where does it store data, etc.) so that I can evaluate if this is the right approach for me. So maybe a lesson here is to put effort in the documentation and the presentation as well and if you have the budget then have someone on the team whose main responsibility is that (like a devrel or dev evangelist role)

36
content/roadmap/nomos/updates/2023-07-24.md Normal file
View File

@ -0,0 +1,36 @@
---
title: "2023-07-24 Nomos weekly"
tags:
- "nomos-updates"
date: 2023-07-24
lastmod: 2023-08-03
draft: false
---
**Research**
- Milestone 1: Understanding Data Availability (DA) Problem
- High-level exploration and discussion on data availability problems in a collaborative offsite meeting in Paris.
- Explored the necessity and key challenges associated with DA.
- In-depth study of Verifiable Information Dispersal (VID) as it relates to data availability.
- **Blocker:** The experimental tests for our specific EC scheme are pending, which is blocking progress to make final decision on KZG + commitments for our architecture.
- Milestone 2: Privacy for Proof of Stake (PoS)
- Analyzed the capabilities and limitations of mixnets, specifically within the context of timing attacks in private PoS.
- Invested time in understanding timing attacks and how Nym mixnet caters to these challenges.
- Reviewed the Crypsinous paper to understand its privacy vulnerabilities, notably the issue with probabilistic leader election and the vulnerability of anonymous broadcast channels to timing attacks.
**Development**
- Milestone 1: Mixnet and Networking
- Initiated integration of libp2p to be used as the full node's backend, planning to complete in the next phase.
- Begun planning for the next steps for mixnet integration, with a focus on understanding the components of the Nym mixnet, its problem-solving mechanisms, and the potential for integrating some of its components into our codebase.
- Milestone 2: Simulation Application
- Completed pseudocode for Carnot Simulator, created a test pseudocode, and provided a detailed description of the simulation. The relevant resources can be found at the following links:
- Carnot Simulator pseudocode (https://github.com/logos-co/nomos-specs/blob/Carnot-Simulation/carnot/carnot_simulation_psuedocode.py)
- Test pseudocode (https://github.com/logos-co/nomos-specs/blob/Carnot-Simulation/carnot/test_carnot_simulation.py)
- Description of the simulation (https://www.notion.so/Carnot-Simulation-c025dbab6b374c139004aae45831cf78)
- Implemented simulation network fixes and warding improvements, and increased the run duration of integration tests. The corresponding pull requests can be accessed here:
- Simulation network fix (https://github.com/logos-co/nomos-node/pull/262)
- Vote tally fix (https://github.com/logos-co/nomos-node/pull/268)
- Increased run duration of integration tests (https://github.com/logos-co/nomos-node/pull/263)
- Warding improvements (https://github.com/logos-co/nomos-node/pull/269)

46
content/roadmap/nomos/updates/2023-07-31.md Normal file
View File

@ -0,0 +1,46 @@
---
title: "2023-07-31 Nomos weekly"
tags:
- "nomos-updates"
date: 2023-07-31
lastmod: 2023-08-03
draft: false
---
**Nomos 31st July**
[Network implementation and Mixnet]:
Research
- Initial analysis on the mixnet Proof of Concept (PoC) was performed, assessing components like Sphinx for packets and delay-forwarder.
- Considered the use of a new NetworkInterface in the simulation to mimic the mixnet, but currently, no significant benefits from doing so have been identified.
Development
- Fixes were made on the Overlay interface.
- Near completion of the libp2p integration with all tests passing so far, a PR is expected to be opened soon.
- Link to libp2p PRs: https://github.com/logos-co/nomos-node/pull/278, https://github.com/logos-co/nomos-node/pull/279, https://github.com/logos-co/nomos-node/pull/280, https://github.com/logos-co/nomos-node/pull/281
- Started working on the foundation of the libp2p-mixnet transport.
[Private PoS]:
Research
- Discussions were held on the Privacy PoS (PPoS) proposal, aligning a general direction of team members.
- Reviews on the PPoS proposal were done.
- A proposal to merge the PPoS proposal with the efficient one was made, in order to have both privacy and efficiency.
- Discussions on merging Efficient PoS (EPoS) with PPoS are in progress.
[Carnot]:
Research
- Analyzing Bribery attack scenarios, which seem to make Carnot more vulnerable than expected.
**Development**
- Improved simulation application to meet test scale requirements (https://github.com/logos-co/nomos-node/pull/274).
- Created a strategy to solve the large message sending issue in the simulation application.
[Data Availability Sampling (or VID)]:
Research
- Conducted an analysis of stored data "degradation" problem for data availability, modeling fractions of nodes which leave the system at regular time intervals
- Continued literature reading on Verifiable Information Dispersal (VID) for DA problem, as well as encoding/commitment schemes.

71
content/roadmap/vac/updates/2023-07-17.md Normal file
View File

@ -0,0 +1,71 @@
---
title: "2023-07-17 Vac weekly"
tags:
- "vac-updates"
date: 2023-07-17
lastmod: 2023-08-03
draft: false
---
**Last week**
- *vc*
- Vac day in Paris (13th)
- *vc::Deep Research*
- working on comprehensive current/related work study on Validator Privacy
- working on PoC of Tor push in Nimbus: setting up goerli nim-eth2 node
- working towards comprehensive current/related work study on gossipsub scaling
- *vsu::P2P*
- Paris offsite Paris (all CCs)
- *vsu::Tokenomics*
- Bugs found and solved in the SNT staking contract
- attend events in Paris
- *vsu::Distributed Systems Testing*
- Events in Paris
- QoS on all four infras
- Continue work on theoretical gossipsub analysis (varying regular graph sizes)
- Peer extraction using WLS (almost finished)
- Discv5 testing
- Wakurtosis CI improvements
- Provide offline data
- *vip::zkVM*
- onboarding new researcher
- Prepared and presented ZKVM work during VAC offsite
- Deep research on Nova vs Stark in terms of performance and related open questions
- researching Sangria
- Worked on NEscience document (https://www.notion.so/Nescience-WIP-0645c738eb7a40869d5650ae1d5a4f4e)
- zerokit:
- worked on PR for arc-circom
- *vip::RLNP2P*
- offsite Paris
**This week**
- *vc*
- *vc::Deep Research*
- working on comprehensive current/related work study on Validator Privacy
- working on PoC of Tor push in Nimbus
- working towards comprehensive current/related work study on gossipsub scaling
- *vsu::P2P*
- EthCC & Logos event Paris (all CCs)
- *vsu::Tokenomics*
- Attend EthCC and side events in Paris
- Integrate staking contracts with radCAD model
- Work on a new approach for Codex collateral problem
- *vsu::Distributed Systems Testing*
- Events in Paris
- Finish peer extraction, plot the peer connections; script/runs for the analysis, and add data to the Tech Report
- Restructure the Analysis script and start modelling Status control messages
- Split Wakurtosis analysis module into separate repository (delayed)
- Deliver simulation results (incl fixing discv5 error with new Kurtosis version)
- Second iteration Nomos CI
- *vip::zkVM*
- Continue researching on Nova open questions and Sangria
- Draft the benchmark document (by the end of the week)
- research hardware for benchmarks
- research Halo2 cont'
- zerokit:
- merge a PR for deployment of arc-circom
- deal with arc-circom master fail
- *vip::RLNP2P*
- offsite paris
- *blockers*
- *vip::zkVM:zerokit*: ark-circom deployment to crates io; contact to ark-circom team

112
content/roadmap/vac/updates/2023-07-24.md Normal file
View File

@ -0,0 +1,112 @@
---
title: "2023-08-03 Vac weekly"
tags:
- "vac-updates"
date: 2023-08-03
lastmod: 2023-08-03
draft: false
---
NOTE: This is a first experimental version moving towards the new reporting structure:
**Last week**
- *vc*
- *vc::Deep Research*
- milestone (15%, 2023/11/30) paper on gossipsub improvements ready for submission
- related work section
- milestone (15%, 2023/08/31) Nimbus Tor-push PoC
- basic torpush encode/decode ( https://github.com/vacp2p/nim-libp2p-experimental/pull/1 )
- milestone (15%, 2023/11/30) paper on Tor push validator privacy
- (focus on Tor-push PoC)
- *vsu::P2P*
- admin/misc
- EthCC (all CCs)
- *vsu::Tokenomics*
- admin/misc
- Attended EthCC and side events in Paris
- milestone (30%, 2023/09/30) Codex economic analysis, Codex token utility, Codex collateral management
- Kicked off a new approach for Codex collateral problem
- milestone (50%, 2023/08/30) SNT staking smart contract
- Integrated SNT staking contracts with Python
- milestone (50%, 2023/07/14) SNT litepaper
- (delayed)
- milestone(30%, 2023/09/29) Nomos Token: requirements and constraints
- *vsu::Distributed Systems Testing*
- milestone (95%, 2023/07/31) Wakurtosis Waku Report
- Add timout to injection async call in WLS to avoid further issues (PR #139 https://github.com/vacp2p/wakurtosis/pull/139)
- Plotting & analyse 100 msg/s off line Prometehus data
- milestone (90%, 2023/07/31) Nomos CI testing
- fixed errors in Nomos consensus simulation
- milestone (30%, ...) gossipsub model analysis
- add config options to script, allowing to load configs that can be directly compared to Wakurtosis results
- added support for small world networks
- admin/misc
- Interviews & reports for SE and STA positions
- EthCC (1 CC)
- *vip::zkVM*
- milestone(50%, 2023/08/31) background/research on existing proof systems (nova, sangria...)
- (write ups will be available here: https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451)
- Solved the open questions on Nova adn completed the document (will update the page)
- Reviewed Nescience and working on a document
- Reviewed partly the write up on FHE
- writeup for Nova and Sangria; research on super nova
- reading a new paper revisiting Nova (https://eprint.iacr.org/2023/969)
- milestone (50%, 2023/08/31) new fair benchmarks + recursive implementations
- zkvm
- Researching Nova to understand the folding technique for ZKVM adaptation
- zerokit
- Rostyslav became circom-compat maintainer
- *vip::RLNP2P*
- milestone (100%, 2023/07/31) rln-relay testnet 3 completed and retro
- completed
- milestone (95%, 2023/07/31) RLN-Relay Waku production readiness
- admin/misc
- EthCC + offsite
**This week**
- *vc*
- *vc::Deep Research*
- milestone (15%, 2023/11/30) paper on gossipsub improvements ready for submission
- working on contributions section, based on https://hackmd.io/X1DoBHtYTtuGqYg0qK4zJw
- milestone (15%, 2023/08/31) Nimbus Tor-push PoC
- working on establishing a connection via nim-libp2p tor-transport
- setting up goerli test node (cont')
- milestone (15%, 2023/11/30) paper on Tor push validator privacy
- continue working on paper
- *vsu::P2P*
- milestone (...)
- Implement ChokeMessage for GossipSub
- Continue "limited flood publishing" (https://github.com/status-im/nim-libp2p/pull/911)
- *vsu::Tokenomics*
- admin/misc:
- (3 CC days off)
- Catch up with EthCC talks that we couldn't attend (schedule conflicts)
- milestone (50%, 2023/07/14) SNT litepaper
- Start building the SNT agent-based simulation
- *vsu::Distributed Systems Testing*
- milestone (100%, 2023/07/31) Wakurtosis Waku Report
- finalize simulations
- finalize report
- milestone (100%, 2023/07/31) Nomos CI testing
- finalize milestone
- milestone (30%, ...) gossipsub model analysis
- Incorporate Status control messages
- admin/misc
- Interviews & reports for SE and STA positions
- EthCC (1 CC)
- *vip::zkVM*
- milestone(50%, 2023/08/31) background/research on existing proof systems (nova, sangria...)
- Refine the Nescience WIP and FHE documents
- research HyperNova
- milestone (50%, 2023/08/31) new fair benchmarks + recursive implementations
- Continue exploring Nova and other ZKPs and start technical writing on Nova benchmarks
- zkvm
- zerokit
- circom: reach an agreement with other maintainers on master branch situation
- *vip::RLNP2P*
- maintenance
- investigate why docker builds of nwaku are failing [zerokit dependency related]
- documentation on how to use rln for projects interested (https://discord.com/channels/864066763682218004/1131734908474236968/1131735766163267695)(https://ci.infra.status.im/job/nim-waku/job/manual/45/console)
- milestone (95%, 2023/07/31) RLN-Relay Waku production readiness
- revert rln bandwidth reduction based on offsite discussion, move to different validator
- *blockers*

60
content/roadmap/vac/updates/2023-07-31.md Normal file
View File

@ -0,0 +1,60 @@
---
title: "2023-07-31 Vac weekly"
tags:
- "vac-updates"
date: 2023-07-31
lastmod: 2023-08-03
draft: false
---
- *vc::Deep Research*
- milestone (20%, 2023/11/30) paper on gossipsub improvements ready for submission
- proposed solution section
- milestone (15%, 2023/08/31) Nimbus Tor-push PoC
- establishing torswitch and testing code
- milestone (15%, 2023/11/30) paper on Tor push validator privacy
- addressed feedback on current version of paper
- *vsu::P2P*
- nim-libp2p: (100%, 2023/07/31) GossipSub optimizations for ETH's EIP-4844
- Merged IDontWant (https://github.com/status-im/nim-libp2p/pull/934) & Limit flood publishing (https://github.com/status-im/nim-libp2p/pull/911) 𝕏
- This wraps up the "mandatory" optimizations for 4844. We will continue working on stagger sending and other optimizations
- nim-libp2p: (70%, 2023/07/31) WebRTC transport
- *vsu::Tokenomics*
- admin/misc
- 2 CCs off for the week
- milestone (30%, 2023/09/30) Codex economic analysis, Codex token utility, Codex collateral management
- milestone (50%, 2023/08/30) SNT staking smart contract
- milestone (50%, 2023/07/14) SNT litepaper
- milestone (30%, 2023/09/29) Nomos Token: requirements and constraints
- *vsu::Distributed Systems Testing*
- admin/misc
- Analysis module extracted from wakurtosis repo (https://github.com/vacp2p/wakurtosis/pull/142, https://github.com/vacp2p/DST-Analysis)
- hiring
- milestone (99%, 2023/07/31) Wakurtosis Waku Report
- Re-run simulations
- merge Discv5 PR (https://github.com/vacp2p/wakurtosis/pull/129).
- finalize Wakurtosis Tech Report v2
- milestone (100%, 2023/07/31) Nomos CI testing
- delivered first version of Nomos CI integration (https://github.com/vacp2p/wakurtosis/pull/141)
- milestone (30%, 2023/08/31 gossipsub model: Status control messages
- Waku model is updated to model topics/content-topics
- *vip::zkVM*
- milestone(50%, 2023/08/31) background/research on existing proof systems (nova, sangria...)
- achievment :: nova questions answered (see document in Project: https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451)
- Nescience WIP done (to be delivered next week, priority)
- FHE review (lower prio)
- milestone (50%, 2023/08/31) new fair benchmarks + recursive implementations
- Working on discoveries about other benchmarks done on plonky2, starky, and halo2
- zkvm
- zerokit
- fixed ark-circom master
- achievment :: publish ark-circom https://crates.io/crates/ark-circom
- achievment :: publish zerokit_utils https://crates.io/crates/zerokit_utils
- achievment :: publish rln https://crates.io/crates/rln (𝕏 jointly with RLNP2P)
- *vip::RLNP2P*
- milestone (100%, 2023/07/31) RLN-Relay Waku production readiness
- Updated rln-contract to be more modular - and downstreamed to waku fork of rln-contract - https://github.com/vacp2p/rln-contract and http://github.com/waku-org/waku-rln-contract
- Deployed to sepolia
- Fixed rln enabled docker image building in nwaku - https://github.com/waku-org/nwaku/pull/1853
- zerokit:
- achievement :: zerokit v0.3.0 release done - https://github.com/vacp2p/zerokit/releases/tag/v0.3.0 (𝕏 jointly with zkVM)

121
content/roadmap/waku/updates/2023-07-24.md Normal file
View File

@ -0,0 +1,121 @@
---
title: "2023-07-24 Waku weekly"
tags:
- "waku-updates"
date: 2023-07-24
lastmod: 2023-08-03
draft: false
---
Disclaimer: First attempt playing with the format. Incomplete as not everyone is back and we are still adjusting the milestones.
---
### Docs
**Milestone**: Foundation for Waku docs (done)
_achieved_:
- overall layout
- concept docs
- community/showcase pages
**Milestone**: Foundation for node operator docs (done)
_achieved_:
- nodes overview page
- guide for running nwaku (binaries, source, docker)
- peer discovery config guide
- reference docs for config methods and options
**Milestone**: Foundation for js-waku docs
_achieved_:
- js-waku overview + installation guide
- lightpush + filter guide
- store guide
- @waku/create-app guide
_next:_
- improve @waku/react guide
_blocker:_
- polyfills issue with [js-waku](https://github.com/waku-org/js-waku/issues/1415)
**Milestone**: Docs general improvement/incorporating feedback (continuous)
**Milestone**: Running nwaku in the cloud
**Milestone**: Add Waku guide to learnweb3.io
**Milestone**: Encryption docs for js-waku
**Milestone**: Advanced node operator doc (postgres, WSS, monitoring, common config)
**Milestone**: Foundation for go-waku docs
**Milestone**: Foundation for rust-waku-bindings docs
**Milestone**: Waku architecture docs
**Milestone**: Waku detailed roadmap and milestones
**Milestone**: Explain RLN
---
### Eco Dev (WIP)
**Milestone**: EthCC Logos side event organisation (done)
**Milestone**: Community Growth
_achieved_: Wrote several bounties, improved template; setup onboarding flow in Discord.
_next_: Review template, publish on GitHub
**Milestone**: Business Development (continuous)
_achieved_: Discussions with various leads in EthCC
_next_: Booking calls with said leads
**Milestone**: Setting Up Content Strategy for Waku
_achieved_: Discussions with Comms Hubs re Waku Blog, expressed needs and intent around future blog post and needed amplification; discuss strategies to onboard/involve non-dev and potential CTAs.
**Milestone**: Web3Conf (dates)
**Milestone**: DeCompute conf
---
### Research (WIP)
**Milestone**: [Autosharding v1](https://github.com/waku-org/nwaku/issues/1846)
_achieved:_ rendezvous hashing; weighting function; updated LIGHTPUSH to handle autosharding
_next:_
- update FILTER & STORE for autosharding
---
### nwaku (WIP)
**Milestone**: Postgres integration.
_achieved:_
- nwaku can store messages in a Postgres database
- we started to perform stress tests
_next:_
- Analyse why some messages are not stored during stress tests happened in both sqlite and Postgres, so maybe the issue isn't directly related to _store_.
**Milestone**: nwaku as a library (C-bindings)
_achieved:_
- The integration is in progress through N-API framework
_next:_
- Make the nodejs to properly work by running the _nwaku_ node in a separate thread.
---
### go-waku (WIP)
---
### js-waku (WIP)
**Milestone**: [Peer management](https://github.com/waku-org/js-waku/issues/914)
_achieved: spec test for connection manager
**Milestone**: [Peer Exchange](https://github.com/waku-org/js-waku/issues/1429)
**Milestone**: Static Sharding
_next_: start implementation of static sharding in js-waku
**Milestone**: Developer Experience
_achieved_: js-lip2p upgrade to remove usage of polyfills (draft PR)
_next_: merge and release js-libp2p upgrade
**Milestone**: Waku Relay in the Browser
---

88
content/roadmap/waku/updates/2023-07-31.md Normal file
View File

@ -0,0 +1,88 @@
---
title: "2023-07-31 Waku weekly"
tags:
- "waku-updates"
date: 2023-07-31
lastmod: 2023-08-03
draft: false
---
**Waku 31 Jul**
---
Waku
Docs
**Milestone**: Docs general improvement/incorporating feedback (continuous)
_next:_ rewrite docs in British English
**Milestone**: Running nwaku in the cloud
_next:_ publish guides for Digital Ocean, Oracle, Fly.io
---
Waku
Eco Dev (WIP)
---
Waku
Research
**Milestone**: Detailed network requirements and task breakdown
_achieved:_ gathering rough network requirements
_next:_ detailed task breakdown per milestone and effort allocation
**Milestone**: [Autosharding v1](https://github.com/waku-org/nwaku/issues/1846)
_achieved:_ update FILTER & STORE for autosharding
_next:_ RFC review & updates, code review & updates
---
Waku
nwaku
**Milestone**: nwaku release process automation
_next_:
- setup automation to test/simulate current `master` to prevent/limit regressions
- expand target architectures and platforms for release artifacts (e.g. arm64, Win...)
**Milestone**: HTTP Rest API for protocols
_next:_ Filter API added, tests to complete.
---
Waku
go-waku
**Milestone**: Increase Maintability Score. Refer to [CodeClimate report](https://codeclimate.com/github/waku-org/go-waku)
_next:_ define scope on which issues reported by CodeClimate should be fixed. Initially it should be limited to reduce code complexity and duplication.
**Milestone**: RLN updates, refer [issue](https://github.com/waku-org/go-waku/issues/608).
_achieved_: expose `set_tree`, `key_gen`, `seeded_key_gen`, `extended_seeded_keygen`, `recover_id_secret`, `set_leaf`, `init_tree_with_leaves`, `set_metadata`, `get_metadata` and `get_leaf`; created an example on how to use RLN with go-waku; service node can pass in index to keystore credentials and can verify proofs based on bandwidth usage
_next_: merkle tree batch operations (in progress); usage of persisted merkle tree db
**Milestone**: Improve test coverage for functional tests of all protocols. Refer to [CodeClimate report]
_next_: define scope on which code sections should be covered by tests
**Milestone**: C-Bindings
_next_: update API to match nwaku's (by using callbacks instead of strings that require freeing)
---
Waku
js-waku
**Milestone**: [Peer management](https://github.com/waku-org/js-waku/issues/914)
_achieved_: extend ConnectionManager with EventEmitter and dispatch peers tagged with their discovery + make it public on the Waku interface
_next_: fallback improvement for peer connect rejection
**Milestone**: [Peer Exchange](https://github.com/waku-org/js-waku/issues/1429)
_next_: robusting support around peer-exchange for examples;
**Milestone**: Static Sharding
_achieved_: WIP implementation of static sharding in js-waku
_next_: investigation around gauging connection loss;
**Milestone**: Developer Experience
_achieved_: improve & update @waku/react; merge and release js-libp2p upgrade
update examples to latest release + make sure no old/unused packages there
**Milestone**: Maintenance
_next_: update to libp2p@0.46.0
_next_: suit of optional tests in pipeline
---

9
content/templates/update-template.md Normal file
View File

@ -0,0 +1,9 @@
---
title: "<% tp.date.now() %> <TEAM> weekly"
tags:
- "<TEAM>-updates"
date: <% tp.date.now() %>
lastmod: <% tp.date.now() %>
draft: false
---