ChatExchange Charter

1. Mission

Define an open, interoperable, and verifiable method for any internet domain to declare its official conversational endpoints — WhatsApp, RCS, Apple Business Chat, web chat, voice — in a way that can be discovered by humans, agents, and AI systems.

The goal is to make chat identity as universal and trustworthy as web and email identity became through A and MX records.

2. Scope

This charter covers:

• Definition and syntax of CX Records in DNS TXT form
• Optional discovery via /.well-known/cx.json
• Verification and attestation process
• Operation of public resolver APIs and trust logs
• Versioning, extensions, and compliance labeling ("CX Verified")

Out of Scope

• Message transport or encryption protocols
• Proprietary platform verification logic
• Commercial terms of messaging providers

3. Record Type Definition

_cx.<domain>. IN TXT "v=CX1; app=<app>; id=<identifier>; intent=<intent>[; meta=<k:v,...>]"

Key	Meaning
v	Spec version (e.g., CX1)
app	Messaging network ID (whatsapp, rcs, apple, telegram, web, voice)
id	Endpoint handle (E.164 for WhatsApp, URI for others)
intent	support | sales | info | hr | custom
meta	Optional key-value pairs (hours, locale, rate-limits)

4. Gateway Record (Optional)

Domains MAY publish a gateway host record that redirects clients to the proper chat endpoint.

cx.<domain> A/AAAA/CNAME → gateway.chatexchange.net

This gateway performs client-side negotiation or HTTP redirect to the appropriate app.

5. Verification & Attestation

• Domain ownership established via DNS control
• Verified records receive a signed JSON attestation served via resolver API
• Attestations MAY be logged in a public transparency ledger for auditability
• Resolver clients SHOULD prefer attested data when multiple sources exist

6. Security Considerations

• Domains SHOULD enable DNSSEC for integrity
• Agents MUST validate signatures before initiating conversation
• Phishing risk is reduced when clients resolve _cx records from apex or relevant subdomains only
• Implementations MUST respect user privacy and not leak contact metadata

7. Examples

_cx.example.com. IN TXT "v=CX1; app=whatsapp; id=+14155550101; intent=support"
_cx.shop.example.com. IN TXT "v=CX1; app=rcs; id=rcs:example_shop; intent=sales; meta=hours:10-18,locale:en-IN"

8. Roadmap

• CX-well-known (/.well-known/cx.json) for HTTP discovery
• Attestation Transparency Log publication
• Reference Resolver API (GET /resolve?domain=)
• Client Libraries (SDKs for Node, Python, Go)
• Governance Transition to a neutral foundation

9. Governance & Change Process

• Maintained by the Chat Exchange Working Group (CXWG)
• New RFCs follow proposal → discussion → consensus → publication via github.com/chatexchange/spec
• Versions use semantic numbering: CX1, CX1.1, CX2
• Drafts remain open for 90 days before standardization

10. Intellectual Property & Licensing

All text under CC-BY 4.0; reference implementations under Apache 2.0.
Logos and marks "Chat Exchange" and "CX Verified" are owned by EdgeCX Pvt Ltd and may be licensed under fair-use guidelines.

11. Participation

Community contributions are welcome through:

• GitHub issues and pull requests
• Mailing list: discuss@chatexchange.net
• Working-group calls (quarterly)

12. Acknowledgments

This draft draws inspiration from DNS, SPF, DKIM, and Let's Encrypt as open identity layers of the internet.
Initial stewardship by EdgeCX Pvt Ltd (India).

13. Document History

Version	Date	Notes
0.1	2025-10-06	Initial public draft

---

For questions or contributions, contact discuss@chatexchange.net or visit github.com/chatexchange/spec.