Identity to identity messaging

[polmaire]

Hey! I'm Pol, co-founder at Converse.
I'm writing this post to start a conversation on a topic that might become a standard or an XIP.
Please feel free to comment / debate, the goal here is to check if our need is specific or if it is a real XMTP use case.

Context
It's been a bit more than one month since we started working on Converse.
We often face a question that has no clear answer for now: who is talking to who?
Indeed, the protocol only handles wallet to wallet communication for now.
If I type an ENS to find someone in a client, the conversation that I start will not "remember" that I'm talking to this specific ENS.

Existing solutions

• Lens: they put the Lens ids of each participant in the conversationId: http://lens.dev/dm/<id1>-<id2> ; it is needed because some wallet contain several Lens profiles and they want to display which Lens profile is talking to which Lens profile.
• Converse: for each wallet, we check if there is a Lens profile attached and we take the first one. If there is no Lens profile, we take the first .eth address we find. And if there is no .eth address we display the 0x address. It works in most of the cases but it's not error proof and it can be misleading.

Proposition

I suggest we add information in the conversation metadata that will help remember who is talking to who.
It would help any client display the right information to the user.

The question is: how should we define "who"? From a user perspective, there are two clear use cases:

• .eth addresses
• Lens handles

But there will most probably be many more "identity providers" in the future:

• Farcaster accounts (going live on ethereum mainnet in 2023)
• unstoppable domains

One could also see other types of assets becoming "identities":

• PFPs (lots of people are creating social media accounts for their PFPs for example)
• NFTs representing characters in games

I'm voluntarily not exploring the technical ways to implement such identities for now because I want to start focusing on the use cases before going deeper into the tech needs.

Other remarks / questions

• if this notion of identity messaging starts being adopted by the community, what should we do if - for example - I sell my ENS domain? As a conversation remains attached to a wallet, it is a situation that should be handled well by the clients.
• if I'm right saying that tens of "identity providers" will exist in the future, we should make sure we can standardize this notion of identity across providers (& chains). We could think of creating a giant "identity resolver" that would help developers easily find any identity and find the wallet that owns it
• we at Converse would be happy to experiment on this topic locally and then let other clients adopt it. This discussion aims at having feedbacks in order to take the right angle to solve this question.

I'd be very happy to have your thoughts on this identity to identity concept. Thank you in advance!

[yash-luna]

Thanks for kicking of this discussion @polmaire! It's super important to think about the different primitives associated with communication.

First, I want to highlight that the slight difference between Lens and ENS (as it pertains to XMTP) today:

• Lens identities/NFTs are a part of conversationId so they're linked to conversations
• ENS is used only for resolution and reverse resolution, so conversations aren't truly linked to ENS NFTs

The resolver, identity, and conversationId concepts have significant overlap but I'll attempt to break them down individually to highlight the problem each of them address. Disclaimer: this is my understanding and I'm open to debating different perspectives around these concepts.

Resolver
Resolution solves the problem of human readable identifiers (that map to other identifiers). Similar to how website domain names abstract away IP addresses, memorable web3 names (ENS, Unstoppable, .lens, cb.id, etc) can abstract away EVM addresses, XMTP public keys, and other identifiers that are not human friendly.

I must admit that the lines between resolvers and identities (origin identities to be explicit) are blurry for me. In a world with account abstraction, an NFT (ENS, BAYC, etc) could theoretically generate XMTP keys that facilitate conversations with that specific NFT.

Identity
The identity used for XMTP communication is the XMTP key bundle (derived from 0x address via signature provided in the 'create identity' step when a user first onboards to XMTP). This key bundle is what enables secure and authenticated communication. It also holds the answer to who is talking to who - the ownership of the key bundles identifies the who.

Even though today only EOA addresses are supported for XMTP key creation, we want to support smart contract wallets, non-EVM chains, and account abstraction in the future. These updates will broaden the scope of what can create XMTP keys and therefore be the 'origin identity' for XMTP communication.

ConversationId
At its core, conversationId is a property that enables conversation filtering. Conversation filtering, achieved by logical separation, has tons of use cases today and I foresee many more applications as the community experiments and iterates. Some of the use cases I've thought about include:

• Identity distinction: distinguish conversations between the same two parent identities (0x addresses) but different Lens profiles. I think that using conversationId for sub-identity distinction will become less prevalent with support for account abstraction.
• Context: I own a popular NFT and people message me with offers frequently. All these offers are tagged with "NFT Offer - BAYC #342" in the conversationId so I can filter them out for my regular messaging experience. I can switch to a view that displays all NFT offers when I want to spend time reviewing them to decide whether to accept or reject.
• Meta conversations/topics: I'm using XMTP as the transport layer to play chess with @neekolas. The actual payloads aren't human readable and I don't want them to pollute my conversation with Nick. So I'd like to have a different conversation for all relevant messages here. Read receipts are another example of where meta conversations could be useful.

In some ways, you can think of conversationId like the Subject field in emails. An immutable context for a conversation. There are many more use cases for conversationId and the community experiments and create shared standards, we'll evaluate SDK support to facilitate ease of adoption and standardization.

[galligan]

@polmaire thanks for bringing this one up! It certainly is a complex topic, especially in the context of multiple different "identities" which may be associated with the same EOA, and therefore XMTP account.

Regarding your naming, I might suggest the use of simply "identifier" as this could be all-encompassing to refer to any kind of naming system (ENS), profile system (Lens), owned NFT association (BAYC 3073), or just 0x address.

To expand on your use cases a bit, I'll drop one more into the mix which would happen through the following scenario:

• 0xA starts a chat with 0xB
  • At this moment, 0xA is represented by alice.eth and 0xB is represented by bob.eth
  • Note that the chat itself is between the two 0x accounts
• 0xA registers a new ENS name and changes the primary domain to the new one, and sets up reverse resolution, so that it now resolves to aliceonchains.eth instead of alice.eth
• bob.eth notices that Alice's name is different than what they expected

After the name change, no history is preserved to help Bob know that at one point they were talking with Alice under the alice.eth name, and at a later point the name was changed.

This scenario happened with me specifically when I previously had matt.galligan.eth associated with my hot wallet that I was using with XMTP, and galligan.eth for one of my cold wallets. I later switched my hot wallet account to use the galligan.eth name, and thus the context of my previous name was gone from conversations.

It's not so bad when the name change is subtle, or obvious, as the examples above. It's much worse if someone takes an identifier away from an address entirely, which completely removes the context from previous conversations.

Whatever the solution may entail, it seems reasonable to desire an identifier to be associated with messages at the time that they're sent, so that the history may be preserved.

Clients could present the historical name as context, associated with previous messages, if the current name no longer matches the historical one. It could also present the current one (possibly even just an address) alongside for that additional context.

[dabit3]

Does XMT plan on enabling the filtering results at the protocol level as opposed to having to do so on the client?

It feels like, as adoption grows, it will not make a ton of sense to fetch all conversations and then filter on the client, but instead be able to retrieve only the conversations needed for the individual app.

If this becomes supported, then I guess the API for this will dictate how the specification is decided?

[qrtp]

I just mentioned this proposal in my own proposal. I think the approaches are complimentary. From my post, I made this distinction:

This discussion on Identity to identity messaging is related to this proposal, but has a slightly different level of abstraction for identity. In the other approach, every conversation might have a different display name for "who I am talking to" and the display name decision is left to the user starting the conversation. In other words, as the user starting the conversation when I search for aaronquirk.eth (vs quirk.x in the same wallet) my XMTP client would store metadata in the conversation that aaronquirk.eth is the display name of my conversation peer.

My proposal puts that initial preference of displayed name in the hands of the wallet owner, and at a higher account level vs. conversation level of abstraction. Once that initial display name decision is made, proposal #24 takes over to preserve the state of that display name. In principal, both solutions could be used simultaneously by an XMTP client to provide the best user experience.