Sharing location to people who don't have OwnTracks

[jpmens]

Feedback request: Is it worth investing time in this enhancement?

We've had a request to be able to share with people who don't have OwnTracks a live map of a location of a device, maybe on a time-limited basis. In order to do this, the clients (Android & iOS) would have a new "share" function in which a user could request they share their location for a specific duration (from time, to time). The OwnTracks Recorder would create a view from this "share request" and return a unique URL to the client. The client could then share this URL with whomever they wish, and the recipient could henceforth visit the map at the URL at least until the share request expires.

Share requests could be created with MQTT and HTTP, and the resulting URL would be viewable via HTTP only, providing that the owner's Recorder is publicly accessible over HTTP(S).

Is this something you consider worthwhile us doing, and would you actually use such a feature? Do you currently operate your Recorder on a publicly accessible IP address (i.e. is your Recorder accessible from the Internet)?

[lostfocus]

I'm not using the recorder app but using my own (rather primitive) PHP code. If the client app had the feature, I'd add that to my server code as well.
It's not something I deeply miss, though.
(This is just a data point. Not sure if it helps your decision in one way or another.)

[jpmens]

Any feedback helps us, @lostfocus, so thank you. If we do roll this then the interface will be documented so there'd be no reason for other backends to not profit from the feature.

[atjn]

I used this feature often before switching to OwnTracks, and would love to have it again!

I am however unsure if I would be able to use it. It was very complicated for me to set up the recorder as it is today, and requiring it to be accessible from an HTTPS domain makes the setup even more complex. Even if I was able to set it up, I would not be confident that it was properly secured, and thus would probably choose not to do it.

[jpmens]

Thank you, @atjn, that's a valid point.

One of the disadvantages of OwnTracks and its tools is that people have to do everything themselves. When we created OwnTracks we realized it would be quite hard to do for many, but we believe it's one of the great benefits of OwnTracks: you are sure what happens with your data.

If we do this particular feature we will pay very specific attention to its documentation.

[jpmens]

So, as a bit of a teaser, here's the initial "documentation" of what we might be doing. The Recorder already has support for this on the master branch, and @ckrey is busy implementing it on our iOS app.

DRAFT

Location Sharing

You might occasionally wish to share your location with somebody who doesn't have OwnTracks. For these situations you can set up what we call a Tour -- a time-limited view of your location which can be viewed from a Web browser.

The OwnTracks Recorder gets a request for a Tour as a JSON published to the ../request subtopic or POSTed to the HTTP endpoint:

{                                                                                                                
  "_type": "request",                                                                                            
  "request": "tour",                                                                                             
  "tour": {                                                                                                      
    "label": "Meeting with C. in Essen",                                                                         
    "from": "2022-08-01T05:35:58",                                                                               
    "to": "2022-08-02T15:00:58"                                                                                  
  }                                                                                                              
} 

The Recorder creates a View from this and returns a unique URL to this View which you can share with anybody you want to.

{
  "_type": "cmd",
  "action": "response",
  "request": "tour",
  "status": 200,
  "tour": {
       "label": "Meeting with C. in Essen",
       "from": "2022-08-01T05:35:58",
       "to": "2022-08-02T15:00:58",
       "uuid": "7fc09e95-0082-4f2e-b3ee-bd68e39a39fe",
       "url": "http://localhost:8085/view/7fc09e95-0082-4f2e-b3ee-bd68e39a39fe"
}

Your last location is marked on this View's map with a red dot and the track of your movements between the from and to times can be loaded. The important bit: the visitor of the unique URL will not see your location prior to the specified from time nor after the to time. It is also possible to completely delete the Tour in which case a user attempting to access it would get a 404 Not Found. Tours can outlive the to field if you want to, say, provide a historic map of where you once were (i.e. My 2019 vacation on Mallorca).

An authorized client may also request a list of current Tours with this JSON:

{
  "_type": "request",
  "request": "tours"
}

whereupon an array of existing Tours and their unique URLs is returned:

{
 "_type": "cmd",
 "action": "response",
 "request": "tours",
 "tours": [
  {
   "label": "Meeting with C. in Essen",
   "from": "2022-08-01T05:35:58",
   "to": "2022-08-02T15:00:58",
   "uuid": "0a721022-c54a-49a4-9f5a-f1a76dd92e9e",
   "url": "http://localhost:8085/view/0a721022-c54a-49a4-9f5a-f1a76dd92e9e"
  }
 ],
 "ntours": 1
}

Only Tours which have been created by a user for their specific device will be enumerated in the Tours list.

Tours can be "un-toured" (i.e. deleted) with this payload:

{
  "_type": "request",
  "request": "untour",
  "uuid": "0a721022-c54a-49a4-9f5a-f1a76dd92e9e"
}

For Tours to work, the Recorder needs to be compiled with support for HTTP and TOURS, and the following settings need defining:

• OTR_HTTPPREFIX must be configured to contain the URL to the Recorder as seen from "outside", i.e. from the Internet. This setting is used to construct the unique URL which will be returned for a Tour. So, if you have, say, a Recorder behind an NGINX proxy (as described in our README), then the setting would say

  export OTR_HTTPPREFIX="https://example.net/owntracks"

  on the other hand, if you're testing internally and your Recorder is listening on port 8085, you might do this:

  export OTR_HTTPPREFIX="http://localhost:8085"

[jpmens]

Initially we thought the term "share" would be good but then decided it's a too ambiguous word, and we didn't want to run into the mess we created with mixing terms (remember region and waypoint? :-) ). After a bit of pondering we think the word tour as in ("I did a tour last year I want to show you") or as in ("I am now on tour") is adequate.

Speak now or forever hold your peace. 😄

[lostfocus]

Oh, I like it a lot! And naming things is always hard - tour sounds like a good term for the feature.

[atjn]

I think it looks great! Including the name :)

If I understand it correctly, each tour is only accessible from the HTTPS address and nowhere else?
I am asking because I think it could be nice to be able to save them for later ease-of-finding in the app or in a separate "tours" app. But I understand that it might be a lot of work for a minor usability improvement. Maybe the tradeoff could be that each HTTPS tour link can be installed as a separate web app? That would allow the user to save tours on their home screen, and even group them into separate folders if they'd like.

[jpmens]

The idea is you (as user of an OwnTracks app) can obtain a list of your tours from within the App. For each one individually, you can chose to share the URL to the tour with somebody (e.g. send via email, paste on Signal, etc.). You can add tours, delete them at will, and always re-share existing tours with new people, say, by re-copying the URL of that one particular tour.

[jpmens]

If I understand it correctly, each tour is only accessible from the HTTPS address and nowhere else?

This is basically correct, though to be clear, it might be HTTP (no TLS) if you so desire. The person operating the Recorder decides at which URL their tours are made available. So I would do https://example.com/my-recorder and you might use https://my.example.net/. In either case, the full URL will become that prefix plus /view/<uuid> (a UUID).

https://example.com/my-recorder/view/a3fad3db-1372-4109-ba12-d1202886a31
https://my.example.net/view/78b6bf86-184a-4176-af21-2717a3ecaf5d

[ckrey]

here's the tour list as shown from within the iOS app (preview)

here's a user describing a new tour on iOS (preview)

When a tour is newly described (i.e. entered) and when a tour is tapped on from the list, the URL to the tour is copied to the clipboard from where it can be shared. Alternatively the URL can directly be opened in your Browser and shared from there.

[atjn]

Thank you for the details, that looks very usable!

I still think that having the tour websites installable could be helpful to the receiver, since I assume that you cannot add other people's tours to the list of tours in your app. I can submit a PR to make them installable if you'd like :)

[jpmens]

@atjn care to explain what you mean by "installable" in as much as being more than putting a bookmark into the browser or (on iOS) installing the page on the Home Screen?

[atjn]

By adding a serviceworker, to the tour "website", you can make it run as if it was a natively installed app (it can work offline, you can version it and send packaged updates to existing installs). If you set it up correctly, most browsers will let the user "install" the app, which is a lot like adding a browser bookmark to the home screen, but the bookmark will look and behave exactly as if it was a natively installed app or program.

Twitter uses this for their web app, if you want to try it out for yourself. It is best supported in Chrome/Edge.

[jpmens]

Thanks for elaborating, @atjn. Serviceworker sounds like a bit too much of what we need for this particular use-case, but I suggest we wait a bit until first users (including yourself, I hope) experience what it's like and we can then always revisit.

[atjn]

Sure, we can definitely wait :)
Just to be clear, the serviceworker can be set up to be 99% autonomous, which means it won't require a build step, and you won't need to worry about it when you are making changes to the rest of the code.

[jpmens]

We have released OwnTracks Recorder version 0.9.1 with support for Tours. Docker image and Debian/Raspian packages are also available.

[jpmens]

Closing this as mostly implemented. Tours are documented, and implementation for Android is being tracked.