This should probably be resolved before we enter FCP.

FWIW, I don't think description needs to be localised. If we have some common descriptions that clients can display in the user's native language, maybe we can add an extra field that has a machine-readable identifier (e.g. m.destination).

It's unclear whether this MSC is trying to define m.ts. This line says it's a "hypothetical" type, but the "Unstable prefix" part seems to indicate that when this MSC lands, then m.ts will be an official type.

If it is trying to define m.ts, then it should indicate whether it is only intended for use in conjunction with m.location, or of not, how it would be interpreted when there is no m.location.

Alternatively, it might be clearer to just add a ts field under the m.location section, as in:

"m.location": {
  "uri": "geo:51.5008,0.1247;u=35",
  "description": "Our destination",
  "ts": 1234567890
},

It's trying to define an actual m.ts mixin that gives the timestamp that a given event describes (which is obviously totally unrelated to origin_server_ts). Such a field is not remotely specific to location data, but any kind of data.

If it's trying to define m.ts, then can the wording be changed so that it sounds like it's doing so? e.g. "... one would add another subtype, m.ts, to spell out the exact time ..."

Also, if we're defining a generic mixin here that could be used for other events, it opens up the question of whether just a single timestamp is sufficient, or whether we need to worry about things like allowing for a range of times, or specifying precision. I don't think it's a blocking concern, as we could always define a new mixin to handle those things, though it would kind of suck to have multiple time-related things.

We've found performance issues with using dynamic map tiles in the room timeline on Element Android and have resorted to static raster images images there. This is another URL endpoint though (https://api.maptiler.com/maps/basic/static/...). We should add a dedicated property for this:

"m.tile_server": { 
    "map_style_url": "...",
    "static_tile_base_url": "https://api.maptiler.com/maps/basic/static"

Clients should be advised to use the tile variant that works best for their specific conditions.

showing descriptions like this one don't seem to be implemented yet, at least i can not get it to show descriptions for pin locations on web and android. i'm not confident to draw conclusions about ios from looking at the code and don't have a device to test.

nor can i get the body field of the legacy version in 1.6 to work for that matter.

It looks like this hasn't been updated to the latest version of extensible events. Is there a reason it hasn't been updated with the rest of the other MSCs?

Element clients use m.pin for locations that are selected by the user on a map and I couldn't find it defined anywhere. should it also be defined in this MSC?

I think it would be clearer to mention both event type and respective content block, to use MSC1767 terminology (which might have only been introduced after writing this, not sure).

I think it would make more sense to treat all of missing, invalid, unknown as generic marker, avoiding all off these complications. If a user's location was shared as generic pin, that would be less confusing UX compared to an intended-generic pin being shown as user location.

This is not needed assuming extensible events proper only land in a new room version.