Abstract
This proposal suggests adding a standardized theming and skin system to XMTP-based messaging clients, allowing users to personalize the visual appearance of their chat interface, including color schemes, font choices, bubble styles, and dark/light mode preferences while keeping this entirely client-side and non-intrusive to the protocol layer.
Motivation
XMTP is positioning itself as the messaging infrastructure for the open web. As more consumer-facing apps build on top of it, user experience and retention become just as critical as protocol correctness. Right now, most XMTP clients ship with a fixed UI, you get what you get. That’s fine for early-stage infra, but as adoption grows, the lack of personalization becomes a genuine friction point.
People spend hours a day inside messaging apps. The ability to make that environment feel like yours, whether that’s a dark theme for late-night use, a high-contrast mode for accessibility, or just aesthetic preference isn’t a luxury. For many users, especially in the Web3 space where identity and self-expression are core values, it’s an expectation.
Telegram built a thriving ecosystem around custom themes. Discord lets users tweak nearly everything. If XMTP-powered apps want to compete for daily active users, theming is low-hanging fruit that pays off in engagement and loyalty.
Proposal
Introduce a lightweight, optional theming specification for XMTP clients that defines:
1. A standard theme schema A JSON-based theme format that covers the core visual tokens: background colors, text colors, accent/brand colors, message bubble styles, font family and size, border radius, and icon set. Apps that adopt the schema can automatically support community-built themes.
2. User-level theme storage Theme preferences stored locally on the client (or optionally persisted via the user’s wallet identity, similar to how XMTP stores consent preferences). This keeps it fully self-sovereign no central server holds your preferences.
3. A shared theme registry (optional, off-protocol) A community-maintained, off-chain registry where designers and developers can publish and discover themes. Think of it like an app store for skins completely opt-in, no impact on the protocol itself.
4. Built-in presets At minimum, all XMTP reference clients should ship with: Light, Dark, High Contrast (accessibility), and OLED Black. These cover the most common user needs out of the box and set a quality baseline for third-party themes.
Scope & Protocol Impact
This is intentionally a client-layer concern. Nothing about the XMTP protocol or envelope format changes. No new message types. No new node behavior. The proposal is purely about standardizing how the presentation layer is built so that:
- Apps that want to implement theming aren’t each reinventing the wheel
- Users who move between XMTP-compatible clients have a familiar, portable experience
- Accessibility requirements can be more easily met across the ecosystem
Why Now
XMTP is at an inflection point. With decentralization milestones being hit, group messaging maturing, and more consumer apps coming online, the ecosystem is shifting from “does it work” to “do people enjoy using it.” Theming is a small but visible signal that the protocol cares about the end user, not just the developer.
It’s also a great way to invite designers into the XMTP community a group that’s currently underrepresented in improvement discussions.
Curious to hear what other community members think, especially from teams actively building consumer clients on XMTP. 
