You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many individuals in the various EVM communities possess multiple ETH addresses utilized for diverse on-chain activities. In instances where this was not intended to provide a degree of pseudonymity — meaning that the users do not mind if these addresses are associated to form a single onchain identity — a straightforward method is sought to utilize only one of these addresses for XMTP-based messaging.
One potential approach is for XMTP clients to facilitate simultaneous messaging from multiple addresses. However, this option is suboptimal as other identity attributes, such as PFP and ENS name, are all tied to a primary address.
An alternative approach, inspired by the early Unix days, involves having a ".forward" address without registering any other identity bundles. When clients query whether one of these addresses is enabled for XMTP communication, the response would indicate the presence of a forwarding address. Subsequently, the conversation would be directed to occur through that forwarding address.
Proposal
I am not well-versed in the underlying XMTP protocol, so this proposal may overlook essential considerations. If this idea gains popularity, it could be further developed with assistance from the XMTP team.
The proposal (in terms of the JS interface) involves modifying canMessage or introducing a new API canMessageWithForward that enables clients to verify whether an address is XMTP-enabled. This API would indicate that the specified address is not enabled, but a forwarding address is. User experience design could incorporate this response by prompting the user to decide if they wish to utilize the forwarding address.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Background
Many individuals in the various EVM communities possess multiple ETH addresses utilized for diverse on-chain activities. In instances where this was not intended to provide a degree of pseudonymity — meaning that the users do not mind if these addresses are associated to form a single onchain identity — a straightforward method is sought to utilize only one of these addresses for XMTP-based messaging.
One potential approach is for XMTP clients to facilitate simultaneous messaging from multiple addresses. However, this option is suboptimal as other identity attributes, such as PFP and ENS name, are all tied to a primary address.
An alternative approach, inspired by the early Unix days, involves having a ".forward" address without registering any other identity bundles. When clients query whether one of these addresses is enabled for XMTP communication, the response would indicate the presence of a forwarding address. Subsequently, the conversation would be directed to occur through that forwarding address.
Proposal
I am not well-versed in the underlying XMTP protocol, so this proposal may overlook essential considerations. If this idea gains popularity, it could be further developed with assistance from the XMTP team.
The proposal (in terms of the JS interface) involves modifying
canMessage
or introducing a new APIcanMessageWithForward
that enables clients to verify whether an address is XMTP-enabled. This API would indicate that the specified address is not enabled, but a forwarding address is. User experience design could incorporate this response by prompting the user to decide if they wish to utilize the forwarding address.Beta Was this translation helpful? Give feedback.
All reactions