WNFS Protocol Negotiation

[laudiacay]

Opening this thread to discuss things like "what happens when one user of WNFS wants to keep using XChaCha, and another user of WNFS wants to be FIPS-compliant" or "one wants high security (RSA accumulators) and the other wants speed (Nyberg accumulators)".

I propose something along the lines of standardization of TLS-style cryptographic + serialization protocols as needed, and an addition alongside the "Version number" of a "protocol specification".

This springs from a discussion @expede and I had in Discord DMs.

Work to do: Figuring out what parts are hot-swappable, what parts should stay consistent, and how to express this data/any other concerns it may bring up.

Banyan will return to this discussion to help with it eventually but probably not for a second... For now, here's a nice thread to post ideas and thoughts.

CC @sstelfox

[expede]

• Related, but not identical: Layer Swapping WNFS #358

[expede]

also cc @matheus23

[expede]

There's a two side discussion to be had:

1. Is the absolute performance of RSA accumulators acceptable?
2. Should forks be compatible
3. Should rs-wnfs be broken into more granular crates to make recomposition possible vs forking the entire project
4. How and what (and if) to signal in "fork headers" beyond version number

[matheus23]

I propose something along the lines of standardization of TLS-style cryptographic + serialization protocols

Would love more resources on that!

I personally envision something like MLS ciphersuites.

[matheus23]

"one wants high security (RSA accumulators) and the other wants speed (Nyberg accumulators)"

I've thought about this a bunch.
We're almost there making this swappable from a code perspective.
We already have the PrivateForest trait in rs-wnfs. What is missing is:

• An associated type on the trait type Name, and using Self::Name instead of NameAccumulator in the PrivateForest functions.
• Parameterize all structs in rs-wnfs, e.g. PrivateNodeHeader<F: PrivateForest>, so that it can refer to name: F::Name instead of name: NameAccumulator.
• Add some abstractions over how path segments are "accumulated" to the PrivateForest trait and make use of them instead of NameAccumulator::add and such functions in rs-wnfs code.

I'd actually say the trade-off is slightly different. I'd actually compare name accumulators with a simple hash chain over all private node inumbers:

• Name accumulators: Use when there exist store-and-forward hubs (without read access) in your network architecture with lots of readers and lots of writers with very low "trust" (i.e. some notion of 'have access to sub-paths, but could be malicious'). Then name accumulators force nodes to verify their access to stuff before submitting it to the hub (even though the hub can't read).
• Hash chains: Use when you don't have many readers, have high trust in every writer.

[expede]

There's also a question about if it's useful to signal that at the top and have a giant switch statement (top-down) or break out crates and let peeple swap in/out implementations based on Traits (bottom-up).

It may be my FP brain, but I personally don't think that a kitchen-sink is helpful because it creates a choke point. I'm also dubious that different stacks will want to interoperate, but in the bottom-up mechanism, you totally could do that.

(Also as a total aside, I wonder if an Autocodec and/or Cambria type thing would be helpful for interop here versus the giant switch)