IMPORTANT: This post contains ideas intended to spark discussion and gather feedback. These are not final concepts and must not be interpreted as implementation details. For official information about how XMTP works, see the XMTP technical documentation. Have questions about this post? We’d love to hear from you—post a reply.
Create and Enable Decentralized Contacts
A decentralized identity (DID) allows a user to validate their own XMTP registration request using a robust cryptographic signature. This validation can typically be done with a blockchain wallet. This on-chain registration can serve to mitigate spam while providing a robust and censorship-resistant identity record.
However, because posting transactions to the blockchain can be expensive, this might hinder the growth of the XMTP network.
This idea proposes a DID workflow that ensures security when transitioning from off-chain to on-chain identity. Here’s how it benefits everyone:
- The identity provider handles the cost of moving transactions on-chain
- The user can verify their identity details using a signed meta transaction. This makes it impossible for an identity provider to cheat or alter identity details.
The contact operations proposed below enable the XMTP client to store and validate a decentralized device bundle, including profile information.
This work represents the first phase of Decentralizing XMTP, intending to enhance security, neutrality, and censorship resistance for decentralized XMTP identity management.
This Contact Directory operates on the premise that an Ethereum public key (EPK) can effectively act as a proxy for a DID registered under the did:eth registry protocol. This registry offers a decentralized means to link a key bundle with an EPK, forming a unique contact ID.
It’s important to note that, with the long-term goals of XMTP in mind, the aim is to facilitate contact workflows that don’t necessarily rely on Ethereum. In such scenarios, the on-chain registry must incorporate a mapping to accommodate a broader DID framework.
For more details about the Contact Directory, see this Contact Operations – Registry discussion.
This workflow suggests three separate RPC endpoints to achieve fruition:
- GrantInstallation stores a public contact bundle to the identity profile
- RevokeInstallation revokes a contact bundle for an identity profile
- FetchInstallation provides a convenient mechanism to retrieve the device installations
This contact workflow is permissionless by design and enables XMTP clients to migrate directly to this decentralized approach.
