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:

• Support for sending, stopping & updating beacon_info events in matrix-sdk & matrix-sdk-base: PR #3741
• Support for sending beacon events in the matrix-sdk crate: PR #3771
• 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?

[torrybr]

Thanks for your detailed response regarding the JoinHandle and stream for handling beacon events! I haven't worked much with JoinHandle before, so I'm trying to wrap my head around how to integrate it into the event handling logic.

I was looking at this example in pinned_events_loader.rs for guidance on using the event cache, but I'm still unsure how to combine this with your suggestion for processing events with a JoinHandle. Would you be able to provide an example or point me to another part of the codebase that demonstrates this kind of pattern?

Seeing how it's been used elsewhere would help me better understand the mechanics.

[torrybr]

Posting this snippet from Matrix Rust SDK Development chatroom which had some talk about this issue:

•	not the timeline, because it should restrict itself to being a view
•	not the event cache, to not explode its responsibilites
•	so could be either a new API object (think: like the send queue), or a method on the room that returns a task (for listening to the "pin violations", whatev that means) and a stream (…or the aforementioned API object)