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

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