MSCXXXX: Sharing ephemeral streams of location data

Author: stefanceriu

proposals/XXXX-ephemeral-location-streaming.md

@@ -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
+        }
+    }
+}
+```
+
+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)?
+
+The relation to the original `m.beacon_info` event is not required as all live
+location beacons should display all available data, either grouped by user or not.
+
+
+```json5
+{
+	"m.location": {
+		"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?
+
+## Encryption
+
+XXX: split out into different MSC?
+
+XXX: use `rooms/{roomId}/ephemeral/m.room.encrypted` instead?
+
+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
+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.
+
+## 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.