Make DAF a special case of VDAF and move it to sections after VDAF
Closed this issue · 3 comments
This had been discussed in: #20. I think it was right to name DAF explicitly and keep it in this document. However, since DAF is at the beginning of this doc, a lot of the key components of VDAF is introduced from DAF, the reader would have to refer to DAF section for the common part and figure out what's the difference. Given that DAF is not recommended and not the main focus of this document, shall we move it to somewhere after VDAF. So section 4 can be definition of VDAFs, right after Overview.
DAF can be explained as a VDAF without a verification system, maybe it makes sense to mention it after Poplar1? We can try to keep the same interface between DAF and VDAF, but specify parameters like nonce and verify_key are not used (I imagine this would be how it will be implemented), or still keep the separate interface.
This is actually intended. Currently the text is structured such that DAF is a "warm-up" for VDAF:
- Define DAF
- Describe its intended functionality/privacy goals
- Say that it's not robust
- Define VDAF as an interactive version of DAF that gets robustness.
That said I can see the merits in making the VDAF section self-contained. I think we could make the text equally clear by introducing VDAF first, but it would require a bit of work.
Do you have a suggestion for how to make make the Daf API a special case of Vdaf?
TODOs from call 2023/7/11:
- Add nonce to API (we need this for IDPF anyway)
- Consider moving DAF after VDAF.