Re: Experimental did:cel Witness Service (open-source)

I think it is not so much about the actual size, but how much a
cloud-provider charges you if you want to host these logs at scale.

ke 11.3.2026 klo 8.00 ip. Alan Karp <alanhkarp@gmail.com> kirjoitti:

> I wonder if the concern of sizes is warranted.  I remember a report from
> the Plan 9 people some 40 or more years ago that their disks were getting
> emptier over machine generations.  Back then the growth in the amount of
> data was swamped by the increase in storage density.
>
> Does that observation apply today?  I have no idea, but it's what I see on
> my own machines.
>
> --------------
> Alan Karp
>
>
> On Wed, Mar 11, 2026 at 10:49 AM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> On Wed, Mar 11, 2026 at 10:38 AM Stephen Curran
>> <swcurran@cloudcompass.ca> wrote:
>> > I've been thinking about log size recently, particularly when combined
>> with PQ cryptography.  It seems to me that as we shift to the use of PQ
>> algorithms, the size of the data will be dominated by the keys and
>> signatures, and compression techniques will be much less useful. So if a 10
>> year log has 5 years of PQ keys and signatures will not benefit much from
>> compression.
>>
>> Maybe. :)
>>
>> I expect that keys that are re-used will be compressed greatly,
>> compression is going to help a lot there (the same public key might be
>> listed thousands of times, but will only need to go in the compression
>> table once and from there on out, will take up a few bytes instead of
>> thousands of bytes).
>>
>> However, if per-event pre-rotation is in play, you're right --
>> compression isn't going to help you at all. This is one of the reasons
>> did:cel doesn't do pre-rotation per event, though did:webvh escapes
>> the worst of it (I think?) by externalizing the signatures.
>>
>> My hope is also that SQISign will win out over the current PQ
>> standards, which have really large key sizes and signature sizes. For
>> example, SQISign at security level "NIST I" has 64 byte public keys
>> and 148 byte signatures.
>>
>> https://sqisign.org/
>>
>> ... which puts it in roughly the same category of storage requirements
>> as elliptic curve signatures (~2x-ish more storage required for
>> SQISign signatures, not the ~37x-ish storage needed for MLDSA or the
>> ~122x-ish storage needed for SLHDSA).
>>
>> But, you're right... if we stick with MLDSA or SLHDSA, the total data
>> you have to retrieve (no matter the log format) is going to balloon to
>> 37x to 122x. I think, Stephen, did:webvh has a design pattern to get
>> around this -- can you please remind me what happens there? I know you
>> externalize into two separate files, but what I'm wondering is if you
>> have to download both to verify (if you don't cache, that is).
>>
>> -- manu
>>
>> --
>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>> Founder/CEO - Digital Bazaar, Inc.
>> https://www.digitalbazaar.com/
>>
>>