Re: Introduction: Glogos - logic layer 0 for truth and coordination

Sorry about the "spam", but also to clarify a few conflicts, the account is
also a document not a storage 😅 And " The server never decides validity."
Is only true when the server is in the role of the  "state relay and
persistence layer" When it is the role of a "service" it does decide
validity by verifying a signature using the keys of the DID.  And the actor
software running on the user-agent automatically handles most actions
according to protocol, regardless of how I might have placed the arrows or
worded some sentences... 😅

su 25.1.2026 klo 21.49 Jori Lehtinen (lehtinenjori03@gmail.com) kirjoitti:

> Resolution was horrible, hoping these are better:
>  [image: image.png][image: image.png]
>
> su 25.1.2026 klo 21.45 Jori Lehtinen (lehtinenjori03@gmail.com) kirjoitti:
>
>> Hi Manu,
>>
>> That is a really good take. I also appreciated your takes on the did:cel
>> vs did:webvh discussion, especially your emphasis on “standardizing just
>> one way to do it” and on designing did:cel in a way that is easy for
>> developers to implement, a very developer-considerate approach...
>>
>> I want to clarify that in my participation I am never trying to suggest
>> replacements. I am always trying to understand where existing/discussed
>> solutions would fit into the architecture I am building, not how to
>> displace them.
>>
>> I attached an image and a high-level explanation below that describes the
>> architectural flow.
>>
>> For the business value of this architecture, the key value propositions
>> are listed here:
>> https://github.com/z-base
>>
>> The key primitive that makes strict zero-knowledge possible is here:
>> https://www.npmjs.com/package/zero-knowledge-credentials
>>
>> For a draft conceptual specification, you can refer to:
>> https://github.com/z-base/z-base/blob/main/docs/specifications/CONCEPT.md
>>
>> What I would like to ask from the community is whether DID serves well
>> for the purpose described below, and to share that this is one concrete way
>> to bootstrap strict zero-knowledge applications.
>>
>> —
>> [image: z-base_flow.png]
>>
>> *Actor startup (always starts encrypted)*
>> The Actor starts with no readable local state. (even loading resources UI
>> displays empty fields and asynchronously updates to discovered state)
>> Any locally stored bytes are already encrypted and meaningless.
>> Without successful user-verified ZK credential discovery, the Actor
>> cannot reconstruct state, even locally.
>>
>> *ZK credential discovery (gate to existence)*
>> The Actor prompts for user verification via a device authenticator.
>> If verification succeeds:
>> – a ZK credential is discovered
>> – an opaque routing id is derived
>> – cipherJwk and hmacJwk are derived
>>
>> If verification fails:
>> – no identifier exists
>> – no state can be discovered
>> – the application has nothing to load
>>
>> State becomes *discoverable*, not “unlocked”.
>>
>> *Local state reconstruction*
>> Using the derived id, the Actor looks for encrypted local blobs.
>> If blobs exist, it attempts decryption using cipherJwk, if not it
>> attempts to find a backup from cloud, signs challenge with hmacJwk so
>> server can filter trash traffic.
>> If discovery or decryption fails, the state is treated as non-existent.
>>
>> *Base Station contact (asynchronous)*
>> After state exists or doesn't, the Actor may connect to a Centralized
>> Base Station.
>> The Base Station gates the connection.
>> The Actor responds only with opaque proofs.
>> The Base Station cannot read, interpret, or correlate any payload.
>>
>> *Resource bootstrap (if none exists)*
>> The Base Station indicates the resource does not exist.
>> The Actor submits an encrypted snapshot.
>> The Base Station assigns an authoritative resource identifier.
>> The Actor binds it to its encrypted local state.
>>
>> *Snapshot storage and delta relay*
>> Encrypted snapshots are stored verbatim.
>> Encrypted deltas are forwarded to peers but not persisted.
>> Delivery may be reordered or duplicated.
>>
>> *Peer collaboration and verification*
>> Manu signs a change/delta using a key bound to his public alias DID.
>> The encrypted change is relayed.
>> Jori’s Actor decrypts, verifies via DID, checks role, and decides locally
>> whether to merge.
>> The server never decides validity.
>>
>> *Public alias and first contact*
>> Actors publish a public alias (e.g. DID).
>> Public storage may contain:
>> – DIDs
>> – public wrap keys
>> – minimal profile data
>>
>> An Actor can create an ephemeral key, wrap it with the recipient’s public
>> key, and send an encrypted message.
>>
>> *Account as a capability container*
>> Discovered credentials unlock an ACCOUNT container.
>> The ACCOUNT holds resource credentials and manages the unlinkable public
>> alias, they can assert as identity to others (eg. `setActorInfo` method in
>> dacument).
>> It is private, but discoverable across devices via cross-platform
>> credentials.
>>
>> *Ongoing operation*
>> Actors mutate encrypted local state offline.
>> When connectivity resumes, snapshots and deltas are exchanged and merged
>> locally.
>>
>> Regards,
>> Jori Lehtinen
>>
>> su 25.1.2026 klo 18.56 Manu Sporny (msporny@digitalbazaar.com) kirjoitti:
>>
>>> On Sat, Jan 24, 2026 at 2:01 PM Manh Thanh Le <vnlemanhthanh@gmail.com>
>>> wrote:
>>> > Synthesis:
>>> > - Your ZKP: The Proof.
>>> > - Glogos: The Time.
>>> > - The Universe: The Anchor.
>>>
>>> Hey Manh, thank you for the productive engagement on the mailing list.
>>> Same to Amir, Jori, and Tyson. I wanted to jump up to a meta-point, as
>>> I haven't had the time to think deeply about the current discussion.
>>>
>>> To each of you: while it might seem that people are pushing back on
>>> ideas you are raising and/or are "just not getting it", be patient and
>>> keep trying. It takes a tremendous amount of communication to even
>>> remotely get on the same page, even when you are communicating
>>> clearly. It just takes time and many on this list are already starved
>>> for cycles where they can think deeply about what you're contributing
>>> to the discussion. Try not to take it personally, not that I think any
>>> of you are; it's just a part of the process.
>>>
>>> Sometimes it helps to point to exactly where your proposal can help:
>>> "Instead of doing X in step 3 of algorithm Y in specification Z, we
>>> can do this instead..." -- the larger the change you are suggesting,
>>> the less likely it is to fit into the existing ecosystem and the
>>> harder it will be for people to understand the ramifications (even if
>>> it's very clear in your mind what they are).
>>>
>>> Let me try to use did:cel and Glogos as an example. One thing Manh
>>> might be saying is:
>>>
>>> "We could add a Data Integrity proof to the list of witnesses for a
>>> log entry that anchors that log  entry to a particular point in time."
>>>
>>> Ok, that makes sense to me and I can see how that would be a fairly
>>> trivial addition to the protocol. Now, verifying the Glogos history
>>> would be far more involved, but that's "someone else's problem". If
>>> they want to use Glogos as the anchor, they will have to figure out
>>> how to do the verification OR they can just depend on some other
>>> witness that they trust. That makes the change fairly trivial, an
>>> option that has benefits, and doesn't require a large rearchitecting.
>>>
>>> Manh might also be saying:
>>>
>>> "You could replace the CEL specification with the Glogos specification
>>> and make Glogos your event log, where you store DID Documents as the
>>> payload for each event"
>>>
>>> Right, I can see how we might do that, but that effectively means that
>>> we have to go back to the drawing board to figure out if all the
>>> attack scenarios we've worked through with did:cel are handled with
>>> Glogos, which then requires me to understand Glogos at depth and
>>> probably do an implementation of it to really understand if it will
>>> meet the design criteria. That requires far more time than I'm likely
>>> to have over the next couple of months and will put me in a holding
>>> pattern to see if someone else does the analysis first in a way that's
>>> easy for me to understand.
>>>
>>> I'm seeing echoes of that issue with the email-to-did bridge (what is
>>> the commercial value created?) and the Dacument references (how is
>>> that better than CEL, Glogos, etc?).
>>>
>>> Again, I'm not making an argument for or against those solutions --
>>> just noting that the following usually helps:
>>>
>>> 1. Be very specific about where your technology fits into a current
>>> solution.
>>> 2. Be specific about the economic value generated such that people
>>> would have an incentive to pay/fund your solution (or work for "free"
>>> to see it achieved).
>>> 3. Explain the smallest set of changes that leads to the future you want
>>> to see.
>>>
>>> I'm not saying you have to do all of those, but if you can do them
>>> with precision, it will help focus the discussion and lead to deeper
>>> understanding by all involved.
>>>
>>> -- manu
>>>
>>> --
>>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>>> Founder/CEO - Digital Bazaar, Inc.
>>> https://www.digitalbazaar.com/
>>>
>>>