Skip to content

Commit

Permalink
MSCXXXX: Sharing ephemeral streams of location data
Browse files Browse the repository at this point in the history
  • Loading branch information
stefanceriu committed Jan 21, 2022
1 parent 4a597ac commit ca8a3fd
Showing 1 changed file with 106 additions and 0 deletions.
106 changes: 106 additions & 0 deletions proposals/XXXX-ephemeral-location-streaming.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,106 @@
# MSCXXXX - Sharing ephemeral streams of location data

## Problem

[MSC3489](https://github.com/matrix-org/matrix-doc/blob/matthew/location-streaming/proposals/3489-location-streaming.md)
focuses on streaming persistent location data for applications that require
historical knowledge.

We also need the ability to share this data in a non-persistent way for cases in
which privacy is a concern, like user locations.

## Proposal

This MSC adds the ability to publish short-lived location beacons through the
the use of custom Ephemeral Data Units (EDUs) by building on top of [MSC2476](https://github.com/ananace/matrix-doc/blob/user-defined-edus/proposals/2477-user-defined-ephemeral-events.md).

In order to do so we will first start by introducing a new asset type on
`m.beacon_info` called `m.self.live` which will mark the start of an user's
intent to share ephemeral location information.

```json5
{
"type": "m.beacon_info.@stefan:matrix.org",
"state_key": "@stefan:matrix.org",
"content": {
"m.beacon_info": {
"description": "Stefan's live location",
"timeout": 600000, // how long from the last event until we consider the beacon inactive in milliseconds
},
"m.ts": 1436829458432, // creation timestamp of the beacon on the client
"m.asset": {
"type": "m.self.live" // Live user location tracking

This comment has been minimized.

Copy link
@ara4n

ara4n Jan 21, 2022

Member

While I really like the idea of using asset in general for distinguishing different types of assets (is it a human? is it a parcel? is it the user? is it a thunderstorm?) i have a feeling that the question of whether the beacon emits live EDUs or not is orthogonal to the type of asset that the beacon describes however: any asset class can emit live loc data.

So i suspect the correct semantic place for this would be on the m.beacon_info mixin alongside description and timeout; simply live: true/false.

This comment has been minimized.

Copy link
@stefanceriu

stefanceriu Jan 25, 2022

Author Member

Yes, you're right, definitely a better solution πŸ‘

}
}
}
```

We define a new asset type as opposed to using the existing `m.self` to allow
clients to distinguish between location types without potentially overwriting
static ones.

Multiple live beacons on the same timeline should behave similarly and aggregate
all available location EDUs.

Subsequently clients will start sending beacon data EDUs to the new
`rooms/{roomId}/ephemeral/{eventType}` endpoint where `eventType` equals
`m.beacon` with the same location payload as defined in [MSC3489](https://github.com/matrix-org/matrix-doc/blob/matthew/location-streaming/proposals/3489-location-streaming.md).

XXX: Why do we need a `{txnId}` after `{eventType}` in [MSC2476](https://github.com/ananace/matrix-doc/blob/user-defined-edus/proposals/2477-user-defined-ephemeral-events.md#addition-of-an-ephemeral-event-sending-endpoint-to-the-client-server-api)?

This comment has been minimized.

Copy link
@ara4n

ara4n Jan 21, 2022

Member

for idempotency


The relation to the original `m.beacon_info` event is not required as all live

This comment has been minimized.

Copy link
@ara4n

ara4n Jan 21, 2022

Member

are you sure? surely we need to know which of the various beacons in the room the EDU refers to, so we can move the right dot around on the map.

This comment has been minimized.

Copy link
@stefanceriu

stefanceriu Jan 25, 2022

Author Member

Now that I think about it again no, that's not right. I was thinking that locations could be aggregated through the sender and type keys coming back in ephemeral but that's not enough. We would still need a relationship to the original beacon to get the asset type too. Will remove.

location beacons should display all available data, either grouped by user or not.


```json5
{
"m.location": {

This comment has been minimized.

Copy link
@ara4n

ara4n Jan 21, 2022

Member

One thing we might want to consider is including a message ID in the EDU (if only to aid with tracing when debugging). Alternatively we could cheat and stalk based on m.ts + beacon ID, i guess...

This comment has been minimized.

Copy link
@stefanceriu

stefanceriu Jan 25, 2022

Author Member

I wonder if we could use the transaction id we pass to the ephemeral endpoint for that (although it doesn't seem to come back in /sync) πŸ€”

This comment has been minimized.

Copy link
@ara4n

ara4n Jan 25, 2022

Member

yeah, the txnid isn't used like that currently (and isn't globally unique).

"uri": "geo:51.5008,0.1247;u=35",
"description": "Arbitrary beacon information"
},
"m.ts": 1636829458432,
}
```

These will reach clients through `/sync`s `ephemeral` dictionary with the same
payload but with the addition of a `sender` which the clients can aggregate user
locations on.

XXX: Do we need a "user stopped sharing live location" event or is the
`m.beacon_info` `timeout` sufficient?

This comment has been minimized.

Copy link
@ara4n

ara4n Jan 21, 2022

Member

relying on the timeout would be ugly. but can we remove the beacon_info event when we stop broadcasting? (the same thing applies to #3489)

This comment has been minimized.

Copy link
@stefanceriu

stefanceriu Jan 25, 2022

Author Member

Don't we want to preserve the original m.beacon_info details? Shouldn't we display that the user has at some point started sharing their live location and that has now finished, without it appearing as redacted?

This comment has been minimized.

Copy link
@ara4n

ara4n Jan 25, 2022

Member

it wouldn't be redacted; it'd still be in history. but we need some way to say that we've explicitly stopped broadcasting rather than timing out. could be live: false rather than replacing it with {}?


## Encryption

XXX: split out into different MSC?

This comment has been minimized.

Copy link
@ara4n

ara4n Jan 21, 2022

Member

yeah, we should put this in a separate MSC.


XXX: use `rooms/{roomId}/ephemeral/m.room.encrypted` instead?

This comment has been minimized.

Copy link
@ara4n

ara4n Jan 21, 2022

Member

yup, the event type should absolutely be m.room.encrypted, just like for timeline events.


E2E encryption for EDUs isn't currently defined but as we're dealing with
privacy sensitive data we propose to wrap them inside the standard encryption

This comment has been minimized.

Copy link
@ara4n

ara4n Jan 21, 2022

Member

should spell out for completeness that this means sending the megolm keys required to decrypt the EDUs over olm just as we'd do for encrypted timeline events.

envelope:

```json5
{
"algorithm": "m.megolm.v1.aes-sha2",
"sender_key": "<sender_curve25519_key>",
"device_id": "<sender_device_id>",
"session_id": "<outbound_group_session_id>",
"ciphertext": "<encrypted_payload_base_64>"
}
```

in which the `ciphertext` will contain the `m.beacon` payload defined above and
which will similarly be sent to `rooms/{roomId}/ephemeral/m.beacon`


## Alternatives

No alternatives for sending custom ephemeral data are known at this point.

This comment has been minimized.

Copy link
@ara4n

ara4n Jan 21, 2022

Member

Streaming over WebRTC datachannels is the obvious alternative, which can be migrated over from #3489. I don't think this is the right baseline solution though because it would be useful to support plain vanilla HTTP like the rest of Matrix, especially for dumb beacons which have no WebRTC, rather than unnecessarily depending on WebRTC. Someone can always propose WebRTC as a future MSC.


## Unstable prefix

* `m.beacon_info.*` should be referred to as `org.matrix.msc3489.beacon_info.*` until this MSC lands.
* `m.beacon` should be referred to as `org.matrix.msc3489.beacon` until this MSC lands.
* `m.location` should be referred to as `org.matrix.msc3488.location.*` until MSC3488 lands.
* `m.ts` should be referred to as `org.matrix.msc3488.ts.*` until MSC3488 lands.
* `m.asset` should be referred to as `org.matrix.msc3488.asset.*` until MSC3488 lands.

0 comments on commit ca8a3fd

Please sign in to comment.