-
Notifications
You must be signed in to change notification settings - Fork 383
Commit
- Loading branch information
There are no files selected for viewing
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.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong. |
||
} | ||
} | ||
} | ||
``` | ||
|
||
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.
Sorry, something went wrong. |
||
|
||
The relation to the original `m.beacon_info` event is not required as all live | ||
This comment has been minimized.
Sorry, something went wrong.
ara4n
Member
|
||
location beacons should display all available data, either grouped by user or not. | ||
|
||
|
||
```json5 | ||
{ | ||
"m.location": { | ||
This comment has been minimized.
Sorry, something went wrong.
ara4n
Member
|
||
"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.
Sorry, something went wrong.
ara4n
Member
|
||
|
||
## Encryption | ||
|
||
XXX: split out into different MSC? | ||
This comment has been minimized.
Sorry, something went wrong. |
||
|
||
XXX: use `rooms/{roomId}/ephemeral/m.room.encrypted` instead? | ||
This comment has been minimized.
Sorry, something went wrong.
ara4n
Member
|
||
|
||
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.
Sorry, something went wrong.
ara4n
Member
|
||
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.
Sorry, something went wrong.
ara4n
Member
|
||
|
||
## 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. |
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 alongsidedescription
andtimeout
; simplylive: true/false
.