I tried scanning from your branch, it isn't working, can you also check that please?

I tested the scanner but still got errors, take a look:

About the error you have after scanning the QR Code of the didcomm-mediator-rs, I feel like it is an internal issue cause I also have the issue but testing with a different Mediator it works well.

About the error you have after scanning the QR Code of the didcomm-mediator-rs, I feel like it is an internal issue cause I also have the issue but testing with a different Mediator it works well.

Is it working with the mediator rootsid, cuz i am testing with the rootsid mediator?

Yeah, for me it works with the RootsID DIDComm

About the errors i pasted above, they still persist. I confirm that i have tested with 2 other mediators. Please look into them again.

About the error we are getting after the scan, i realized the issue could be coming from the MediatorCoordnation.ts file because the Buffer.from method seem not to recognize the "base64url" encoding which we are using but rather it supports standard encoding like base64.

I suggest we convert the base64url string to a standard base64 string before encoding.
Also meaning that the call to the backend works but fails at this level.

About the error we are getting after the scan, i realized the issue could be coming from the MediatorCoordnation.ts file because the Buffer.from method seem not to recognize the "base64url" encoding which we are using but rather it supports standard encoding like base64.

I suggest we convert the base64url string to a standard base64 string before encoding. Also meaning that the call to the backend works but fails at this level.

I don't think so @mbunwe-victor, find the examples when each of them are used below, and also i dont think that should be an issue, but nevertheless, i'll do the modifications and run the test, to see the result.
Base64 → Use when encoding general binary data (e.g., emails, storage, images in HTML).
Base64URL → Use when encoding data for URLs, JWTs, and APIs to avoid special character issues.

So this is what i think we need to do, though its not precise in the tickets description.
We need the displayed data(e.g routing key) so that we'll send it to bob for messaging, so you'll update the backend by logging just the routing key and the display it in the frontend so that the user can copy it and send for messaging.

WDUT @IngridPuppet @hugoib ?

So this is what i think we need to do, though its not precise in the tickets description. We need the displayed data(e.g routing key) so that we'll send it to bob for messaging, so you'll update the backend by logging just the routing key and the display it in the frontend so that the user can copy it and send for messaging.

WDUT @IngridPuppet @hugoib ?

I thought it makes sense to reuse our QR code sharing view. did:peer addresses are definitely not user-friendly.

So this is what i think we need to do, though its not precise in the tickets description. We need the displayed data(e.g routing key) so that we'll send it to bob for messaging, so you'll update the backend by logging just the routing key and the display it in the frontend so that the user can copy it and send for messaging.
WDUT @IngridPuppet @hugoib ?

I thought it makes sense to reuse our QR code sharing view. did:peer addresses are definitely not user-friendly.

Yes yes, this also best:
@mbunwe-victor please look into that too please.

So about this discussion,

So this is what i think we need to do, though its not precise in the tickets description.
We need the displayed data(e.g routing key) so that we'll send it to bob for messaging, so you'll update the backend by logging just the routing key and the display it in the frontend so that the user can copy it and send for messaging.

i had this: