xmtp

Last week /xmtp got network-level allow/block prefs, which are shared between client apps.

So how can opt-in senders (e.g. subscriptions, newsletters, notifs) skip request filters now?

That's where a new XIP (permission preference proofs) comes in:

Last week /xmtp got network-level allow/block prefs, which are shared between client apps.

So how can opt-in senders (e.g. subscriptions, newsletters, notifs) skip request filters now?

That's where a new XIP (permission preference proofs) comes in:
https://community.xmtp.org/t/xip-43-permission-preference-proofs/552

Co-founder XMTP, building web3's secure messaging layer ➡️ https://xmtp.org

XIP-43 introduces a permission proof—a simple message signed by the user upon subscribing. That proof is then "attached" to the publisher's invite message, which is immediately sent, and can later be read by the subscriber's XMTP inbox app, using the proof to automatically allow the publisher's messages. 🚀

The best part of this is that it's seamless to the user—just subscribe, sign, and see the messages flow in.

But behind the scenes, their inbox is doing the work to validate the subscription sender's allowance, and still protecting them from unsolicited senders.

While it would have been ideal to have a "Subscribe with XMTP" button that toggled the publisher to "allow" with one-click, security implications made that a no-go.

So a new solution needed to be designed—one that doesn't require a user to sign into their XMTP account directly on the publisher's site.