-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Description
Steps to reproduce
- Create a widget that uses
sendToDevice - Send a to device message without encryption:
widgetApi.sendToDevice( 'com.example.message', false, { '@user-id': { '*': { hello: 'world' } } } )
- Send a device message with encryption
widgetApi.sendToDevice( 'com.example.message', true, { '@user-id': { '*': { hello: 'world' } } } )
Outcome
What did you expect?
Both messages can be received by another device.
What happened instead?
Only the unencrypted event is received.
I already analyzed it a bit more:
The issue is that the code flow for encrypted and unencrypted devices is different. In StopGapWidgetDriver, for unencrypted messages the content parameter of sendToDevice is forwarded as-is together with the event type, but the event type is not forwarded at all for encrypted messages. I could verify that on the receiver side, the message is received without any event type, neither is the content of the message correct, because the payload is not under the content property, but applied to the top level.
I think the correct way would be to construct a new payload object inside StopGapWidgetDriver that has a top level type and all content is placed in content. I could verify that doing it manually works:
widgetApi.sendToDevice( 'com.example.message',
true,
{ '@user-id':
{ '*':
{ type: 'com.example.message', content: {hello: 'world'} }
}
}
)Fixing this issue though might be a breaking change for existing widgets that use this API. Especially for Element Call. Element Call itself already takes care of this behavior and would break if the issue is fixed.
Operating system
macOS
Browser information
Chrome
URL for webapp
develop.element.io
Application version
Element version: a26be26-react-2da98a6024ff-js-16672b3d0cad Olm version: 3.2.12
Homeserver
matrix.org
Will you send logs?
No