Use Matrix as transport for position updates

[vranki]

You could consider using Matrix (https://matrix.org/) as transport for position data. I've been planning to do app like this for some time.

Matrix can share arbitrary json data and there is SDK for Android that can be used for the hard stuff.

It has already location message specified, but no client AFAIK uses it yet: https://matrix.org/docs/spec/client_server/latest#m-location

Things needed for minimal viable product:

1. Login to Matrix
2. Choose rooms which to publish location
3. Send (and receive) m.location messages.

This way you don't need a specific server for Hauk. You can use any Matrix server (including self-hosted) and existing accounts.

[bilde2910]

Hi, thanks for the suggestion! I've never worked with Matrix before, so I will need some time to look into whether this is feasible to implement. I can't promise any ETAs on this one.

[bilde2910]

I've tested this a little now against the matrix.org instance, and it seems like popular clients (at least riot.im) does not support showing location data at this point:

I assume that I'd also need to implement a location viewer in Hauk for this to work optimally.

The other issue to consider is that each instant message is a message on its own even if it contains location data. This means that as people start sharing their locations from Hauk in a Matrix channel every X seconds, there will be a relentless amount of spam in that channel to people using a client which doesn't render the location and instead posts the message body as a standard text IM instead. Essentially one text message every second (or whichever interval period) that does not contain any meaningful data to incompatible clients.

I'm not sure how well Matrix really works for this kind of real-time location sharing. I feel like the m.location type was created to share a single static location instead of a stream of data.

m.location also has no obvious way to pass along speed and accuracy metadata, which would degrade the viewer experience. I could of course implement my own type, but then all bets are off as for adoption by other clients.

This is possible to implement, but I'm questioning the value that it would really provide over using the Hauk backend which is built for this purpose, and I feel it may cause more bad than good given the potential for this to spam a channel to the point it and its history becomes virtually unusable.

[vranki]

Riot doesn't show location, at least yet but it can be implemented in Riot or any other client. You could also use a bot to share the location data to a web based map or a custom client.

I'd see this could work in 2 ways:

• Share location once as a message with link to map service such as OSM or Google Maps (would work on any Matrix client)
• Share location stream as m.location so that it can be displayed or logged with custom client.

Do you have any .apk with Matrix support available? I'd be interested to try it out and perhaps write a small client that could show a map with m.location updates in real time.

Looks like you already found https://github.com/vector-im/riot-android/issues/1199 - so there is pressure to get some proper location based stuff to Matrix and Hauk could be a good start.

This Half-shot's old map implementation used Leaflet library, it might be an easy way for web based map https://github.com/matrix-org/matrix-react-sdk/pull/596

[bilde2910]

Share location once as a message with link to map service such as OSM or Google Maps (would work on any Matrix client)

This is out of scope for Hauk, as Hauk is meant to be a streaming location source rather than a single static location source. It would be better for clients to implement this on top of m.location since that appears to be the intended usage for that type. Getting the current location and sharing it to Matrix should be trivial to implement by clients - implementing a viewer is really the more challenging part.

Share location stream as m.location so that it can be displayed or logged with custom client.

This is what Hauk would do in this case. I'm wondering if it's possible to use an "edit" function to try to avoid channel spam. I.e. riot.im uses m.relates_to and m.new_content to update a message (this does send a new message behind the scenes). But I don't know how well it works for other clients. I'd have to play around with it.

Another option is support within the Matrix protocol itself. Either a message type which contains metadata only and doesn't render a message in incompatible clients, or a formal standard to edit and update a message, as the riot.im way isn't standardized.

I don't have an .apk for you to test currently, as I'm holding off with implementing this until I know what the proper way to implement this would be.

[RuralYak]

Don`t get me as moaning, but take a look at Riot issues backlog and mean time to resolve of them. This could turn in a loooong story

[SanskritFritz]

A similar solution exists implemented as a Telegram client: https://osmand.net/blog/osmand-telegram-released Compared to Hauk it is clumsy in my opinion and the Android client drains the battery significantly.

[vranki]

I have coded a location bot that solves the egg part in chicken and egg problem. Now if we had Matrix support in Hauk we could send m.location messages and the bot could translate them to text/OSM links. I could add some kind of rate limiting if needed so that rooms are not spammed if someone keeps sending updates. https://github.com/vranki/malobot

[natrius]

Just a reminder: There is an issue at the riot github https://github.com/vector-im/riot-android/issues/1199

May want to get there and upvote.

[bilde2910]

Just chipping in again because it's been a little while since I responded here.

I want Matrix to have some form of real-time location sharing option. And as much as I want it, I just can't see a good way to implement this in Hauk now. My reasoning boils down to how the Hauk protocol would best be encapsulated in the Matrix protocol. Currently, Hauk uses HTTP(S) as its transport protocol. It implements its own packet based system on top of it. The Hauk data stream is one-to-one (client to server) and will never be seen by third parties which don't understand the Hauk protocol natively. As such, I'm able to add and change things at will in the protocol because it only affects clients which explicitly it (i.e. the official app and backend).

Matrix is a different beast. I have two ways to implement it and there are major downsides to both:

1. Using the Matrix protocol at the application layer. This means directly sending m.location packets with geo-coded coordinates to a channel. This will be the most "compatible" approach - currently no clients seem to support m.location packets, but if (when) live location support is added to clients, it will be m.location because it's part of the official Matrix spec. However, using Matrix at the application layer is problematic because the protocol would be stripped down to only location updates, and would not work with things like password-based end-to-end encryption. Hauk users would be at the mercy of Matrix to handle encryption within its protocol, and setting a password would not be possible at all.

2. Using the Matrix protocol at the transport layer. This means implementing a custom Matrix packet that contains the payload data structured according to the Hauk protocol. In essence, the Hauk packets are wrapped directly into Matrix packets the same way they're wrapped directly into HTTP now. This has the advantage that all Hauk-specific metadata and functionality will remain intact, however other clients will most likely never add support for this custom message format. Additionally, the messages require some form of fallback text field that is displayed in all clients not supporting this format.

I want this to happen, but I don't see how it would fit cleanly into Hauk. I'd much rather see official support for streaming m.location officially in vector-im/riot-android#1199.