Meadowcap #32
Meadowcap #32
Conversation
meadowcap/src/lib.rs
Outdated
| access_mode: AccessMode, | ||
| namespace_key: NamespacePublicKey, | ||
| user_key: UserPublicKey, | ||
| delegations: Vec<Delegation<MCL, MCC, MPL, UserPublicKey, UserSignature>>, |
There was a problem hiding this comment.
This will work for now, but long-term (or even medium-term), we want something that is much cheaper to clone (i.e., something that involves reference counting). We will have many entries with only a few different capabilities, so they should (at least be able to) reuse the same memory. Might even involve interning. CC @Frando, this could be fairly involved. One option would be to require the parameters of the types in a Delegation to be FromBytes, so that we can store things in a Bytes struct.
There was a problem hiding this comment.
I've always wanted an intern.
But more seriously... let's follow this up in the willow channel on discord.
There was a problem hiding this comment.
Do you mean wrapping the delegations, or the full capability?
In iroh-willow I switched to internally wrapping the full delegation in an Arc. My reasoning was that cloning capabilities is much more frequent than modifying them. With the capability-as-arc, I can just clone them freely whenever and wherever I need them, which is nice.
There was a problem hiding this comment.
I don't have any specific, thought-through ideas. But the same style as the Path struct (encoded data inside a Bytes) comes to mind.
Agreed that cloning is much more important than mutation. Reading a bunch of entries with the same authentication token from the WGPS can reuse refcounted memory when the network encoding specifies the authentication token as one that had been transmitted before. But it might be nice to do interning to also reuse tokens when the network encoding does not explicitly state that it's reusable. Additionally, when reading entries from persistent storage, it would be good to deduplicate memory as well.
Co-authored-by: Aljoscha Meyer <[email protected]>
Co-authored-by: Aljoscha Meyer <[email protected]>
|
@AljoschaMeyer the fuzz tests are currently running with complaint, but:
I would appreciate if you could inspect the fuzz tests as they are for oversights on my part! |
|
To make the silly signature scheme even more silly, how about defining the signature as a single byte which is the XOR of the public key and the first message byte? That way, there are only 255 different signatures, and the fuzzer should hopefully guess them quickly enough. |
|
Super cool =)! |
Implementation of Meadowcap.
signaturecrate.What's done:
Extra fancy data structures(we will handle this later)