MSC3488: Extending events with location data
parent
1ad5ff4179
commit
33fbe8ccac
@ -0,0 +1,103 @@
|
|||||||
|
# MSC3488 - m.location: Extending events with location data
|
||||||
|
|
||||||
|
## Problem
|
||||||
|
|
||||||
|
We need a standard way to share location data about events in Matrix. Use
|
||||||
|
cases include sharing freeform static location info, sharing live-updating
|
||||||
|
location data of assets, associating location data with IOT telemetry, etc.
|
||||||
|
|
||||||
|
The spec currently has the concept of an `m.location` `msgtype` on
|
||||||
|
`m.room.message` events, but this is very limiting as it only applies to
|
||||||
|
sharing location as an instant message. Instead, we'd like to leverage
|
||||||
|
extensible events (MSC1767) to associate location data with any kind of
|
||||||
|
event.
|
||||||
|
|
||||||
|
## Proposal
|
||||||
|
|
||||||
|
We introduce `m.location` as an extensible event type: a key which can be
|
||||||
|
placed in the `content` of any event to associate a location object with the
|
||||||
|
other data (if any) in that event. Clients which are location-aware may
|
||||||
|
let the user view events containing `m.location` on a map.
|
||||||
|
|
||||||
|
This is intended to eventually replace the `m.location` msgtype (although this
|
||||||
|
MSC doesn't obsolete it)
|
||||||
|
|
||||||
|
The `m.location` object must contain a `uri` field with a standard RFC5870
|
||||||
|
`geo:` URI. It may also contain an optional `description` field, giving a
|
||||||
|
free-form label that should be used to label this location on a map. This is
|
||||||
|
not to be confused with fallback text representations of the event, which are
|
||||||
|
given by `m.text` or `m.html` as per MSC1767. The description field is also
|
||||||
|
not intended to include semantic descriptions of the location (e.g. the
|
||||||
|
details of a calendar invite), which should be stored in their respective
|
||||||
|
extensible event types when available.
|
||||||
|
|
||||||
|
XXX: should description be localised?
|
||||||
|
|
||||||
|
```json
|
||||||
|
"m.location": {
|
||||||
|
"uri": "geo:51.5008,0.1247;u=35",
|
||||||
|
"description": "Our destination",
|
||||||
|
},
|
||||||
|
```
|
||||||
|
|
||||||
|
If sharing the location of an object, one would add another subtype (e.g. a
|
||||||
|
hypothetical `m.asset` type) to give the object a type and ID.
|
||||||
|
|
||||||
|
If sharing time-sensitive data, one would add another subtype (e.g. a
|
||||||
|
hypothetical `m.ts` type) to spell out the exact time that the data in the
|
||||||
|
event refers to (milliseconds since the UNIX epoch)
|
||||||
|
|
||||||
|
If `m.location` is used as the event type itself, it describes a contextless
|
||||||
|
static location, suitable for "drop a pin on a map" style use cases.
|
||||||
|
|
||||||
|
Example for sharing a static location:
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"type": "m.location",
|
||||||
|
"content": {
|
||||||
|
"m.location": {
|
||||||
|
"uri": "geo:51.5008,0.1247;u=35",
|
||||||
|
"description": "Matthew's whereabouts",
|
||||||
|
},
|
||||||
|
"m.ts": 1636829458432,
|
||||||
|
"m.text": "Matthew was at geo:51.5008,0.1247;u=35 as of Sat Nov 13 18:50:58 2021"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Alternatives
|
||||||
|
|
||||||
|
We could use GeoJSON (RFC7946) to describe the location. However, it doesn't
|
||||||
|
support the concept of uncertainty, and is designed more for sharing map
|
||||||
|
annotations than location sharing. It would look something like this if we
|
||||||
|
used it:
|
||||||
|
|
||||||
|
```json
|
||||||
|
"m.geo": {
|
||||||
|
"type": "Point",
|
||||||
|
"coordinates": [30.0, 10.0]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Another design choice is to represent static shared locations as a normal room
|
||||||
|
event rather than a state event. The reason we've chosen non-state events is
|
||||||
|
so that the data is subject to normal history visibility: it's very much a
|
||||||
|
transient event. Just because I temporarily mention a location to someone
|
||||||
|
doesn't mean I want it pinned in the room state forever more. On the other
|
||||||
|
hand, it means that streaming location data (where you do want to keep track
|
||||||
|
of the current location in room state) ends up being a different shape, which
|
||||||
|
could be a little surprising.
|
||||||
|
|
||||||
|
## Security considerations
|
||||||
|
|
||||||
|
Geographic location data is high risk from a privacy perspective.
|
||||||
|
Clients should remind users to be careful where they send location data,
|
||||||
|
and encourage them to do so in end-to-end encrypted rooms, given the
|
||||||
|
very real risk of real-world abuse from location data.
|
||||||
|
|
||||||
|
## Unstable prefix
|
||||||
|
|
||||||
|
`m.location` used as a event type and extensible event field name should be
|
||||||
|
referred to as `org.matrix.msc3488.location` until this MSC lands.
|
||||||
|
`m.ts` should be referred to as `org.matrix.msc3488.ts` until this MSC lands.
|
Loading…
Reference in New Issue