sicpa-dlab / didcomm-rust Goto Github PK
View Code? Open in Web Editor NEWLicense: Apache License 2.0
License: Apache License 2.0
I'm not too familiar with how the DIDPeer DIDs are supposed to work, but according to this comment, it appears that there may be some issues with Peer DID Numalgo 2 generation across libraries between https://github.com/sicpa-dlab/didcomm-python/ and here. The output is different enough that it has caused a conversion layer to be built to convert the DID between libraries in order to maintain inter-operability. Daniel has submitted a PR to the Spec to make clarifications decentralized-identity/peer-did-method-spec#62 but as of this moment it has not been merged.
Irregardless of the merge status, did:peer:2 DIDs generated by didcomm-rust
and didcomm-python
are incompatible with each-other when a service endpoint is defined. didcomm-python
is expecting a flat servicesEndpoint structure, where-as didcomm-rust
is expecting an object.
cc: @dbluhm
Hi Guys,
I'm trying to run uniffi wrapper for swift as by this guide (https://github.com/sicpa-dlab/didcomm-rust/blob/main/uniffi/README.md).
But I catched an error in "3. Generate Swift binding:" point when I run command: uniffi-bindgen generate src/didcomm.udl --language swift -o ../wrappers/swift/didcomm
Error body:
Error: Failed to parse UDL
Caused by:
ExtendedAttributeNoArgs not supported: "Wrapped"
Could you please advice on what could be the problem?
P.S.: I'm trying to use swift code from wrappers but unfortunately README.md file is empty. Could you share some more details on how I can work with the given module?
Thank you in advance,
Yurii
didcomm-rust/wasm demo is failing in step https://github.com/sicpa-dlab/didcomm-rust/tree/main/wasm#run-demo - more specifically, during the npm run start
command...
C:\web7sandbox\repos\didcomm-rust\wasm\demo>npm ll
[email protected]
| C:\web7sandbox\repos\didcomm-rust\wasm\demo
| JS demo for didcomm
+-- @types/[email protected]
| TypeScript definitions for Node.js
+-- [email protected]
| WASM based javascript wrapper for DIDComm
+-- [email protected]
| TypeScript execution environment and REPL for node.js, with source map support
+-- [email protected]
| An extensible static analysis linter for the TypeScript language
`-- [email protected]
TypeScript is a language for application scale JavaScript development
What are the chances that a .NET binding/wrapper can/will be created for these rust libraries?
Michael Herman
Web 7.0
- User stories are good: As a [user] I want [to be able to do X] so that [I can achieve Y]
- Team actions are also good: As a team we [should explore X] so that [we can do Y]
Explain why you think this issue needs to be addressed and why it should be addressed in this repo.
- What evidence do you have that it will be a requirement for this project?
- What evidence do you have that it meets the needs of the users of this project?
- Have you checked that a similar issue or resolution doesn't already exist?
If so link to it and explain any shortcomings
Explain what actions or decisions need to be completed to close this issue.
- Using a task list here can be helpful to track progress.
Include links to any examples, research or code that support this issue.
Before submitting:
- Add appropriate labels for 'type:' and 'related to:'
- Add an assignee if you want to direct this issue at a particular individual
When I try to use a did document that has a service block without routingKeys
it blows up complaining it doesn't find the routing keys. These should be optional as seen here
Have friendly errors when a method can receive all types, DO NOT crash with a SIGBUS error.
Sending inn a JSON obj into unpack, which is allowed by the types, crashes silently with a SIGBUS error. Trying to debug this was not that easy: nodejs/help#3168
But the library should throw a friendly error if JSON objects are not possible to send in for unpack.
Only string works at the moment
This needs to be fixed for a better DX, as SIGBUS is not caught by try catch, and it can fail silently depending on how one run its code. This is a very bad DX.
Fail if one send in something the unpack method dont expect. Fail with a proper error so the developer can understand.
Or if JSON objects are OK, which they should be, dont crash unexpectadly.
As a user I would like to be able to know why resolution of did document failed, e.g. network error or simply not found. The API is available such as
public protocol DidResolver: AnyObject {
func resolve(did: String, cb: OnDidResolverResult) -> ErrorCode
}
but when trying to invoke
try cb.error(err: .InvalidState(message: did), msg: "NetworkError")
then nor ErrorKind
or msg
is propagated to pack or unpack methods on error closure.
public func unpack(msg: String, options: UnpackOptions, cb: OnUnpackResult) -> ErrorCode
public protocol OnUnpackResult: AnyObject {
func success(result: Message, metadata: UnpackMetadata)
func error(err: ErrorKind, msg: String)
}
In the above err is always
(lldb) po error
▿ ErrorKind
▿ InvalidState : 1 element
- message : "Invalid state"
and msg is always
(lldb) po msg
"Invalid state: Unable resolve signer did: can not resolve DID Doc: Invalid state: unable receive callback result: oneshot canceled: unable receive callback result: oneshot canceled"
What I would expect is ErrorKind is correctly propagated.
I was just installing the didcomm npm package and ran into some errors
I could not find any documentation on the nodejs api so I wanted to install it to discover the api.
install didcomm node package via pnpm
and import it successfully.
When importing like this:
import * as didcomm from 'didcomm'
I got this error:
(node:64180) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
(Use `node --trace-warnings ...` to show where the warning was created)
/Users/username/Work/jlinc/didcomm-npm-install/node_modules/.pnpm/[email protected]/node_modules/didcomm/index.js:1
import * as wasm from "./index_bg.wasm";
^^^^^^
SyntaxError: Cannot use import statement outside a module
at internalCompileFunction (node:internal/vm:73:18)
at wrapSafe (node:internal/modules/cjs/loader:1166:20)
at Module._compile (node:internal/modules/cjs/loader:1210:27)
at Module._extensions..js (node:internal/modules/cjs/loader:1300:10)
at Module.load (node:internal/modules/cjs/loader:1103:32)
at Module._load (node:internal/modules/cjs/loader:942:12)
at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:168:29)
at ModuleJob.run (node:internal/modules/esm/module_job:193:25)
I added these two lines to node_modules/didcomm/package.json
{
"type": "module",
"main": "index.js"
}
and it fixed the import problem.
Node v19.5.0
pnpm 7.29.0
Macbook Pro Ventura 13.2.1
Give a brief description of the objective of this issue. What needs to be discussed?
Test vectors are not really testing different things. The test vectors currently only thinks about JWK methods. But your documentation have lots of different types.
I believe this lib should expand its test vectors to showcase more diversity of crypto
Explain why you think this issue needs to be addressed and why it should be addressed in this repo.
Because it helps other people use this library more efficient as well and not hitting their heads against something that is supported but not documented
Explain what actions or decisions need to be completed to close this issue.
- Using a task list here can be helpful to track progress.
Easy for newbies to start and see how they can do things with tests, to cater for their environment
The library appears to have issues with my multibase encoded private key (Ed25519VerificationKey2020
) as it throws an "Unsupported prefix" from (here)[https://github.com/sicpa-dlab/didcomm-rust/blob/53dcbbcfec906c15ccf3ee94b275dbb61d026ff4/src/utils/did.rs#L453]. I have checked and the prefix isn't what it expects there.. I have tried with some of the test keys used in this library so I'm not sure why this is happening.. I also haven't seen anything about those prefixes anywhere so I'm not sure where they are from.
I am unable to sign a message with my multibase encoded authentication key
I am able to sign a message with my multibase encoded authentication key
I am trying to build uniffy project from tag 0.4.1,
but running the build command gives the following error output.
➜ uniffi cargo build --release
Updating crates.io index
Updating git repository `https://github.com/hyperledger/aries-askar`
Compiling proc-macro2 v1.0.69
Compiling unicode-ident v1.0.12
Compiling version_check v0.9.4
Compiling typenum v1.17.0
Compiling memchr v2.3.4
Compiling serde v1.0.189
Compiling subtle v2.4.1
Compiling cfg-if v1.0.0
Compiling libc v0.2.149
Compiling syn v1.0.109
Compiling thiserror v1.0.50
Compiling radium v0.5.3
Compiling lexical-core v0.7.6
Compiling generic-array v0.14.7
Compiling nom v6.2.2
Compiling ryu v1.0.15
Compiling bitflags v1.3.2
Compiling serde_json v1.0.107
Compiling quote v1.0.33
Compiling getrandom v0.2.10
Compiling syn v2.0.38
Compiling nom v5.1.3
Compiling tap v1.0.1
Compiling wyz v0.2.0
Compiling rand_core v0.6.4
Compiling arrayvec v0.5.2
Compiling funty v1.1.0
Compiling camino v1.1.6
Compiling static_assertions v1.1.0
Compiling anyhow v1.0.75
Compiling opaque-debug v0.3.0
Compiling askama_escape v0.10.3
Compiling bitvec v0.19.6
Compiling paste v1.0.14
Compiling ucd-trie v0.1.6
Compiling byteorder v1.5.0
Compiling digest v0.9.0
Compiling cipher v0.2.5
Compiling universal-hash v0.4.1
Compiling signature v1.3.2
Compiling crypto-mac v0.11.1
Compiling ff v0.10.1
Compiling itoa v1.0.9
Compiling rand_core v0.5.1
Compiling unicode-width v0.1.11
Compiling textwrap v0.11.0
Compiling group v0.10.0
Compiling hmac v0.11.0
Compiling aead v0.3.2
Compiling block-buffer v0.9.0
Compiling cpufeatures v0.2.10
Compiling futures-core v0.3.28
Compiling unicode-segmentation v1.10.1
Compiling autocfg v1.1.0
Compiling slab v0.4.9
Compiling heck v0.3.3
Compiling weedle v0.12.0
Compiling sha2 v0.9.9
Compiling clap v2.34.0
Compiling poly1305 v0.6.2
Compiling futures-task v0.3.28
Compiling fnv v1.0.7
Compiling der v0.4.5
Compiling ident_case v1.0.1
Compiling serde_derive v1.0.189
Compiling thiserror-impl v1.0.50
Compiling zeroize_derive v1.4.2
Compiling futures-channel v0.3.28
Compiling darling_core v0.12.4
Compiling zeroize v1.4.3
Compiling aes-soft v0.6.4
Compiling crypto-bigint v0.2.11
Compiling pest v2.7.4
Compiling curve25519-dalek v3.2.0
Compiling chacha20 v0.6.0
Compiling elliptic-curve v0.10.6
Compiling salsa20 v0.7.2
error[E0433]: failed to resolve: could not find `memmem` in `memchr`
--> /Users/i******/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pest-2.7.4/src/position.rs:311:33
|
311 | memchr::memmem::find(&self.input.as_bytes()[self.pos..], s1.as_bytes())
| ^^^^^^ could not find `memmem` in `memchr`
Compiling ecdsa v0.12.4
Compiling polyval v0.4.5
For more information about this error, try `rustc --explain E0433`.
error: could not compile `pest` (lib) due to previous error
warning: build failed, waiting for other jobs to finish...
error: could not compile `pest` (lib) due to previous error
```
Give a brief description of the objective of this issue. What needs to be discussed?
- User stories are good: As a [user] I want [to be able to do X] so that [I can achieve Y]
- Team actions are also good: As a team we [should explore X] so that [we can do Y]
According to DID Comm V2 specs the body
on the Plaintext Message MUST be a JSON object.
In most examples on this list, the JSON string is used instead ("example-body"
)
Explain why you think this issue needs to be addressed and why it should be addressed in this repo.
- What evidence do you have that it will be a requirement for this project?
- What evidence do you have that it meets the needs of the users of this project?
- Have you checked that a similar issue or resolution doesn't already exist?
If so link to it and explain any shortcomings
Just to follow the specs
Explain what actions or decisions need to be completed to close this issue.
- Using a task list here can be helpful to track progress.
The Plaintext Message MUST have a JSON object in the body
in DID Comm v2.0.
In DID Comm v2.1 this body
is optional but also needs to be a JSON object if present.
Include links to any examples, research or code that support this issue.
Before submitting:
- Add appropriate labels for 'type:' and 'related to:'
- Add an assignee if you want to direct this issue at a particular individual
While using version 0.4.1 in Uniffi Swift, whenever I try to send a message with extra headers I get the following error:
UniffiInternalError.rustPanic("Failed to convert arg \'msg\': Malformed: Invalid json value: expected value at line 1 column 1")
Because this makes extra headers unusable in Uniffi swift, and also makes protocols like the (Pickup protocol) [https://didcomm.org/pickup/3.0/] unusable.
Successfully pack a message with extra headers.
(Return Route)[https://github.com/decentralized-identity/didcomm-messaging/blob/main/extensions/return_route/main.md]
(Pickup protocol)[https://didcomm.org/pickup/3.0/]
When I receive a message that is encrypted, and run it through unpack with the right secrets and resolvers. I expect that I get an object I can work with that is decrypted and possible to read the datat itself.
But the object that is provided is an object with a ciphertext. Since I was not the one encrypting the initial ciphertext, I expect that the library will provide me with a way to get the clear text message out.
Here is an example of the unpacked.as_value()
message
{
"id": "36f2a86e-5b25-4baf-9f7f-40d978590316",
"typ": "application/didcomm-plain+json",
"type": "https://didcomm.org/routing/2.0/forward",
"body": {
"next": "did:peer:2.Vz6MkhMTSwCfytUNmrEQ4We5i6B2ywM8hAcHvRDD293QGrqSS.Ez6LSm3LPosAtT2qUtFNU9Y2y9P9wQUfJjGgs98uchVJtZjfS.SeyJpZCI6IiNkaWRjb21tIiwidCI6ImRtIiwicyI6Imh0dHBzOi8vZGV2LW9wZW4tbWVzc2FnZXMtYXBpLWx0aDRnb3dkeXEtZXcuYS5ydW4uYXBwL21lc3NhZ2VzIiwiYSI6WyJkaWRjb21tL3YyIl19"
},
"attachments": [
{
"data": {
"json": {
"ciphertext": "EvyxDoHnIYCc0iFhenovIaiJfnIDWlE1brmoqLlNaVoHJ6oGuSWp_UaiqT2yGCZiKKP4E0mptTM14TD9dYpiAKajcjhIKFIeDCMyyaKdusdd6V6C7On98D9uEW9vqW6VDn-EygIv1ZTQInJ3P0ec_my-x1L2G6CReM7p5uDyfI0xIYzr_Lv8cTNRJIna5HOXEPq04fSf-BQZDX3DiL-wcdO-HCy4qL_udevp9hUla7Xam1xhnU_7pttu7ygHnSrtjJMyzNymNSsb1mNgz3qio-_d_MW2xyhoMtQzig7TVnB9CIYpvMRg-HSwMLwkxGDHxwBZIH_EaYxOcmZIA6QoJ6gljRIyVB_4AbAiJuzMEZpRbcdtg0kgpY632Rs8jloHkf_RS3AY3ZaatOl6x1JbI9JgFpprow2L5rwnvMOxU3i3sV_jwKtEccxcS2oVxYOFBIAei2kw6Bk3Oz-sCmCwYMdy23F95WYo_1Ma16-i-I3JQpkHUvlmwnDOOc-0Qz245SxohM9Fqg1bmBpEMvSoYi93gnBexthUV89K7KJT_ja1ed_ZZsoChMS3U3E1nfge9SY6uRs4JRKdDT0kfzu3Wb-fXQJtdNcnvqN_fT29a59SiQv9vm8J2iw6pVw3E_9msEHCFeEc-d1A01J-yllqHU8pjljrK11dHDSqyUfHCEsd0vsZuxJjN3Q042SwfSduGL8puxz3hNed8d2PnkLr-6i0LLrvYU5mnddlsZt-xqq22RLxN08NauBdyOSzykTRUUx8ClqyzuAwVY9RjOybagIiJpnlEbieYXbSP2ruu0F6sytArC0ZSEMl5jLNAGq0I9FjrcS7Mqv_E76s2qOSEUPcHnw8hHd7gcryjEgjxntUtAB53JhgEJNkQifFABXg01mu8k-rPIpVtGIOhqG_rEIePbKALk25aX4uMoGHHcsAAGfwgDGM_LsHl35zpGtjDB3yON3toB2UpMShKYdJH9FBijA-BhUEEutJjqxxMcbouGTcD9gl7PxYCdEq4oPAo74kND4WquixiRyKjiOsSEADNbzyISl40USMXNskUfokZHIDwqu224SjjH7lcu6nz0vz85ku1cuOMXNVv4GHbX8-P9dii65Iwn7F_QVb_-i50BTVpYvDUt1F4AUbvbu0mIypyTyX4Emp5XaLFtRvukilAEn6EhfT4oZPveKon3DnnimerdDm-ebarvO04LjnAF5NBNomocCb4-Ep-6uWdljxJDrVYNFo-GqWvUYRhlbVg3aTwOGs0v_6Mah4iKhLA7i4UOb6doF5D6DLnjr3Fz7_XOcqebmPb7ExeOdcBvMWRuDHKfmPLlcp__rDOCLZ2KXvI6HBnWZ3NVbMTYn512PsXGaJ0N64UVCiW6piiTPKBdpfPEPgnOM70xVdfMpax9ZtihXvxPjxZ1dOVYhIsIv9_b0kpcUtbV13bReKks_1mVp1LOyHN75DyUvsq0CRgT6-NNnYod0tLFsd8uYaXtGF44qvwj6WlGDW8g1lcB6UroSAcSnfoCu5LWDKOdiWfnR2QZD0mrNv0YAGr63BFo7hUFX2f3a9XX60aDL0IumkcJ5FLCYMjkRUkL7AglNw707SdAKmE1mnEz2TfnYpvEY9NzYgpoOL_sXissf-HS41JYppcuCusdomUiUMrQXPSbXOZ2HNRJrvrP0DGix56bmsL315njkFZ3SxUcczaCbPUzT8YBD475GWnaPDwDiVUUf7NnK7flNVshviMZK_8JMOH0EvDnzIm_hfeTTO3SxQxshFb7XqmYVolXs73HdaWXG44jrK__F6SSzr3h-ZzChBEaz8cnC037Jr2P0PoOPExaZIkJgTXRMtDGT0hrm6X8__xQZtWRVeeG14p4c3hIaBSbiofOjZdLgfBKw4Vz2etH3QNC8DupqGDQ2HoGivbsPvpgF2CpDSdlq1oOJMW3NFvUxizVN6mju8edXKCoj8RCmEhzpvBAqB1_Ir6gPPr7p_z3r1_QN0GNW9rKqSiBfFBmc2y3fuWxYrsL-vrJDwfTOGv9cEwboOeUArG501iObfaKKEZBtZzJIj-WLBGgsSsjrbkvqUDnb763y07ym7pZhKQaYmx2INKwPu0sdBPJYpE8ChuQGbpK9iclhx7bXpejvbRltyxHPdWAJlLFgbb4xvcxM6igseZ1wNqxo_DaNjyxTcVsIVa8BkKVj6jnHsMciqkbbQ78uLQBaUTVwWak6blr4oFbH79fWOPzN4qxp9AakhQRJR3EJfovw1R6lO9WOa38wKljvVkd_Zah_0RPRNZpuKrxylEFgAVUKh3JdUwD6zREvLw39ahj3b7LbajYdvFgLeMuRhkkLrY89LS54JHrovpgNvb_NBWGT8F2MNzRF7Ty-UJFeyfHdKRl0O9gOog189Ogqg_VuWesWftomkaj-YHqsYw4SeS7SBSg4zu6C7P-CirM0LPMvGK6AaGfmsL2Q7Vrsph56UD2FvRi8VAPbTivbcN3rJeotZ57S3sETFEXp_o9SwvlNRgpxHyJvadlad9KVAVhBihir-elrsfZTLomwsX55Ruj5GjGZsAr6sLmVLI9zxqgA9b_fxSiBg08IjVE4wn7_0KtFA8eafqDeXJREFQTooD6-GucrNeXN6yzZamJiyyBWx_tui2W6UCs554VW8Z3n2JtJNZDAazEQlB8JhfyUeYIbOsYWfOfx0hHMxYbaD30lp_q4r9KBYqYviX6ign8Bk9mllqeXV4Af30TSzcj5mFuumdL8ZedErMvyKBlU36p6NyyZs2c5phtTNLbPy-WgdblyvdDBFaxT5BLyJjZxzFVy5TlRLgOV7mBBxVY9ScP2z638J4hFqA6_-EuPBjPw4jOLOAmzHly85hyIC0zA8pSwrPaFqg3GYAoph-A25RjPTPtykbUrC2OgXM9GtJAQTrT4RTvYPLKSo3nINwoAp8845e0BbNUfp6-odCQaHVtm35rFezOBdqe0tsZlrCnA6m-fBs-3sOJObjhW-JrteHofmxQTDpxF5PZLYXTffBajbPeB_gbCsvd0VZ5KiXlCCLPyrE7VnTnbF023gzob8xGfYp1E4tv3OvVXRHaE_OCQxA4SsPDj5UVMzQ-4_PK5KziF79qHLot1uUbohSgbJLtie6Qj5hnjQWw-pnkVDVFIhHw3qmu8et4maFauZSEL2jNvwuzSoZAm8dsN6raQniypE_5SPnn0D1QlYBwNy3jeeVJ5G0oruAjPRriGIUGlsEeRPn1cEQfouCzxF5frw-w5SkCtpUFqiy9ZNKsjtGkQBDPq8P1iOlfoYGfTyfxYwJOsb3aQoqZoynITY0kDSY1b1HrxTpJY0YTpVLLBR_nvpsMjezEXeQVuCmJDBbRvy36x2D3JH-dIu0QHTGlIR1FuBJsaPb2qZLf7wEcPZ8ELO2yGpn27JooeNEsDM_vf8mIvd3D-W4CyKs77J32hH8Dx_il70E-mybyBLyO8sWRRnVioHTcs55STTTUpFPYHDQPlLpyetMx9Vz19Sl0ZoS1jXDxJq3yua3t19d0upPETpE7zTUnTsimdjaMXWDpDdALFObO_85zLXbpRcyM8705J3JPcHbez1IiPfwAk5Tcq-zS2Ejed5wXU23_xt36BPTJBsdKkXhQToN9SrxK7ac586y4Lzncj44SSFReUSw1pf7G3z67dudC6T84lL6vcYYbGLGgvKZHlvnZ2MHkPRoYFImYZ03GWYQ_xC9Fk2DRm4VqB3QqJBBslHyIne3xeGp3aq-_dzL3CepaCRXLcsFl1Qh1e_riaVf2zrkq3oXEUKAWErD1muairiR7jT-2MFesSciy4IFLlsBTj2hsPYhPmRR6SCyCt-E3-gWXTSUyRFgj2G2WtceT44DGz37aCT5_BOsPXlOBeolqTWCFgrKbwX1tFSa1nYrO-Xx8hu73XuczilXdN-c7Lb8WxTk7QvWE37tEM3O_y-IFurMob4xSo9AhXTvS2nQ9PmWiedq8jLjFr2SNjA6iPE7lTxx69uO4S-jwW_WAN7r56Z062EiwkOwjtex2ykW2SbpkmyY6tX5wlnMZenJo22a52jIrbMABVbRk_xfAgDXMhPtctX8dgobDM2G273LDdCet0Rzcs8QvEN0e1zfcRAGawF2_EZ5dDdd2rpVk3vep_NUOY03qONZcHFfMzl2O39D9QaEcdS7Xt-BUTuMJlZYAZG2K1tfSTlyvw89ceDnEqvxrI9PfhQM9uoZ5FrBY2x9aN0-U4O2YKr_nlL6wyGgbExmzFBmuRcRJvLnii6Maet-IEt4B5F5Say6biJvPWIXT3JJkbq39lQDMVCjWiXllSVv90tmOZoeQX4W59q5UYMqvZp3-l9KXgS6szd95e904GU1X3xFd6NNiU_Na83t1gMJ-c2x6UIp9CF2p77MjesybVelV5VLxYfk2C8gFEduJjH9WsF0bMfa-gYtdaRfycpNf_RL9l76jckm4p18qrbpm0d1pdhRqVhJmLxh5I-x4Do3QTv2QHt5M6v8849Y5h-V-wm_SK-4snPKL19ZaB-1Q_1flta8UVYfS_kCqrks1zdnbZf6KBz_rXnFe2NmNbIs2WY9JxmS9uvsSda5baOxUnI5yUXD4OuiphSg-sC4-UlWcFa8icJuf4cP9XwGlnIcBz4w-9Ecgiv4eyRpDyDTALkkAbuaiynwpKV44B0JtuyzaCi0zVFzm68-1mVFOHjEkfC2Vtp2DlpLdNW0pHof5_LlaUk--XdUM88XchSK-dcrck1kq1AE3HxMVcLNm9QKoga3f8EcgfQiD2B4230nutEcUP2dRXaC9rfTHC7cuzQmtMb1_ktLutM8f7U0bce4SJyenxYCaqduxhzwylJBo5e2kDWTJqK0NUUF47yYDD9ybroyWvfY_cjuUNbqMxVEerz5ZtSO9sqBE6TeHWPDsSJVjr73vQb5YEUWSba0u_irqBls_sgha7e3MP9NXp6SSO1xf9uNgct7CJVgNvYgQDZNdQgpDx-iTBDLeCkhapB3XNJFMpdzdrdJqxu6-oW8qpKrP6NlGuNSl7G3LwIfhFTV9auFOGRkDCzUC4RJ8e8Do-2DNJCBY_fbclxnLD3y2SZLI5bfH3yHQhN_Ayfn0uePVA2m-pbK6QafohqtdngFn63NrS19QIfw29py2LTP4iVEspzIfDhwJnSgIdk_jS9FbMbDvjLTrrPmvUf5If3cCTeHgH-lZmlruIqhhASgNpjLppHrjwg-1S0KxuoWJxSpdHvQ36G2_hFM8z5jrbow4h9X6QDq8wNV-cT6GS5zJGaQRO61nHOg-0XpRUHUYpxukIHritIjTIqiF_VgSq0X7COodZeM1h54rb37FS7i-v337r5slBUl9x8D7EXraGuu6xPuDG6fMmefYiMfNmwY07l8gR6fWdSLj_vTdPlxIMaAXYdjppaNVqPyYa2DvV4gu_Mk9rhzbB0rw3sx5a9SNOPEHvXinc-5U2RSMrivo8OM7FcM3jZw__gkgCsRgCqy8PXrkwg5wmPJU9vQRhf_VPvArRPfPjhTzJsu-9prZILnnMkvBQx8K-4yD8-Co9jCbhBXSTjyPDeGF59Yr_Qum5yxfBVcrF2nquTvi4FzRd_ehXbIeSAT3Ue9IzBt96xHl4giVTW_yrda_1efCAURDc",
"iv": "ppQiLheseVBGRfdsXVxnhQzQF1kavfZF",
"protected": "eyJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIiwiYWxnIjoiRUNESC1FUytBMjU2S1ciLCJlbmMiOiJYQzIwUCIsImFwdiI6IkJCLW9GVjBKemZoQWFFNjlQS3VaRmQ4dDhWZ19hQzhfTlpUNTM3NkxCOFEiLCJlcGsiOnsiY3J2IjoiWDI1NTE5Iiwia3R5IjoiT0tQIiwieCI6IkdmYUhrbHFUdWk3VUhSTXJIYms2Y0llNjFkbDhkd2tqQUZCcTI2aGMzUjgifX0",
"recipients": [
{
"encrypted_key": "QlQcNWkAUKbmOhDagbX5Vo9w1BzowrwfIrDtPxkpFXjtzwyq0tYiGA",
"header": {
"kid": "did:peer:2.Vz6MkhMTSwCfytUNmrEQ4We5i6B2ywM8hAcHvRDD293QGrqSS.Ez6LSm3LPosAtT2qUtFNU9Y2y9P9wQUfJjGgs98uchVJtZjfS.SeyJpZCI6IiNkaWRjb21tIiwidCI6ImRtIiwicyI6Imh0dHBzOi8vZGV2LW9wZW4tbWVzc2FnZXMtYXBpLWx0aDRnb3dkeXEtZXcuYS5ydW4uYXBwL21lc3NhZ2VzIiwiYSI6WyJkaWRjb21tL3YyIl19#6LSm3LPo"
}
}
],
"tag": "Ba3PnsIur7cgeLxSSH_CNw"
}
}
}
]
}
Because its not usable to actually consume the message itself that was sent.
The message below was the original message going through the encrypt message
function.
And I want to see that after I unpack with the right secrets.
What am i missing?
{
"id": "1234567890",
"typ": "application/didcomm-plain+json",
"type": "http://example.com/protocols/lets_do_lunch/1.0/proposal",
"body": {
"messagespecificattribute": "and its value"
},
"from": "did:peer:2.Vz6MkkkhBpeffjdyRCpyv1h17ZH4fJ6amEu2cujuaBcf2bmor.Ez6LScPkBqUGgUnFdxEPviCBAhdeKrhrHidLCyrcjq6SdvSj6.SeyJpZCI6IiNkaWRjb21tIiwidCI6ImRtIiwicyI6Imh0dHBzOi8vZGV2LW9wZW4tbWVzc2FnZXMtYXBpLWx0aDRnb3dkeXEtZXcuYS5ydW4uYXBwL21lc3NhZ2VzIiwiYSI6WyJkaWRjb21tL3YyIl19",
"to": [
"did:peer:2.Vz6MkhMTSwCfytUNmrEQ4We5i6B2ywM8hAcHvRDD293QGrqSS.Ez6LSm3LPosAtT2qUtFNU9Y2y9P9wQUfJjGgs98uchVJtZjfS.SeyJpZCI6IiNkaWRjb21tIiwidCI6ImRtIiwicyI6Imh0dHBzOi8vZGV2LW9wZW4tbWVzc2FnZXMtYXBpLWx0aDRnb3dkeXEtZXcuYS5ydW4uYXBwL21lc3NhZ2VzIiwiYSI6WyJkaWRjb21tL3YyIl19"
],
"created_time": 1516269022,
"expires_time": 1516385931
}
encrypt and pack a message, and un pack and decrypt the same message with the same library
As implemented, calling pack_encrypted
with the to
DID not requiring forwarding will cause the returned PackEncryptedMetadata
to omit the messaging_service
parameter.
I suggest always returning the messaging_service
parameter, even when forwarding is not required because not returning it requires me to rewrite routines already implemented by this library to determine the service endpoint to deliver my message to. It's not terribly complicated but it creates an opportunity for subtle discrepancies in implementation resulting in potentially inconsistent behavior.
Hi, would it be possible to add support for ios simulator target running on m1 mb ?
Give a brief description of the objective of this issue. What needs to be discussed?
The current produced types for TS is not following standards of the spec.
I just touched upon the DIDDoc type and that has false things such as:
/**
* DID for the given DID Doc
*/
did: string,
This should be id
- https://www.w3.org/TR/did-core/#did-document-properties
/**
* DID URLs of verification methods used for key agreement.
* See https://www.w3.org/TR/did-core/#verification-methods.
*/
key_agreements: Array<string>,
this should be keyAgreements
- https://www.w3.org/TR/did-core/#did-document-properties
So I dont know how literal to the spec one should be, but the resolved documents will not be of proper attributes if these types are correct.
Explain why you think this issue needs to be addressed and why it should be addressed in this repo.
Because the produced type is not correct to what a did doc should be if you want to work with other libraries.
Explain what actions or decisions need to be completed to close this issue.
- Using a task list here can be helpful to track progress.
Update the production of types to produce proper TS types
Include links to any examples, research or code that support this issue.
I dont know how this works with a wasmbinding and the rust magic, but I assume it transpiles the attribute values in the rust code directly to these names. And then I can understand things become a bit wonky.
Maybe one can define in some config somewhere to transpile to the right attributes?
Before submitting:
- Add appropriate labels for 'type:' and 'related to:'
- Add an assignee if you want to direct this issue at a particular individual
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.