swcurran
commented
8 months ago 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 aries.vc.verifier.once (see definition) so that we get a smaller, QR code that is independent of the size of the presentation request. That eliminates the need for compression when doing presentation requests with the users having an internet connection, while avoiding the need for a shortened URL to make the QR code feasible.
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.
TelegramSam
dbluhm
KimEbert42
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