MSC3489 Live Location Sharing

[torrybr]

This issue tracks the progress and outstanding work for implementing the functionality described in MSC3489. It involves sending, stopping, and handling beacon and beacon_info events within the SDK and builds on events types in Ruma.

Related Communication

Initial discussion can be found in this draft PR.

Completed Tasks:

• [x] Support for sending, stopping & updating beacon_info events in matrix-sdk & matrix-sdk-base: PR #3741
• [x] Support for sending beacon events in the matrix-sdk crate: PR #3771
• [x] Refactor beacon_info tests so they are in their own folder: PR #3794

In progress:

• [ ] Process incoming beacon events and associate them with their referenced beacon_info

Remaining Tasks:

• [ ] Handle cases where beacon events arrive before their associated beacon_info events
• [ ] Provide a stream for the client to listen to new live location shares
• [ ] Add support for the timeline
• [ ] Add support for FFI bindings

Questions

1. I’m currently working on the logic for processing incoming beacon events and associating them with their referenced beacon_info. Where should this logic be implemented? I assume it will require a lookup for the existing beacon_info in BaseRoomInfo.

Additional Context

The following ideas were suggested by @bnjbvr and should be integrated into the tasks above to improve the ergonomics of working with beacons:

• Provide a stream to listen to new live location shares (client-wide).
• For each live location share, offer a stream to listen to new beacon events and receive updates about the beacon_info itself (e.g., stopped, redacted, etc.).

[bnjbvr]

Thanks for opening an issue!

I’m currently working on the logic for processing incoming beacon events and associating them with their referenced beacon_info. Where should this logic be implemented? I assume it will require a lookup for the existing beacon_info in BaseRoomInfo.

This could be a new method on the Room object, that returns a pair of a JoinHandle to a task listening to events, gathering them into some coherent API object that's more pleasant to use (from the event cache if enabled, or sync via event handlers otherwise), and another stream of those API objects / something that gets notified or sends the new beacon updates. That way, it's the caller's responsibility to put the task somewhere and do something with it, which is kind of nice as it doesn't store any processing logic in the Room. Does it make sense?