Feature/compression #812
Feature/compression #812
Conversation
Signed-off-by: Kim Ebert <[email protected]>
Signed-off-by: Kim Ebert <[email protected]>
| Result: | ||
|
|
||
| ``` | ||
| {"invitation_url": "https://localhost:443?oob=eyJAdHlwZSI6ICJkaWQ6c292OkJ6Q2JzTlloTXJqSGlxWkRUVUFTSGc7c3BlYy9vdXQtb2YtYmFuZC8xLjAvaW52aXRhdGlvbiIsICJAaWQiOiAiYTYwZDhlYTAtZDg1Zi00NDJkLTk0NTktZTk2NWEyYjg3Nzg1IiwgInNlcnZpY2VzIjogW3siaWQiOiAiI2lubGluZSIsICJ0eXBlIjogImRpZC1jb21tdW5pY2F0aW9uIiwgInJlY2lwaWVudEtleXMiOiBbImRpZDprZXk6ejZNa296SGNjNzI0ajlGOFJBR214bTFOY3hpVlhtOE10c0NMQ0paWktacWRwd0Z3Il0sICJyb3V0aW5nS2V5cyI6IFsiZGlkOmtleTp6Nk1rcTNycDg1cm1qTjRwdnN5WUpWTlZoVXZBNUJwTWFlNkd5MlBUUzVZaHdVelIiLCAiZGlkOmtleTp6Nk1rbnZwTmEzQXdWOHl6SHJaM0s3WXVDdU1adXBiSEt0ZDJwVDN4U3NzODRqenEiXSwgInNlcnZpY2VFbmRwb2ludCI6ICJodHRwczovL21lZGlhdG9yNC50ZXN0LmluZGljaW90ZWNoLmlvOjQ0MyJ9XSwgImhhbmRzaGFrZV9wcm90b2NvbHMiOiBbImRpZDpzb3Y6QnpDYnNOWWhNcmpIaXFaRFRVQVNIZztzcGVjL2RpZGV4Y2hhbmdlLzEuMCJdLCAibGFiZWwiOiAiTGFiIn0=", "invitation": {"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/out-of-band/1.0/invitation", "@id": "a60d8ea0-d85f-442d-9459-e965a2b87785", "services": [{"id": "#inline", "type": "did-communication", "recipientKeys": ["did:key:z6MkozHcc724j9F8RAGmxm1NcxiVXm8MtsCLCJZZKZqdpwFw"], "routingKeys": ["did:key:z6Mkq3rp85rmjN4pvsyYJVNVhUvA5BpMae6Gy2PTS5YhwUzR", "did:key:z6MknvpNa3AwV8yzHrZ3K7YuCuMZupbHKtd2pT3xSss84jzq"], "serviceEndpoint": "https://localhost:443"}], "handshake_protocols": ["did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0"], "label": "Lab"}, "state": "initial", "trace": false, "invi_msg_id": "a60d8ea0-d85f-442d-9459-e965a2b87785"} |
There was a problem hiding this comment.
Please change the did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/out-of-band/1.0/invitation to use the didcomm.org prefix.
Should the example use did:peer keys? I suspect that is going to be typical, to enable reuse of connections.
I realize this is just an example, but it should be consistent with current best practices. I agree that the best examples to use for this are those that are typically pushed in QR codes — connection establishment, and especially connection-less presentation requests.
| @@ -1,53 +1,52 @@ | |||
| # Aries RFCs by Status | |||
There was a problem hiding this comment.
Updating index.md should be left out of the PR. That is done as a follow up, as it will cause conflicts.
| https://localhost:443?c=sztd&d=1&oob=KLUv_Wc3PnoBMAG1BgBijCwjEIfWAzs-1Bd8YPpweoDAqvElxVlFB2t_B0mLRHdVVVVVwQ1ZRjAL7yxb-TIysjm8Ed-yTeWLF1qo8MlxiEaMtHI3fSrdFbppodFuTwhO6WsiVbU3ECY-bHpEdFBAg8QUpAG-8RKYVKWACeQ87VWx2H7qLWqW-QNtLAt11M6HIEmkxwYucGqk1akI2O1ABcPSONJHGQaQDJnr8mtWyfL4Ho4t6nhZ-XGX-8dUCIn_JQ8CCgCVXyJ1RAnO_AEwww7QY1FQCCwIETfkSRDzzwJ-R-kV6uOdbQ== | ||
| ``` | ||
|
|
||
| The URL is reduced from 794 bytes to 370 bytes.(46.6 % of original size) There difference in the QR codes can be seen below. |
There was a problem hiding this comment.
How would this approach do on presentation requests? That’s where this is most important — and what pushes us into redirects.
|
I'c curious how this compares to e.g. gzipping the message (especially in oob presentation where there's multiple nested messages with same keys) and also making sure that e.g. attachments are using JSON data instead of base64 to avoid re-encoding multiple levels of base64 and also fully benefiting from compression. Also would be curious how a manual well-known compression algorithm could look like, as is used in did:peer:2 for example. We could look at the most common flows for QRs where using shortened invitations is not possible (i think the presentation flow as stephen mentioned being the most used one) and then optimize that flow. From our side i see us making such optimizations sooner, than using a trained model for compression/decompression, unless the difference between the approaches is significant |
Signed-off-by: Kim Ebert <[email protected]>
|
Hey @reflectivedevelopment — FYI that I’m trying to get an OOB invitation request for an connection-less presentation. I was reminded as I looked for an example that even though we do “connection-less” presentation requests in Bifold, we actually use a connection with a goal code For a full offline case, I think the same “single use connection” could be used where the DIDComm endpoint for the request/presentation is done with BLE. Again, the size of the QR code is minimized — just the connection data, so we don’t have to worry about the size of the presentation request. I think these approaches might be better than trying to coordinate a compression dictionary to be used across all implementations. |
No description provided.