sendMatrixLocation sends a single static m.location. There is no live location -
nothing handles m.beacon_info or m.beacon.
Live location is the half people actually use: share for an hour while on the way
somewhere, and let it update. Here a shared location is a pin dropped once, and a live
share started in Element appears as a single event that never moves.
`sendMatrixLocation` sends a single static `m.location`. There is no live location -
nothing handles `m.beacon_info` or `m.beacon`.
Live location is the half people actually use: share for an hour while on the way
somewhere, and let it update. Here a shared location is a pin dropped once, and a live
share started in Element appears as a single event that never moves.
Live location is a phone feature. The thing it does is share a position that is moving - on the way somewhere, for the next hour - and moho is a desktop client,
where the answer is the same room it was in when the share started.
The sending half could not be built honestly here anyway. moho has no location source
at all: sending a place is a typed or pasted link, and PlaceField.tsx records that the
map picker was refused on purpose, because drawing one means fetching tiles from
somebody's server and "a message that mentions a street corner should not tell a third
party it was read". Adding geolocation to satisfy this would undo a privacy decision
already made, for a feature whose value is in being carried around.
The receiving half was considered separately - showing a beacon somebody shares from
Element on their phone - and is not wanted either.
Nothing is lost for the case a desktop actually has. Static locations already work in
both directions: m.location is rendered on receive, and sendMatrixLocation sends one
(#123), from a pasted map link, a geo: URI or a pair of coordinates.
Reopen if moho ever runs somewhere that moves.
Closing as won't implement.
Live location is a phone feature. The thing it does is share a position that is
*moving* - on the way somewhere, for the next hour - and moho is a desktop client,
where the answer is the same room it was in when the share started.
The sending half could not be built honestly here anyway. moho has no location source
at all: sending a place is a typed or pasted link, and `PlaceField.tsx` records that the
map picker was refused on purpose, because drawing one means fetching tiles from
somebody's server and "a message that mentions a street corner should not tell a third
party it was read". Adding geolocation to satisfy this would undo a privacy decision
already made, for a feature whose value is in being carried around.
The receiving half was considered separately - showing a beacon somebody shares from
Element on their phone - and is not wanted either.
Nothing is lost for the case a desktop actually has. Static locations already work in
both directions: `m.location` is rendered on receive, and `sendMatrixLocation` sends one
(#123), from a pasted map link, a `geo:` URI or a pair of coordinates.
Reopen if moho ever runs somewhere that moves.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
sendMatrixLocationsends a single staticm.location. There is no live location -nothing handles
m.beacon_infoorm.beacon.Live location is the half people actually use: share for an hour while on the way
somewhere, and let it update. Here a shared location is a pin dropped once, and a live
share started in Element appears as a single event that never moves.
Closing as won't implement.
Live location is a phone feature. The thing it does is share a position that is
moving - on the way somewhere, for the next hour - and moho is a desktop client,
where the answer is the same room it was in when the share started.
The sending half could not be built honestly here anyway. moho has no location source
at all: sending a place is a typed or pasted link, and
PlaceField.tsxrecords that themap picker was refused on purpose, because drawing one means fetching tiles from
somebody's server and "a message that mentions a street corner should not tell a third
party it was read". Adding geolocation to satisfy this would undo a privacy decision
already made, for a feature whose value is in being carried around.
The receiving half was considered separately - showing a beacon somebody shares from
Element on their phone - and is not wanted either.
Nothing is lost for the case a desktop actually has. Static locations already work in
both directions:
m.locationis rendered on receive, andsendMatrixLocationsends one(#123), from a pasted map link, a
geo:URI or a pair of coordinates.Reopen if moho ever runs somewhere that moves.