# 14/07 - Thursday

Recap of Vac positioning:

Vac products:
- Secure Messaging (mainly "Waku Research") (it also includes the anonymity research)
- zk-WASM (some similarity to zk-EVM, but with focus more towards privacy than scalability)
- RFCs (previously "Research Support": Specs, academic- and other outreach efforts, support-for-researchers role)
- Applied ZK/Explorations

## Administrative assistant role (project manager + secretary):

- Find and booking hotels
- Visa issues
- Twitter
- Reporting
- Interface between some teams (e.g. logos)
- Minutes/Note taking (cf. Jessie's role in attending many meetings and extracting value)
- Following events (e.g. conference deadlines)
- research proposals
- check if requirements are met
- check budget/time plan
- edit and hand-in proposals to respective funding agencies
- Arranging presence at conferences
- Marketing role - e.g. university visits and relationships

## Notes
- discussed the naming, it should be different from Status, to reflect what we are doing with research and PSE, EF etc. The Research & dev does not indicate what we exactly do, like conferences, publications, etc. Vac and Vac research may sound boring.
- [] read the projects, principles and then suggest names and taglines

## Website layout/menu

#### (top level)
- Main
- Oskar
- Principles (move it to the left menu)
- Projects (update with new content), a project may touch multiple research areas
- Research areas (like crypto, distributed systems, indicating them as tag)
- Open problems (specific problems, grants, 2 sentences descirbing the problem, adding links if need be)
- Sanaz + Daniel
- Contribute/Collaborate (How to get startedddContributor's guide, Discord, Forum, GH board, Github issues filter link (e.g. good first issue), Contribute pseudonymously, specific technical problems)
- Daniel + Hanno
- Richard -> Contributors "chart"
- Giuseppe -> Contribute pseudonymously
- Media

#### Research blog posts
- [...]

#### External links/Resources:
- Specs/RFCs
- Forum
- Waku.org

## Github repos

- [ ] Github VAC org -> Update logo
- [ ] Create a Waku GH organization and PIN the repositorires (e.g. status-im/nwaku, status-im/js-waku, etc.)

## RLN (Sanaz)
- [ ] vac.dev/rlnp2p page, as a stand alone page, and image from my presentation with summary of the rfc, write up, discord channel (Sanaz), it should be more than rln primitive as presented by [EF applied zk group](https://appliedzkp.org/), a more user-friendly API, give it to Blagoj, EF, others as a landing page, et review from Oskar

# rln-relay roadmap (Sanaz)
- Getting rln testnet ready
- rln contract: Keshav + Sanaz
- Standardizing the interface
- Fee should be added to the rln contract
- should inherit from the semaphore
- support of multi chain and interoperability with erc 20 tokens
- Integration of zero-kit (cross client): Giuseppe
- rln lib as a stand alone primitive; also applied rln e.g., for anonymous authentication, Sanaz
- Merkle tree optimization: Sanaz
- rln paper: Sanaz

## Qs

- What is meant by Merkle tree optimization? Already ideas here. Minimum to keep only leaves on user side, etc. to reconstruct root.
- Zerokit integration? If final plan, perhaps not too much effort on testing what we have? Won't be too much time.
- Missing things:
- Involve Taylor, esp. w Blagoj afk, already in Discord
- How does this tie into operator story/trial?
- JavaScript implementation for RLN-relay in Waku.
- Zerokit for same circuits
- RLN and RLN circuit (already written)
- RLN-relay in JS, i.e. for Waku
- integration into chat2
- ability to sign up
- tie into testnet effort
- Performance (general)
- could be blog post
- need more good data
- Performance analysis (same as above?)
- Key store and wallet integration (all implementations)
- Wallet integration both in nim and js and go (same as above?)
- Trusted setup (after circuit)
- Circuit and contract audit (ask corey)
- Effort to get core contributors to test RLN-relay
- performance test (to see what is a meaningul optimization of the merkle tree storage), can be only on the nim version
- get it tested by Ccs the nim version
- get it tested by CCs for the cross client version
- write up for the performance
- write up inro to rln-relay to get people test it
- operator story to run rln-relay, like incentivization and priority queue for rln members (talk to Hanno)

# Service credentials (Keshav)

- Quick review of plan:
- relayer nodes, services and service clients
- Tornado Cash model with fund sender, fund receiver and indirection
- Tornado Cash Nova?
- Amortizing gas cost by claiming batch of credentials
- Attack possible by registering in pool without providing Waku

## Qs:

_valid game-theoretical analysis for service incentivization (technical part is mostly clear), what are the underlying assumptions -> output is spec and write-up answering "why this will work", work on contract, TC understanding and investigation including smart contract level_

- What about the game-theoretic aspect? The "plan" is just a mechanism to pay at a high abstraction level.
- Understanding the work for the next (couple of) month(s):
- Focus on the spec and the analysis
- We have to look at game theory: under what conditions would both parties act in each other's best interest? A write-up here.
- Understand the cost of providing the services
- Proof of concept?
- Understand the dependency on other things (e.g. where does fit in in relation w/ RLN)
- If we focus on store, how does that interact w/ capability discovery? Store has online window - do you pay for that?
- Interaction w/ p2p protocols? Payment channels, for example, does it change the waku message, or waku store protocol messages? A new libp2p protocol?
- Code changes in nwaku, etc.
- Credential exchange needs to encrypted e.g., using Noise since peers do not know eachothers ahead

# Anonymity (Daniel)

- Presentation by Daniel (perhaps he can link here?)
- https://forum.vac.dev/t/towards-a-waku-v2-security-analysis/134
- anonymity trilemma:
- low latency and low bandwidth, e.g. Tor
- low bandwidth and strong anonymity, e.g. Mixnets
- strong anonymity and low latency, e.g. ?
- This first step considers for internal attackers that you can get into position. There may be attacks/gossipsub vulnerabilities to get into position earlier (may be in article series).
- Dandilion++:
- PSE did some preliminary research and found that it's not necessarily feasible. Potential gaps in their analysis, though important point: problem of latency. Latter does not necessarily apply to us, but gain understanding - e.g. what guarantees do we get if only two hops. Tradeoffs possible within trilemma for specific applications?
- How long? Mid-September-ish
- Roadmap on Daniel's slide.

# Specs

Raw specs to Draft:

- 31/WAKU2-ENR

Also Noise and Noise sessions?
RLN specs?

Draft specs to stable:
- 13/WAKU2-STORE
- 14/WAKU2-MESSAGE (dependency for most other protocols)
- 15/WAKU2-BRIDGE
- 23/WAKU2-TOPICS (dependency for bridge)
- 10/WAKU2 - remove all not-stable stuff and create new WAKU2 spec in draft
- 33/WAKU2-DISCV5

Open Qs:
- what do we do with 10/WAKU2 integration which is very dynamic
- how should we version 14/WAKU2-MESSAGE?
- FT store?
- filter protocol changes

# Project: Secure Messaging roadmap for next ~3 months (Jul-Oct)

## TEMPLATE: Project (people)

### July

- Task 1
- Milestone 1
- ...
- ... (person)

### Aug

### Sep

### Oct

**TEMPLATE!**

(Sep/Oct can also be combined if too far ahead)

## Anonymity (D)

* [roadmap issue](https://github.com/vacp2p/research/issues/107)

### Sep

* Task: Add new Waku Protocol: Waku-Dandilion
- draft raw RFC: XX/WAKU-DANDILION
- implement in nwaku
- results before devcon

### Oct

* Task: Add new Waku Protocol: Waku-Dandilion
- research: how to reduce latency. Possible routes:
- can dandlion++ be modified (time-box)
- use Waku Tor for low latency applications

* Task: Write research log posts in the anonymity series
- write research log post on Waku-Dandilion
- write research log post: Relay anonymity part 2: Waku message

### Nov

* Task: perform libp2p anonymity study
- do the necessary research
- write research log post

* Task: Add Tor as an anonymization layer to Waku
- write raw RFC on Waku over TOR: XX/WAKU-TOR

### Future (outlook)

* Task: Add Tor as an anonymization layer to Waku
- implement Tor Waku in nwaku
* Task: Write research log posts in the anonymity series
- write research log post on anonymity properties of "resource restricted" protocols

## Service credentials (K, L)

- Game Theory
- Analysis
- Pay first or service first?
- Reputation implementation via Repitation
- Service Gaurantee
- Different benchmarks for all three services - lightpush, filter, store
- Who is more likely to cheat? End user or relayer?

- Difference in incentivization mechanism of lightpush/store/filter
- Lightpush: Send the service credentials with message to the server for publishing
- Store: Make request for history. Server replies with estimated size of history. Client sends the service credentials. Server sends the history.
- Filter: Incentivation mechanism much different than the above two. It is not a single transaction but rather a subscription to the filtered live messages. Client needs to "pre-pay" with credentials to keep receiving the messages. Server notifies the client when all pre-paid credentials have been consumed but new live messages are coming in.

- Writeup / Blogpost

- Protocol specification details (RFCs)
- Lightpush RFC Extension (XX/WAKU-LIGHTPUSH-XYZ)
- Store RFC Extension (XX/WAKU-STORE-XYZ)
- Filter RFC Extension (XX/WAKU-FILTER-XYZ)
+ TBD Depends on the definition of the incentivation model for filter

- nwaku Implementation details (follow RFC)
+ Service credentials storage (shared between protocols)
+ Pay for serv. credentials and reedem of credentials
+ Requirement: secure comm. channel (to prevent front-running)

### Notes on the above:

- July, Aug, Sept division
- Focus on Store as a start (make simplifying assumption of credential per page)
- More concrete tasks. Be mindful of same resources involved with RLN.
- Something for Richard?

## Discovery (D)

* [roadmap issue](https://github.com/status-im/nwaku/issues/879)

### July

* Task: add peer exchange protocol to Waku
- raw RFC: 34/WAKU-PX

* Task: add capability discovery protocol to Waku
- raw RFC: XX/WAKU-CDISC

### Aug

* Task: add peer exchange protocol to Waku
- nwaku implementation

* Task: add capability discovery protocol to Waku
- nwaku implementation

### Future (outlook)

* [Discv5 update](https://github.com/ethereum/devp2p/issues/199)
- research
* DHT academia collaboration

## Store/FT store (S, L)

TODO

## Specs (H,D)

### Sep

- Task: RFC template
- Milestone 1: [finalize RFC template](https://github.com/vacp2p/rfc/pull/488)
- generalize to Waku/Logos/Codex

### Oct

- Task: Get protocols to stable
- Milestone 1: Raw protocols to Draft
- Targeted: 31/WAKU2-ENR, 32/RLN-SPEC ?, 37/WAKU2-NOISE-SESSIONS ?
- Assigned: Hanno
- Milestone 2: Draft protocols to Stable
- Targeted: 10/WAKU2, 13/WAKU2-STORE, 14/WAKU2-MESSAGE, 15/WAKU2-BRIDGE, 23/WAKU2-TOPICS, 33/WAKU2-DISCV5
- Merge FT store wire spec with store (this is what's actually used)
- Strip unstable stuff from 10/WAKU2 and create new WAKU2 draft spec
- Assigned: Hanno

- Draft proposal for filter protocol improvements
- Ambitious milestone for October, but let's try :)
- Could be captured in GH issue
- Assigned: Hanno/Lorenzo/Waku team

#### Notes on above:

- Careful on Status integration - which requires stability
- Move some items earlier

## Noise (G)
(to tailor to incentivation mechanisms or nwaku needs, i.e. we already have encryption available in status: why pushing for noise?)

### July
- Add payload padding
- Split nwaku noise module
- Manage/implement/test backward compatibility with V1 primitives

### August
- Integrate/implement Double-ratchet using PayloadV2 + tests
- Noise+DR PoC in Chat2
- Integrate and promote to draft Noise RFC

### September
- After-handshake anonymity measures:
- anonymity/performance/resources impact analysis for (frequent) contentTopic change
- implement contentTopic change/filter/message retrieval every N messages exchanged (towards session management RFC implementation)
- Session Management:
- Implement device-id assignment logic

### October
- Session Management:
- 2-to-1 example and PoC
- Tests with ChaChaPoly but no Double-ratchet
- independent noise sessions (21=NM)
- session info share and sync among all users devices (2111 = N11M).
- analyze impact of double ratchet secrets' sharing (e.g. session compromise)
- Eventually integrate DR.
- parametrize to n-to-m
- Integrate and promote Session Management spec to draft
- Noise+DR+session management Chat2 PoC
- go/js implementation support

### Great to have at some point
- Add support to Blake2 hash
- Anonymous filter query (Private Information Retrieval, Oblivious transfer)
- Noise implementation/stack as external library

#### Notes on above

- Cut this down to be more realistic i.t.o. resources
- Be clear about why we do this: gather clear requirements from Waku Product, etc.
- Having an understanding on how to do this in other clients (esp. js-waku)

## RLN (S)
To be decided by Frank and Richard (a parallel effort)
* js/Go rln-relay implementation
* wallet integration in js/Go
* key-store in js/Go
* rln chat2 in js/Go

### July
* Dynamic rln-relay
* rln-chat2 testnet in nim local test by the Vac team (Sanaz)
* rln-relay performance
* gathred feedback, get performance insights (Sanaz)
* Write a post on the performance result of rln-relay (may spill to August) (Sanaz)
* Multi-chain rln-relay
- Raw rfc for the contract API with the fee option (Keshav)
- Support for ERC20 token as rln payment (Keshav)
- Cross-client testnet
* nim zero-kit integration under a compiler flag (Giuseppe)
* integration of zero-kit in Go (Giuseppe + Richard)

### August
* applied rln
* applied rln as a stand alone, with usecase in ethereum validators (Sanaz)
* rln-relay performance
* looking into Merkle tree optimization (research and dev) + protocol design and dev(Sanaz)
* Multi-chain rln-relay
- Contract Audit (Corey-Keshav)
- Wallet integration in nim (Keshav)
- key store in nim (Keshav)
* Cross-client testnet
* zero-kit testnet (Giuseppe)
* circuit audit (Giuseppe + Corey)

### September
* rln-relay performance
* Re-evluating storage/performance with the new merkle tree management design (Sanaz)
* cross-client testnet
* rln-relay trsuted setup (Sanaz + Giuseppe)
* rln-relay based connection management (Sanaz + Hanno)

### October
- cross-client testnet (Sanaz + Frank + Richard)
- a vac.dev post on introduction to rln-relay for larger audiance to run rln-chat2 (Sanaz)

#### Notes on the above:

- Make the milestones clearer: e.g. tie under "launch an RLN testnet in August", with the laundry list above as details
- Capture interrep and decentralized captcha somewhere in the rln-relat 6 months plan (for the record https://docs.google.com/document/d/1it9_HTzOTvumBsUoeY3SEVFTJA-sSYrW89-HsEjriEg/edit?skip_itp2_check=true&pli=1)