Re: [Email-to-DID Bridge] Exploring a practical migration path for email infrastructure

You mentioned:

*"Instead of replacing it, the goal should be to hollow it out from within:
keep the web as the discovery and transport plane, but move identity,
state, authority, and continuity into the client."*

While this approach (as taken by z-base) is valuable for certain use cases,
UDNA goes a step further by re-architecting the addressing layer itself.

UDNA rethinks addressing from first principles:

   -

   Instead of https://server.com/resource, UDNA uses
   udna://did:entity.example/resource.
   -

   The address is cryptographic, not geographic.
   -

   The DID (Decentralized Identifier) represents the *entity*, not its
   location.
   -

   Service endpoints are discovered via DID documents, not DNS.

This isn't about making servers "blind relays" but about making
addressing intrinsically
tied to identity, not infrastructure.

On Tue, 3 Feb 2026 at 03:57, Amir Hameed <amsaalegal@gmail.com> wrote:

> What UDNA Actually Addresses
>
> Today's internet is built around location-based addressing:
>
>    -
>
>    URLs and IP addresses point to *where* something is (a server, a
>    service, a resource).
>    -
>
>    DNS maps human-readable names to locations.
>    -
>
>    Trust is delegated to centralized authorities (CAs, DNS providers,
>    identity brokers).
>
> This creates several fundamental problems:
>
>    1.
>
>    Services are tied to infrastructure – If a service moves, its address
>    breaks.
>    2.
>
>    Identity is an afterthought – Authentication and authorization are
>    bolted on top of location-based protocols.
>    3.
>
>    Trust is centralized – Certificate Authorities, DNS hierarchies, and
>    identity providers become single points of failure and surveillance.
>    4.
>
>    No intrinsic privacy – IPs and metadata leak correlation data by
>    design.
>
>
>
> On Tue, 3 Feb 2026 at 03:55, Amir Hameed <amsaalegal@gmail.com> wrote:
>
>> Hi Jori,
>>
>> Thanks for sharing your thoughts on the current state of transport
>> protocols and the vision behind z-base. You've made several valid points
>> about the role of SMTP, HTTP, WebSockets, Tor, libp2p, QUIC, and DNS in
>> handling transport and discovery—and you're right that these protocols
>> already solve the problem of moving bytes and providing global discovery.
>>
>> However, I'd like to clarify that UDNA is not focused on replacing
>> transport or discovery layers. Instead, it aims to solve a deeper
>> architectural problem: decoupling identity from location.
>>
>> On Tue, 3 Feb 2026 at 01:45, Jori Lehtinen <lehtinenjori03@gmail.com>
>> wrote:
>>
>>> Transport is already solved. SMTP, HTTP, WebSockets, Tor, libp2p, QUIC,
>>> they all move bytes. What they do not solve is who someone is, where they
>>> can be reached, and how that mapping can change without a central
>>> authority. The current web already provides global discovery through DNS,
>>> domains, and centralized routing tables. Instead of replacing it, the goal
>>> should be to hollow it out from within: keep the web as the discovery and
>>> transport plane, but move identity, state, authority, and continuity into
>>> the client. That is what z-base is doing. It does not fight the web, it
>>> parasitizes it. Servers become blind relays and caches. Trust, history, and
>>> control live at the edge. Everything else is just useful plumbing.
>>>
>>> https://github.com/z-base
>>>
>>> ti 3.2.2026 klo 11.30 Amir Hameed (amsaalegal@gmail.com) kirjoitti:
>>>
>>>> Hey All,
>>>>
>>>> Have a look at our demo run of Universal DID Native Addressing CGs
>>>> implementation on a local wifi, looking forward to feedback, comments and
>>>> suggestions.
>>>>
>>>> On Wed, 28 Jan 2026 at 05:34, Amir Hameed <amsaalegal@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, 28 Jan 2026 at 6:56 PM, Michael Herman (Trusted Digital Web) <
>>>>> mwherman@parallelspace.net> wrote:
>>>>>
>>>>>> Updated diagram…
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Michael Herman (Trusted Digital Web) <
>>>>>> mwherman@parallelspace.net>
>>>>>> *Sent:* Wednesday, January 28, 2026 1:18 PM
>>>>>> *To:* Jori Lehtinen <lehtinenjori03@gmail.com>; Amir Hameed <
>>>>>> amsaalegal@gmail.com>
>>>>>> *Cc:* Daniel Hardman <daniel.hardman@gmail.com>; W3C Credentials CG <
>>>>>> public-credentials@w3.org>
>>>>>> *Subject:* RE: [Email-to-DID Bridge] Exploring a practical migration
>>>>>> path for email infrastructure
>>>>>>
>>>>>>
>>>>>>
>>>>>> Loose-related, at the Web 7.0 Foundation, we’re looking at forking
>>>>>> the open-source ZeroTier project and turning it into a DID-native,
>>>>>> DIDComm-native router/DID virtual network for DID-native, DIDComm-native
>>>>>> apps (aka Neuroplexes).
>>>>>>
>>>>>>
>>>>>>
>>>>>> Michael Herman
>>>>>>
>>>>>> Chief Digital Architect
>>>>>>
>>>>>> Web 7.0 Foundation
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Jori Lehtinen <lehtinenjori03@gmail.com>
>>>>>> *Sent:* Wednesday, January 28, 2026 12:30 PM
>>>>>> *To:* Amir Hameed <amsaalegal@gmail.com>
>>>>>> *Cc:* Michael Herman (Trusted Digital Web) <
>>>>>> mwherman@parallelspace.net>; Daniel Hardman <daniel.hardman@gmail.com>;
>>>>>> W3C Credentials CG <public-credentials@w3.org>
>>>>>> *Subject:* Re: [Email-to-DID Bridge] Exploring a practical migration
>>>>>> path for email infrastructure
>>>>>>
>>>>>>
>>>>>>
>>>>>> I can totally see it working that way, but how do you deliver the
>>>>>> response from Bob's DIDComm client to Alice's email client with end-to-end
>>>>>> encryption, wich is obviously the more crucial part here as Bob  is the one
>>>>>> that cares about total privacy. I think this can still be a good idea even
>>>>>> without e2e encryption guarantee, however if you can solve that part it is
>>>>>> always better. An organizations internal messaging can always be
>>>>>> "decenralized" by making it centralized to the organization controlled
>>>>>> machinery just by self-hosting any regular server software. But as stated I
>>>>>> think this can help with "adoption pain" regardless so it is not
>>>>>> necessarily a bad idea.
>>>>>>
>>>>>>
>>>>>>
>>>>>> ke 28.1.2026 klo 14.14 Amir Hameed (amsaalegal@gmail.com) kirjoitti:
>>>>>>
>>>>>> Hi Jori
>>>>>>
>>>>>>
>>>>>>
>>>>>> It’s hard to explain every detail in a single email but since the
>>>>>> points raised are critical I would try best to give a proper walkthrough
>>>>>>
>>>>>>
>>>>>>
>>>>>> Let me walk through the protocol step by step and show precisely
>>>>>> where privacy risks arise and how the architecture addresses them.
>>>>>>
>>>>>> Step-by-Step Protocol Flow
>>>>>>
>>>>>>
>>>>>>
>>>>>> Phase 1: Sender initiation
>>>>>>
>>>>>>
>>>>>>
>>>>>> Scenario: Alice (an email user) wants to message Bob (a DID user).
>>>>>>
>>>>>>    1. Alice composes an email to bob-executive@company.org
>>>>>>    2. Her email client performs a standard DNS/MX lookup for
>>>>>>    company.org
>>>>>>    3. The message is delivered to company.org’s SMTP server, which
>>>>>>    runs the bridge
>>>>>>
>>>>>>
>>>>>>
>>>>>> At this stage, privacy behaves exactly like normal email. Alice’s
>>>>>> email provider sees standard SMTP metadata. The receiving SMTP server at
>>>>>> company.org receives the message within infrastructure controlled by
>>>>>> that organization. This is the baseline privacy model of email and cannot
>>>>>> be changed by any overlay system.
>>>>>>
>>>>>> Phase 2: Bridge processing
>>>>>>
>>>>>>    4. The SMTP server invokes bridge.handle_email(message)
>>>>>>    5. The bridge consults its internal routing table:
>>>>>>
>>>>>> bob-executive@company.org → did:web:company.org:bob
>>>>>>
>>>>>>    6. The bridge converts the email into a DID message representation
>>>>>>
>>>>>>
>>>>>>
>>>>>> The critical design decision here is that the email-to-DID routing
>>>>>> table is privately maintained by each organization. There is no global
>>>>>> directory and no shared mapping service. company.org alone controls
>>>>>> and stores this mapping inside its own infrastructure.
>>>>>>
>>>>>> Phase 3: Message transformation
>>>>>>
>>>>>>    7. The bridge constructs a DID message:
>>>>>>
>>>>>>
>>>>>>
>>>>>>    - The payload is encrypted using Bob’s public key from his DID
>>>>>>    document
>>>>>>    - Metadata such as sender, timestamp, and subject is preserved
>>>>>>    - Email headers are mapped into DID message attributes
>>>>>>
>>>>>>
>>>>>>
>>>>>> End-to-end encryption is applied at this stage. Only Bob can decrypt
>>>>>> the message. The bridge itself handles ciphertext only and cannot read the
>>>>>> content.
>>>>>>
>>>>>> Phase 4: Protocol-agnostic routing
>>>>>>
>>>>>>    8. The bridge inspects Bob’s DID document to discover service
>>>>>>    endpoints. This may include:
>>>>>>
>>>>>>
>>>>>>
>>>>>>    - A DIDComm endpoint (preferred)
>>>>>>    - A WebSocket endpoint
>>>>>>    - An HTTP/HTTPS endpoint
>>>>>>    - Or email as a fallback if no DID endpoint is available
>>>>>>
>>>>>>
>>>>>>
>>>>>>    9. The message is delivered using the selected transport
>>>>>>
>>>>>>
>>>>>>
>>>>>> Decentralization emerges here because each DID holder independently
>>>>>> controls their service endpoints. Multiple transport options avoid
>>>>>> single-point dependencies, and fallback mechanisms ensure reliable delivery.
>>>>>>
>>>>>> Phase 5: Recipient processing
>>>>>>
>>>>>>    10. Bob’s DID wallet receives the encrypted message
>>>>>>    11. The message is decrypted locally using Bob’s private key
>>>>>>    12. The message is presented in Bob’s interface (wallet, agent,
>>>>>>    or email client via plugin)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Decryption occurs only on Bob’s device, not on any intermediary
>>>>>> system.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Where privacy could break and how it is prevented
>>>>>>
>>>>>> One risk is the bridge becoming a centralized surveillance point if
>>>>>> everyone relied on a single service. The architecture avoids this by
>>>>>> treating the bridge as open-source software, not as a hosted service.
>>>>>> Organizations deploy their own instances, control their own routing tables,
>>>>>> audit the code, and remain independent of external operators.
>>>>>>
>>>>>> Another risk is metadata correlation. Even with encrypted content,
>>>>>> timing and volume can reveal patterns. Bridges can mitigate this using
>>>>>> message batching, randomized delays, optional padding to normalize sizes,
>>>>>> and privacy-preserving transports such as Tor or I2P for DIDComm delivery.
>>>>>>
>>>>>> A third risk is a centralized mapping database. This is avoided
>>>>>> because mappings exist only within each organization’s infrastructure.
>>>>>> There is no global registry of email-to-DID associations.
>>>>>>
>>>>>>
>>>>>>
>>>>>> What decentralization actually means in this design
>>>>>>
>>>>>> Each organization retains sovereign control over its routing tables,
>>>>>> security policies, supported transports, and encryption standards.
>>>>>>
>>>>>> Multiple implementations are possible because the system is defined
>>>>>> through standard interfaces. Organizations can use a reference
>>>>>> implementation, build their own, or extend it with custom logic, while
>>>>>> remaining interoperable.
>>>>>>
>>>>>> Recipients control which DIDs map to which email addresses, which
>>>>>> endpoints they publish, what transports they accept, and whether they
>>>>>> participate at all.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Addressing your core concern
>>>>>>
>>>>>> You noted that it is “quite hard to uphold the promise of privacy and
>>>>>> decentralization.” That concern is valid for centralized service models.
>>>>>>
>>>>>> This design is different: it is a protocol implementation, not a
>>>>>> service.
>>>>>>
>>>>>> Privacy and decentralization arise from localized processing inside
>>>>>> each organization’s infrastructure, end-to-end encryption before messages
>>>>>> leave the bridge, recipient-controlled cryptographic identity and
>>>>>> endpoints, and the absence of any central registry.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Realistic boundaries
>>>>>>
>>>>>> We cannot change the fundamental architecture of email. When senders
>>>>>> use external providers, those providers will always see metadata.
>>>>>>
>>>>>> What this system provides is end-to-end encryption after the message
>>>>>> enters the recipient organization, full control over identity translation
>>>>>> for domain owners, and a migration path that does not require universal or
>>>>>> immediate adoption.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Discovery model
>>>>>>
>>>>>> The bridge serves recipients, not senders.
>>>>>>
>>>>>> Bob’s email-to-DID mapping exists only inside his organization’s
>>>>>> bridge. The sender needs only Bob’s email address.
>>>>>>
>>>>>> In the DID-to-email direction, if a sender knows Bob’s DID but Bob’s
>>>>>> DID endpoints route through his bridge, the message can be translated to
>>>>>> email. If not, delivery fails, correctly reflecting Bob’s choice not to
>>>>>> accept email delivery.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Practical example
>>>>>>
>>>>>> An external partner emails contact@enterprise.com.
>>>>>>
>>>>>> The enterprise bridge routes the message to internal DIDs, encrypts
>>>>>> it, and delivers it to internal teams via DIDComm.
>>>>>>
>>>>>> Replies are sent as DID messages, translated back into email by the
>>>>>> bridge, and delivered to the external partner.
>>>>>>
>>>>>> The partner receives a normal email and is unaware of the DID layer.
>>>>>>
>>>>>> The privacy benefit is strongest for the organization and its
>>>>>> internal users, while compatibility with the existing internet is preserved.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Conclusion
>>>>>>
>>>>>> Privacy and decentralization are achieved through:
>>>>>>
>>>>>>    - Distributed deployment, with each organization operating its
>>>>>>    own bridge
>>>>>>    - End-to-end encryption for translated messages
>>>>>>    - Recipient-controlled identities and endpoints
>>>>>>    - No central mapping or routing authority
>>>>>>    - Transparent, auditable implementation
>>>>>>
>>>>>> We are not proposing a centralized gateway. We are providing protocol
>>>>>> building blocks that organizations can deploy inside their own security
>>>>>> perimeter, under their own governance and access controls.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Amir Hameed Mir
>>>>>>
>>>>>> Sirraya Labs
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, 28 Jan 2026 at 4:48 PM, Jori Lehtinen <
>>>>>> lehtinenjori03@gmail.com> wrote:
>>>>>>
>>>>>> I think that would be extremely valuable. But it also might be quite
>>>>>> hard to uphold the promise of privacy and decentralization there. If you
>>>>>> could walk us trough the protocol/process step by step, it would be easier
>>>>>> to consider how it would work exactly and identify + tackle possible issues.
>>>>>>
>>>>>>
>>>>>>
>>>>>> ke 28.1.2026 klo 13.13 Amir Hameed (amsaalegal@gmail.com) kirjoitti:
>>>>>>
>>>>>> Hi Jori,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes, conceptually there are two symmetric gateway endpoints. One
>>>>>> translates SMTP email into DIDComm messages and delivers them to a DID
>>>>>> inbox. The other translates DIDComm messages back into email and delivers
>>>>>> them via SMTP.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The key value is that one side can use decentralized,
>>>>>> cryptographically secure messaging (DIDComm) without requiring the other
>>>>>> side to migrate, install anything, or even know about DIDs.
>>>>>>
>>>>>>
>>>>>>
>>>>>> This removes the adoption barrier that normally kills new identity
>>>>>> and messaging systems, while still enabling privacy, authentication, and
>>>>>> decentralization where it is needed.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Amir Hameed
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, 28 Jan 2026 at 4:40 PM, Jori Lehtinen <
>>>>>> lehtinenjori03@gmail.com> wrote:
>>>>>>
>>>>>> So two endpoints? One that translates email to did, and another one
>>>>>> that translates did to email? And the value proposition is what? Takes
>>>>>> email message and transforms it to a DIDComm message and delivers it to
>>>>>> some kind of DIDComm inbox and the other way around allows to respond with
>>>>>> a DIDComm message turned in to email and gets translated and delivered to
>>>>>> an email inbox. So if another party wants decentralized and private
>>>>>> messaging they can have that with a person that doesn't want to migrate or
>>>>>> doesn't care or something like this?
>>>>>>
>>>>>>
>>>>>>
>>>>>> ke 28.1.2026 klo 12.10 Amir Hameed (amsaalegal@gmail.com) kirjoitti:
>>>>>>
>>>>>> Hi Michael
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thank you for engaging, I don’t have single full architecture diagram
>>>>>> but I just draw one for you and I am attaching it here , I believe it will
>>>>>> give you an idea of how bidirectional runtime mapping happens between two
>>>>>> different identifiers, Have a look then we can dive deep into what goes
>>>>>> under the hood, there are two mappings happening inside runtime, one is
>>>>>> header mapping and another is message format mapping.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, 28 Jan 2026 at 3:26 PM, Michael Herman (Trusted Digital Web)
>>>>>> <mwherman@parallelspace.net> wrote:
>>>>>>
>>>>>>
>>>>>>    1. RE: a bidirectional DID ↔ Email bridge acting as a universal
>>>>>>    message router
>>>>>>
>>>>>>
>>>>>>
>>>>>> This is confusing because “DID” (an identifier) and “Email” (an email
>>>>>> message/system/protocol) are “not of the same type”.
>>>>>>
>>>>>>
>>>>>>
>>>>>> For example: DID and Email Address are of the same type (both
>>>>>> character string identifiers).
>>>>>>
>>>>>>
>>>>>>
>>>>>>    2. RE: translates email messages into DID-native formats
>>>>>>
>>>>>>
>>>>>>
>>>>>> What is a “DID-native (email message) format”? …an example?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Michael Herman
>>>>>>
>>>>>> Chief Digital Architect
>>>>>>
>>>>>> Web 7.0 Foundation / TDW™
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Amir Hameed <amsaalegal@gmail.com>
>>>>>>
>>>>>> *Sent:* Tuesday, January 27, 2026 1:05 PM
>>>>>> *To:* Daniel Hardman <daniel.hardman@gmail.com>
>>>>>> *Cc:* Michael Herman (Trusted Digital Web) <
>>>>>> mwherman@parallelspace.net>; W3C Credentials CG <
>>>>>> public-credentials@w3.org>
>>>>>> *Subject:* Re: [Email-to-DID Bridge] Exploring a practical migration
>>>>>> path for email infrastructure
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Michael
>>>>>>
>>>>>> The core idea of this bridge is to be fully protocol-agnostic. While
>>>>>> DIDComm is currently the strongest candidate for DID-native messaging, the
>>>>>> design is not limited to it—we have already tested WebSockets and
>>>>>> HTTP-based delivery methods as well.
>>>>>>
>>>>>> The real problem we are addressing is that today there are two types
>>>>>> of users: those who prefer communicating via DIDs, and those for whom
>>>>>> traditional email is perfectly sufficient. In real-world scenarios such as
>>>>>> customer support or enterprise communication, both groups must be able to
>>>>>> coexist and communicate seamlessly.
>>>>>>
>>>>>> This becomes a classic translation problem, similar to human
>>>>>> languages. If one person speaks Hindi and another speaks English,
>>>>>> communication is only possible through a translator. In the same way, the
>>>>>> DID world and the email world require a neutral translation layer.
>>>>>>
>>>>>> That is what this system provides: a bidirectional DID ↔ Email bridge
>>>>>> acting as a universal message router. It maps email addresses to DIDs and
>>>>>> translates email messages into DID-native formats (and vice versa) at
>>>>>> runtime.
>>>>>>
>>>>>> Rather than being just a mailbox, it functions as a universal message
>>>>>> box, capable of handling both email and DID messages simultaneously. Users
>>>>>> remain free to choose how they communicate, while the bridge ensures
>>>>>> interoperability underneath.
>>>>>>
>>>>>> The goal is to enable gradual adoption of decentralized identity
>>>>>> without breaking compatibility with the existing, widely-used email
>>>>>> ecosystem, while keeping the system open-source and extensible for future
>>>>>> protocols.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Amir Hameed Mir
>>>>>>
>>>>>> Sirraya Labs
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, 27 Jan 2026 at 5:55 PM, Daniel Hardman <
>>>>>> daniel.hardman@gmail.com> wrote:
>>>>>>
>>>>>> email + DIDComm work:
>>>>>> https://github.com/decentralized-identity/didcomm-messaging/blob/main/extensions/email_transport/main.md
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 26, 2026 at 4:57 PM Michael Herman (Trusted Digital Web)
>>>>>> <mwherman@parallelspace.net> wrote:
>>>>>>
>>>>>> Amir, once you’ve mapped an SMTP email address to a DID, which
>>>>>> protocol are you using to complete the email message delivery?  …for
>>>>>> example, is it DIDComm?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Michael Herman
>>>>>>
>>>>>> Chief Digital Architect
>>>>>>
>>>>>> Web 7.0™ / TDW™
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Amir Hameed <amsaalegal@gmail.com>
>>>>>> *Sent:* Sunday, January 25, 2026 12:51 PM
>>>>>> *To:* W3C Credentials CG <public-credentials@w3.org>
>>>>>> *Subject:* [Email-to-DID Bridge] Exploring a practical migration
>>>>>> path for email infrastructure
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hello CCG community,
>>>>>>
>>>>>> I'm writing from Sirraya Labs to share an early-stage but
>>>>>> production-tested approach we've been developing: an *Email–DID
>>>>>> Router* that bridges traditional email infrastructure with
>>>>>> decentralized identity (DID/VC) systems. We're keen to gather feedback,
>>>>>> explore alignment with related W3C work, and understand whether this
>>>>>> direction resonates with the community’s broader interoperability goals.
>>>>>> What we’re exploring
>>>>>>
>>>>>> The system operates as an enterprise-grade gateway that:
>>>>>>
>>>>>>    - Maps traditional email addresses (e.g., executive@company.com)
>>>>>>    to DIDs (e.g., did:example:alice123)
>>>>>>    - Transforms SMTP-based emails into verifiable, identity-aware
>>>>>>    messages
>>>>>>    - Routes messages using confidence-based logic, security
>>>>>>    screening, and configurable policies
>>>>>>    - Runs with full auditability and measurable performance (tested
>>>>>>    in live environments)
>>>>>>
>>>>>> Here’s a snapshot from a recent run:
>>>>>>
>>>>>> text
>>>>>>
>>>>>> [2026-01-25T11:31:28Z INFO  email_did_gateway] Processing incoming email from chairman@board-of-directors.com to executive@company.com
>>>>>>
>>>>>> [2026-01-25T11:31:28Z INFO  email_did_gateway] Successfully processed email into DID message: 71259949-4f38-46a1-8c74-c86540ba5917
>>>>>>
>>>>>> [2026-01-25T11:31:28Z INFO  email_did_router] Processed executive email - Confidence: 0.78, Method: RuleBased
>>>>>>
>>>>>> Why this matters for DID/VC adoption
>>>>>>
>>>>>> Email remains the dominant channel for business, institutional, and
>>>>>> personal communication. Rather than proposing a disruptive replacement,
>>>>>> we’re focused on *building incremental, opt-in bridges* that allow:
>>>>>>
>>>>>>    1. Gradual migration of trust from SMTP+PKI to DID/VC models
>>>>>>    2. Immediate value through better routing, security screening,
>>>>>>    and audit capabilities
>>>>>>    3. Preservation of existing infrastructure and investment while
>>>>>>    enabling verifiable communication
>>>>>>
>>>>>> We see potential alignment with several W3C efforts—DID Comm, VC-API,
>>>>>> identity hubs, and trust spanning protocols—and are keen to explore how
>>>>>> this work might complement ongoing standardization.
>>>>>> Questions for the community
>>>>>>
>>>>>> Before we formalize or release anything publicly, we’d value your
>>>>>> perspectives on:
>>>>>>
>>>>>>    - *Use cases* we may have overlooked (enterprise, government,
>>>>>>    healthcare, education, etc.)
>>>>>>    - *Privacy and compliance considerations* (GDPR, residency,
>>>>>>    retention, consent)
>>>>>>    - *Mapping lifecycle* (persistence, revocation, recovery,
>>>>>>    expiration)
>>>>>>    - *Confidence and trust models* suitable for email→DID routing
>>>>>>    - *Potential alignment* with existing or emerging W3C
>>>>>>    specifications
>>>>>>
>>>>>> We’re particularly interested in whether this kind of bridge could
>>>>>> help accelerate real-world adoption of DID/VC systems in environments where
>>>>>> email remains non-negotiable.
>>>>>>
>>>>>> We’re at the stage of gauging interest and refining the approach
>>>>>> based on community feedback. If this resonates, we’d be happy to:
>>>>>>
>>>>>>    - Share more detailed design notes
>>>>>>    - Discuss integration with related CCG work items
>>>>>>    - Potentially present in a future CCG call
>>>>>>    - Explore collaboration with groups working on interoperability,
>>>>>>    trust layers, or migration pathways
>>>>>>
>>>>>> Our goal is to help build *responsible, incremental bridges*—not to
>>>>>> replace email or DIDs, but to enable them to coexist and evolve together.
>>>>>>
>>>>>> We look forward to your thoughts, critiques, and suggestions.
>>>>>>
>>>>>> Best regards,
>>>>>> Amir Hameed
>>>>>> Sirraya Labs
>>>>>>
>>>>>>