# iroh x willow

_25 June 2024_

**Attendees**

- frando
- dignifiedquire
- gwil
- aljoscha
- glyph

## Notes

- Would iroh like to use willow-rs?
- frando: "Yes, I think we would"
- Things look compatible
- Type aliases for generics
- dig: Be aware that compile times might explode due to heavy use of generics
- Shouldn't be too bad if there is only one instantiation / implementation
- gwil: Suggest iroh makes a gradual move to willow-rs
- I.e. start with `Path` only
- frando: Not sure about store and WGPS yet
- iroh want to use a simple embedded database: [redb](https://www.redb.org/)
- Most of the iroh implementation is single-threaded, even though it's on the tokio runtime
- Uses `Rc`
- Fine to block; waiting on I/O
- frando has done some initial profiling
- 80% of CPU time is used on encryption
- Maybe have a threadpool for sessions
- Satisfied with current sync protocol in iroh
- frando: Would be worried about a fully generic version but this may not be warranted
- Using four separate stores right now
- Entry
- Secret
- Capability
- Payload (iroh blob store)
- Might do a data model trial run soon (using willow-rs)
- Two missing pieces needed for iroh-willow:
1) Private Area Intersection
2) Store (`redb`)
- frando: Not sure if he should do a concrete implementation first
- Using tokio for networking
- tokio tasks for QUIC
- Each logical channel gets its own QUIC stream
- Loop over streams
- Boundary between this and store is a shared buffer (channel struct): in-memory pipe
- Can be used sync or async
- Message gets encoded (bytes) into the channel and is then written to the network
- One stream per logical channel
- Doesn't need to enforce message boundaries
- Could be interesting to compare this to ufotofu
- tokio-utils: most of frando's implementation copy-pasted from here
- frando: Will write a doc about the iroh-willow QUIC implementation
- Interested in two things which are not handled in Willow
1) Limit PAI to a set of namespaces communicated in the clear
- Preannounce namespaces (optional)
- Before or after commitment
- Betty can limit namespaces for PAI on their end based on announcement by Alfie
- Could be part of WGPS but can also be separate
2) HyParView peer sampling
- Pre-will iroh docs
- iroh-gossip
- HyParView + Plumtree
- Punt on swarm mode for now
- Initial version of iroh-willow will only have one-to-one sync
- Leave peer sampling to application layer
- May want to embed this into iroh-willow ast a later time
- Distributed PAI (research topic)
- "Live mode: receive new entry, gets forwarded to peers if it falls into a shared area
- aljoscha: We also want to do this
- Store trait
- Single-threaded event loop (async)
- iroh
- Paths need to be `Send`
- Network layer is multi-threaded
- Likely would need to define a supertrait of `Path` with `Send`
- aljoscha: We could eventually move this into willow-rs
- Return type notation: may help solve this
- Language-level solution which is under development
- Might need two version of each trait
- Single-threaded
- Multi-threaded (`Send`)
- Some concerns about current willow-rs implementation of `Path`
- dig has a single slice version sketched out
- aljoscha likes it
- Very cheap to take prefixes
- Zero-copy networking
- WGPS is anti-zero-copy networking by design
- May be single-copy
- frando's implementation should mostly be single-copy at the moment
- Get zero-copy `Entry` from redb
- Encryption performance
- Two improvements:
- Buffer a few incoming messages; use something like [rayon](https://crates.io/crates/rayon) threadpool to verify signatures
- Could maybe use batch verification instead ([curve25519-dalek](https://crates.io/crates/curve25519-dalek))
- Hashing is fast enough
- Signature verification is handled outside of store in iroh-willow
- `PossiblyAuthorisedEntry`
- Need a full entry for verification
- Requires an allocation
- Could use a shared buffer instead
- Can't verify a network message
- frando: Open to discussing WGPS early-on
- Where does session state live?
- Right now: `Rc<RefCell<_>>`
- Will do a round of clean-up soon