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

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/
>
>