Standardized inbox filtering

[nmalzieu]

This is a disucssion about Standardized Inbox Filtering, a way for a user to define how to filter the conversation to display in an XMTP Client.

Currently, the XMTP network allows anyone to write to anyone without the option to opt-in or opt-out of conversations with other users. Implementing a standardized inbox filtering layer will provide users with more control over their communication preferences, reduce spam, and enhance privacy.

We could think of different "filtering layers":

1. Opted-in: The user has explicitly accepted talking with the other user.
2. Opted-out: The user has explicitly blocked the other user by clicking on a button in the interface of an XMTP client. Every conversation with the opted-out user is also considered opted-out.
3. Neither opted-in nor opted-out: The user received a message from another user but did not send anything nor clicked on any "allow" button.

Then we could define best practices that clients need to follow, for instance:

• Clients should create a "requests" section in their user interface containing all conversations with users in the "Neither opted-in or opted-out" category.
• Clients can add an additional layer of filtering, "Implicitly opted-in":
  • This is not at the protocol level but only a UX guideline at the client level, hence will not be synced between clients
  • The condition for implicit opt-in of a conversation could be that:
    • the user has sent at least one message in the conversation (the client will need to keep syncing messages in the conversation until it reaches the beginning of the conversation or the first message sent by the user)
    • there is a good chance of a positive interaction (e.g., having an on-chain transaction with the peer or following the peer on Lens or Farcaster)

Dependency: In order to store these filtering settings, we would need to have "protocol level user settings" (= user preferences).

• It could be a specific protected topic settings-0x..... that clients can write to using the XMTP Key to store encrypted settings. We could either post the whole settings to the topic everytime the settings change or have some way to store incremental data
• This would enable to share preferences between multiple clients, and help clients provide a consistent experience rather than building their preferences outside of the XMTP protocol (where switching to another client would make the user lose his preferences)
• We could all agree on specific "keys" and format to store some data, including filtering data.
• The SDKs would have a simple way to retrieve the settings (like await client.retrieveUserSettings()) in a JSON format
• We would have a specific key called filtering in the settings, with a format that could look like:

{
  "filtering": {
    "version": "1.0.0",
    "peers": {
      "0xa.....": "OPTED_IN",
      "0xb.....": "OPTED_OUT"
    }
  }
}

• It means that we trust the clients to not write malicious data to those settings (i.e. automatically Opt In to partners etc). But we already trust clients with our XMTP keys not to send malicious messages from our accounts, so this is probably ok.

[galligan]

This is awesome @nmalzieu and thanks for opening up the topic. The idea of layering in some inbox filtering in a standardized way that can be interoperable is a great first step on a path toward protocol-level consent. We've seen this done in some fashion to a couple of clients, notably the Lenster client which separates conversations from accounts that your Lens profile is not following.

I'd love to see something along these signs implemented into XMTP clients, so my mind goes to: What's the MVP for such a concept that would require minimal work to validate the concept?

Filtering MVP

While it would seem that a client simply sending a message to your own account would be the easiest way to store some of these preferences universally, that functionality was removed from the SDK out of caution surrounding security concerns. So naturally I wonder if it would be possible to use XMTP as it is today with no modifications, and somehow still achieve something similar for an MVP.

Perhaps it could look like this:

• Client fires up a burner account (new EOA) and initiates it with XMTP
  • Thought: Retaining the private key for this burner account might not be necessary, so long as messages can continue to flow into it. There may be some value in it though, where clients that update the settings by sending messages could sign those messages for a layer of trust and verification.
• Client starts initiates a new conversation with the burner
• Client forms the settings JSON payload and sends it as a message (possibly new content type?) to the new conversation
• Subsequent updates to the filter list could be sent as new messages with the entire JSON payload

Now, admittedly this approach likely doesn't scale or wouldn't be great for the long term. But maybe as "minimally viable" it could help us learn something.

Presuming this feels like a reasonable means to "store" some user preferences in a persistent way, what would the next leap be that might allow for interoperability? Does it require a protocol-level feature or self-messaging, or would it be possible to extend the "burner" concept further?

Ultimately I'm curious what others think might be a great way to just get moving along with something like this.

[yash-luna]

Can we use the self-message topic to store this data?

[polmaire]

hey @galligan I like the MVP approach here

I'm just a bit worried UXwise
If I understand correctly, it would mean that clients have to know that this conversation is not "for humans to read" and choose not to display it - right?

If we go that way, I'd say:

• we'll have to be very clear with builders and communicate efficiently with them
• messages in the convo should be "human readable" - something like the acknowledgment of receipt we received for SMS

Also - about retaining the private key within the client, I think the positive outcome is very limited because it would mean that other clients would not be able to access it.

Finally, tbh it would be much easier to use a convo that a wallet could have with itself & put a specific conversationId for settings. I don't know about the security issues (and of course it has to be taken into account) but that sounds like a much more viable solution.

Hope this helps!

[shanemac]

Maybe this is a dumb question, but is there a way to start even a step before client-level filtering which is on-chain data filtering and letting people bypass the request inbox based on on-chain data that they are using to filter their messages? The filter settings would be in the recipient's control and in their client's to help filter them all. Much like iMessage allows this on a basic level filtering.

I.E. Shane wants to allow any person who also owns the same NFT or creator of NFTs to be able to message me and implicitly be opted-in.

That's a very simple example but a very tiny first step that might help us see what that looks and feels like.

[trebor-yatska]

Some recent discussions on how to implement a "filtering MVP" have been focused on encoding user preferences in an interoperable smart contract.

[trebor-yatska]

Thanks for this proposal @nmalzieu. I feel one of the most important aspects of this topic is protecting the protocol. A few reasons why:

• Moving fast on codifying specific protocol level consent rules may lead to protocol corruption. It is much easier to make client app upgrades than it is to coordinate changes across the decentralized protocol. Experimentation can happen at the client level, and implementations that become hardened can be proposed as core protocol upgrades in future XIPs (I suspect we will quickly understand which consent features would be prime candidates for protocol level inclusion).
• There are laws across many different jurisdictions that dictate consent terms. The protocol is borderless--client apps residing in certain jurisdictions can decide if joining the network is in their best interest, and what controls must be put in place to do so.
• The protocol should provide certain agreed upon basic guarantees for participants, such as censorship resistance, availability, security, and self-sovereign data and identity ownership. Consent standards are complicated and user specific.

I think one path forward is a working group to get input on the basic protocol level framework, and to start building initial standards for client apps.

[nmalzieu]

Thanks. This topic is not about consent anymore (nothing to filter out in the protocol itself) but about filtering your inbox inside the client (which I guess is not under any law in any country?)
Our goal is to find a way to share my filtering preferences between the clients that provide the feature.
For that we can:

• provide an API that anyone can use for this (very centralized)
• do this in a interoperable manner (via a smart contract? may be too expensive to save user settings)
• use the protocol (which would be a very nice way to save other preferences in the future). It could be done through a specific topic for instance.

What do you think?

[qrtp]

use the protocol (which would be a very nice way to save other preferences in the future). It could be done through a specific topic for instance.

Needs to be this option, IMHO. If the user preferences are not available at the protocol level, then it is too hard to get clients to agree on a standard for managing such preferences. The preferences should be portable between any XMTP client, and for that the protocol needs to be involved.

[qrtp]

This would enable to share preferences between multiple clients, and help clients provide a consistent experience rather than building their preferences outside of the XMTP protocol (where switching to another client would make the user lose his preferences)

100% agree on this. Every client right now is building their own "user preference" infrastructure because it does not exist at the protocol level. For example, in order for our Unstoppable Domains iOS app to be approved, Apple required us to implement a "block" feature for a conversation. We were able to do this using our own hosted API, authenticated using a signature from the XMTP user's private key. I expect Coinbase Wallet and Converse had to do the same thing, so that's at least 3 implementations of user blocking that are in a specific non-portable silo for each of those apps.

If we could store these preference on the XMTP protocol itself, it would make the user experience much, much better. We could also store other user preference as I've suggested in #45. Note that a difference in #45 is that the user preference should be visible to any client for any user (a public visible preference) whereas the preference in this proposal is viewable only to the account owner (a private visible preference). Both public/private user preferences I think have value, depending on the context.