MSC3489: Sharing streams of location data with history #3489
Conversation
|
Looks good, but I don't like this part: "m.beacon.* events should be sent every 2 seconds while the location of the asset is moving. If the asset is not moving, it should be refreshed every 30 seconds." The location data can come from another source via bridge or bot and this data source may have it's own update interval. Also the practical update rate depends on application. Some applications may need 2 seconds, but some may be happy with 60 secs or even longer. An application may choose use smart algorithm that calculates error between true location and location extrapolated from velocity vector and updates only if it grows high enough. I'd change this to recommendation, although 2 secs is quite high rate, even for moving cars or people being followed live on map. Maybe there should also be a field for maximum time of next update. If the update isn't sent before this, the recipient can assume that sender was unable to send update for some reason. |
relax rate requirements spell out that we're ignoring velocity for now
|
feedback incorporated - thank you. (please always provide feedback by commenting on the relevant line of the PR, or the heading if there isn't a specific relevant line, so that we can track the feedback & resolve it as a thread, until github finally implements threaded comments...) |
|
Sneaking in a little note here that another alternative could be done with a combination of MSC2477 and a slower rate of state events as in here for the "breadcrumb trail" - even described that particular use-case as an example in the proposal there. Something much like this (like Telegram's live location) was one of the original thoughts for a use-case when I first wrote that proposal after all. |
turt2live
added
client-server
* Various tweaks following initial implementation: - switched from `m.beacon.*` state event to `m.becon` reference relationship to original `m.beacon_info.*` - changed `beacon_info` created to `m.ts` - renamed `lifetime` to `timeout` - added `m.asset` `type`
ara4n
changed the title
* Clarify that this proposal includes history - see MSC3672 for EDUs * Note dependency on MSC3267 for reference relationships * Remove variable event_type - instead use state_key * Propose state_key prefixes inspired by MSC3757 and MSC3779 * Update links to matrix-spec-proposals * Clarify how to stop sharing, and when a share is stopped * Mention the need for redactions to work * Clarify the use of milliseconds for all timing * Mention implementations
| events will automatically have permission to share their live location, because | ||
| the `state_key` matches the pattern required to be an "owned" state event. | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
There is another alternative that appears not to have been discussed yet, although the idea is quite obvious:
Instead of introducing a new event m.beacon that for the most part duplicates an MSC3488 m.location:
- use
m.location - when used for location streams (i.e. in this context and MSC3672), require the
m.relates_tomixin to be set
Pros compared to the MSC as it currently is:
- automatic fallback for clients that support static
m.location - further fallback to
m.text
Cons:
- this could result in clients without live location support having their timelines spammed. while one could still view the movement trail similar to the original intention, this might be considered undesireable
| `description` is the same as an `m.location` description | ||
| ([MSC3488](https://github.com/matrix-org/matrix-spec-proposals/pull/3488)). | ||
|
|
||
| `live` should be true when a user starts sharing location. |
There was a problem hiding this comment.
When live is false, m.ts and timeout become meaningless, right? So those fields are optional?
If they are, couldn’t we get rid of live and say that the location sharing is live when both m.ts and timeout are present and the timeout is not reached?
There was a problem hiding this comment.
Could these still be relevant for displaying clients to visualize the time interval during which location has been shared? I guess they could also use the m.ts fields from the first and last m.beacon event for the same purpose. So maybe that's irrelevant. 🤔
In which we introduce
m.beacon_info.*andm.beacon.*events for streaming location data, building on MSC3488.Rendered
Matrix React SDK implementation
https://github.com/matrix-org/matrix-react-sdk/tree/develop/src/components/views/location
Element Android implementation
https://github.com/vector-im/element-android/tree/develop/vector/src/main/java/im/vector/app/features/location
Matrix iOS SDK implementation
https://github.com/matrix-org/matrix-ios-sdk/tree/develop/MatrixSDK/LocationSharing
Preview: https://pr3489--matrix-org-previews.netlify.app