-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add senderHmac
and shouldPush
to MessageV2
#519
Conversation
src/keystore/InMemoryKeystore.ts
Outdated
encrypted: ciphertext, | ||
senderHmac: await generateHmacSignature( | ||
keyMaterial, | ||
new TextEncoder().encode(contentTopic), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the hkdf salt/domain, I would suggest we also include some kind of time-dependent value, such as the number of months since the Unix epoch: xmtp/XIPs#35 (comment). This ensures that we have automatic key rotation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My worry about the time-dependent value is the complexity of keeping the push server up to date with the correct keys. If we had it roll over at 12am on the first of the month UTC, we'd guarantee that push notifications would not be correctly filtered for some time at the start of each month. Basically would be broken until the app starts up again, which requires integrators to have some sort of wakeup scheduled to refresh keys if they aren't comfortable with extended breakages each month. That's going to be a bigger ask for integrators.
The way to fix this is to have each user pass in not just the current month's key but also the next N months keys for each topic. That's fine, but it makes things more complicated from the push server side. Need to handle expirations etc. Clients would also need to be aware of their last upload time and periodically refresh.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary of discussion:
- We can pass (prev_hmac_key, current_hmac_key, next_hmac_key). That solves any roll over issues.
- We can expose an API that maps (list of topics to subscribe pushes for) -> (hmac keys for topics). Integrators simply need to call it any time the topic list changes, as well as periodically, and upload it if it changes. This only needs to happen every 30 days at most.
Deploying with Cloudflare Pages
|
42f16a9
to
b6b388f
Compare
08384e3
to
86063f6
Compare
MessageV2
senderHmac
and shouldPush
to MessageV2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One comment on the content of the HMAC, otherwise this makes sense
5320fa9
to
5c59492
Compare
5c59492
to
12895cb
Compare
🎉 This PR is included in version 11.4.0-beta.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
context: https://community.xmtp.org/t/xip-35-message-sender-identifier-in-topic/509/2
in this PR:
shouldPush
toContentCodec
typeshouldPush
method toTextCodec
andCompositeCodec
senderHmac
andshouldPush
toMessageV2
getV2ConversationHmacKeys
toInMemoryKeystore
to retrieve conversation topics and their associated HMAC keysTODO: