Evaluate if / how to update the tails file format to use compressed elements

[swcurran]

There is a known cryptographic approach to publishing the elements of an AnonCreds tails file in compressed structure, resulting in a 50% savings in the size of a tails file -- or a 100% increase in the number of elements in a tails file of the same size. Thus a 768k tails file for a RevReg with 3000 credentials (the maximum recommended today for AnonCreds deployments) could have a RevReg size of 6000 credentials with this change.

The cost of the compression is that the holder must decompress the tails elements before use -- either as a one time process on saving (resulting in a doubling of the storage needed for the tails file) or as they are used in creating a presentation.

This task is to:

• define a good approach to conveying to a holder that a file is compressed (e.g. a version flag)
• implement holder code to handle both an uncompressed and compressed file, with some experimentation to determine the best time for a holder to decompress the file (on receipt or on use)
• adding a mechanism that an issuer can use to choose to produce an uncompressed or compressed file.

[TimoGlastra]

Might be good to make this an opt-in for the holder based on a header parameter? This way holders that don't support it are not interrupted, and holders that do support it get the benefits.

[swcurran]

Another option would be to have the Issuer place the compressed version of the tails file be at a deterministic location relative to the tails file location in the RevReg, so a holder knowing about the location could check it first and fall back to the actual location. For example, rather than doing a GET /<RevRegID>, the holder would first do a GET /<RevRegId>.z, and worse case, get a 404, and have to do a GET /<RevRegId>. A not-yet-updated holder would do a GET /<RevRegId> and get the uncompressed version. Eventually, the two files would be the same -- compressed version.

[swcurran]

General question for @TimoGlastra and other Mobile Wallet aware folks like @cvarjao, @jleach and others on the BC Wallet team.

What is a reasonable size for a tails file that a Mobile Wallet must download as part of being issued a VC?

To now, we have suggested that 768kb (3000 credentials) is the outside limit, but @andrewwhitehead was questioning that. Is 2.6MB reasonable (10k credentials, uncompressed)?

Once a Mobile Wallet is installed, what are the biggest files that you see being downloaded by the wallet? Include images, or any other data/code needed to operate the wallet.

Thanks

[cvarjao]

@swcurran , this is more of an user experience question than a technical question. If we assume 3G speeds (2Mbps), and 2.6MB file, we are adding at least 1 second delay just for downloading the file (which should be cached and such, so it is 1 time cost), and then I am not sure what is the processing/lookup time. Even though it is 1 time cost, delays usually have negative impact in the user experience for first time users

[swcurran]

@cvarjao -- yes -- absolutely a UX question. That's what I was asking.

Given the nature of how/when a tails file is retrieved. What is the largest file would you like issuers to use?