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

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