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

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/

Received on Sunday, 25 January 2026 16:54:30 UTC