Some of the terminology changed with the Threshold merge. Currently need renaming:

• staker -> staking_provider
• decentralized_identity_evidence - undecided, operator_signature? See what ends up being merged with nucypher/nucypher#2850
• something else?

See note in #83 (comment)

Update nucypher-core dependency in nucypher (see nucypher/nucypher#2832 (comment))

• Should improve the ergonomics of the WASM bindings by allowing === and == comparison in JS.
• Consider implementing equals method in WASM bindings
• Related to: nucypher/ferveo#126

Initially the objects in nucypher-core were only intended to be serialized in binary because we were only concerned with protocol objects. Recently an issue was raised on Discord about deserializing the JSON response from Porter with fields like

      {
        "checksum_address": "314CaB1F5e6731f14F1deb4413d76b09D68710CA",
        "encrypting_key": "033c8e562e959b70714c96ec65cfd74f35d29526f8e8b38d148e8551b702dfb581"
      },

It would be convenient if these field could be deserialized by serde into Address and PublicKey. There are two problems here:

• Address's serde serialization for human-readable formats is the serde default, that is a list of integers. So it cannot be deserialized from the hex form above at all.
• While PublicKey would deserialize fine, it may be better to have a 0x prefix in front of the hex representation, to match the Ethereum RPC format (and the same applies to Address).

Naturally, fixing that should be done in a consistent manner. There are several interconnecting issues (which also affect umbral), so the scope of the changes needs to be determined.

Several bytearray-like objects in nucypher-core (Address, FleetStateChecksum, HRAC and the third-party recoverable::Signature) use the custom arrays_as_bytes serialization. certificate_der field of NodeMetadataPayload uses serde_bytes. These will have to be modified to support human-readable formats. One way to do it is to expose the machinery from serde.rs in umbral and use it in nucypher-core. The problem is that it deals with objects that are represented as arrays with size known at compile time, so that may have to be changed.

operator_signature and certificate_der fields of NodeMetadataPayload may need to be wrapped in types so that we could impl Serialize/Deserialize for them. This way the Option<recoverable::Signature> that we need will be handled automatically, too. Now we need a special function in arrays_as_bytes.rs to handle it.

Should we care about human-readable serialization of protocol objects? How will versioning work in this case?

This should possibly defined in https://github.com/nucypher/rust-umbral just like capsule and we will wrap it here

• Implement an alternative "slim" export in the nucypher-core package for WASM-aware bundlers
• Provides nucypher-core users with a lightweight (~33% smaller) alternative for "fat" export which contains base64-encoded inlined WASM
• Consider merging the nucypher-core-wasm and nucypher-core-wasm-bundler directories on the back of this change
• Refers to #83

Conditions aren't really optional, why do we use Option<&Conditions> as parameters for various dkg protocol objects? Shouldn't it accept Conditions instead? No Condition is not an option for dkg (it was optional for PRE adapted tDec), we actually always want conditions.

cc @piotr-roslaniec , @KPrasch .

• Expose as a language-specific type in bindings
• Handle serialization & validation internally
• Update downstream dependencies
• Refers to nucypher/ferveo#116

Update nucypher-core to account for changes in nucypher/ferveo#132

• Bump protocol versions for those objects
• Enrico signs conditions data and includes signature in the MessageKit?

Currently it is kept as a bytestring, so an invalid NodeMetadataPayload can be created if the signature format is wrong, which will later lead to an error when calling derive_operator_address(). Instead, it would be better to fail early by checking that the signature is valid on NodeMetadataPayload creation.

Presently all ferveo-generated objects are handled as bytes. Instead, ferveo types can be implemented directly in dks.rs as well as the python/wasm bindings. This implies that ferveo provides a crate exporting it's python and wasm bindings for consumption in nucypher-core (nucypher/ferveo#87).

targets

• ThresholdDecryptionRequest.ciphertext -> ferveo.api.Ciphertext
• ThresholdDecryptionResponse.decryption_share-> ferveo.tpke.api.DecryptionShareSimple||DecryptionSharePrecomputed
• NodeMetadataPayload.ferveo_public_key -> ferveo.common.keypair.PublicKey

Suggestion from @piotr-roslaniec (#54 (comment)) :

   // Elsewhere
   fn map_py_value_err<T: fmt::Display>(err: T) -> PyErr {
     PyValueError::new_err(format!("{err}"))
   }

    <potential error returning call>.map_err(map_py_value_err)?;

• Downstream changes from nucypher/rust-umbral#126

Requirements

Implement two new serde-versioned bytes-serializable entities for use in nucypher/nucypher and nucypher/nucypher-ts threshold decryption product (working title "tCBD"). Bob will use these entities to gather threshold decryption shares. Both python and WASM binding are needed.

Entities

• ThresholdDecryptionRequest (ThRq)
  • ritual ID: int
  • ciphertext: ferveo.Ciphertext
  • conditions: Conditions
  • context: Context
• ThresholdDecryptionResponse (ThRs)
  • share: ferveo.DecryptionShare

Notes

• Implementation is very similar to ReencryptionRequest/ReencryptionResponse
• see development mockup here: https://github.com/nucypher/nucypher/blob/385e982e1c0bd830894b63f5a809881d6b412ab4/nucypher/utilities/mock.py
• see usage in nucypher/nucypher's Ursula here: https://github.com/nucypher/nucypher/blob/385e982e1c0bd830894b63f5a809881d6b412ab4/nucypher/network/server.py#L143
• consider encrypting ThresholdDecryptionResponse for Bob.
• will require a version bump

Nickname derivation in nucypher (from staker addresses/fleet state checksums, see https://github.com/nucypher/nucypher/blob/main/nucypher/acumen/nicknames.py) is non-trivial to reproduce in other languages (although possible). Should we move it into this crate? In case nucypher-ts wants to use it.

• Introduce wasm_bindgen(module = "ferveo/nucypher") in order to avoid naming conflicts between umbral.Ciphertext & ferveo.Ciphertext etc., in WASM bindings
• Instead of relaying on prefixes (FerveoPublicKey, UmbralPublicKey, etc.) make sure that the naming conflicts are avoided by exposing types from their respective modules (ferveo.PublicKey, umbral.PublicKey).

• Downstream changes from nucypher/ferveo#139