Enable RSS feed for history/friends

[vincentdephily]

The http://www.openstreetmap.org/history/friends page would be much more usefull if it allowed RSS format, like http://www.openstreetmap.org/history.

Auto-discovery is disabled for the "friends" version of the page in history.html.erb. I imagine this was done because the url format didn't automatically translate to a good-looking rss url ?

[tomhughes]

No, it is disabled because it's not a stable URL as different people will get different results because it relies on you being logged in to know what to return.

So adding it to a feed reader won't do you any good because you just won't get any results as the feed reader will not be logged in when it fetches the URL.

[vincentdephily]

My feed reader is normally logged in, as it shares cookies with my browser and OSM cookies can last a while. I even read rss content that is behind a paywall from my rss reader. Not everybody is on the online rss reader bandwagon, where a "login before you can fetch rss feed" requirement is indeed a problem.

If you feel working around the not-logged-in case is a requirement, the easy way is to return a 403, or a feed with a single article pointing to the login page. Not very elegant, but gets the job done.

A nicer and still easy way of course would be to make user friends lists public, so that no login is needed. But that has privacy implications (making it opt-in could certainly alleviate that).

The last way is to use links thate aren't tied to an account, but to a list of watched users instead. http://www.openstreetmap.org/history/users/$SOMERANDOMSTRING would be the rss link, with the random string mapping to a static list of users, not the dynamic list of friends. Display a "create rss feed" button on the friends list, and you've got your UI.

You could also use a deterministic string too : serialise the array of user ids, maybe compress and b64-encode it, and voilà. Longer url, but doesn't require server-side storage and hence no akward "create feed" UI.

I use the friends list as a QA tool. Whenever I contact a mapper about a mapping issue, I add him/her to my friends list so I can see what the next changeset looks like. But having to open a specific webpage for that is a pain, so I don't do it regularly.

[vincentdephily]

Thinking about it further, the deterministic string solution sounds like it would both be simple for the user and simple to code : you just need (de)serialize_userids() functions and a hook for the feed. It even saves you a trip to the db to fetch the list of friends :p

Of course there's still the drawback that the list is static, but I feel it is acceptable, and you could reflect that in the feed name.

[danstowell]

I disagree - the deterministic string solution would be confusing, because it doesn't refer to my "real" friends-list but only to the list of friends I had at the time I added the RSS link to my feed reader. "Reflect that in the feed name" is patching over a bad issue. It would not be simple for the user, it would confuse matters.

I like the idea of providing the feed and simply providing a 403 if not logged in. Hopefully straightforward. I'm not suggesting that I or one of the core developers should do it ;)

[tomhughes]

The deterministic string solution is something of a security/privacy risk so that definitely won't be happening.

[vincentdephily]

@tomhughes How is the deterministic string a security/privacy risk ? It's basically a querystring: "give me the changesets of users foo, bar, and baz". You can already get those changesets for individual users, no extra information is exposed, it's just a nicer interface to get them. I definitely see a privacy risk with the public friends list idea, but not with this "multi-user list of changesets" idea.

@danstowell The "403" solution isn't great either: it might mess up the reader's cache, and it cannot work with online readers (such as feedly, newsblur, etc). I think having to use a static list is a lesser problem.

[tomhughes]

@vincentdephily Well if anybody gets hold of that string they have a list of your friends.

[danstowell]

The string could be replaced by a random string or opaque hash. But the usability confusability aspect is worse.

[vincentdephily]

They're not getting hold of that string unless I actively share it somewhere. I don't have any more reason to share it than I have to share a list of usernames in plaintext format. Unless some hypotetical social news reader platform is automatically sharing all my feeds, but then I've got bigger privacy issues to begin with. Joe hacker can't lookup my osm profile and extract my friends list, in string format or otherwise.

Also, it's just my "friends" list at some given point in time. If that feature was available, I'd certainly curate multiple thematic lists for myself: newbies (I might even auto-generate that one), people I've recently contacted, people that keep making mistakes, people in my area, actual friends... etc.

[vincentdephily]

@danstowell A random or opaque hash doesn't make any difference, privacy-wise. If I get hold of the link, I can follow it to see who's included.

[mmd-osm]

4590 has a similar requirement. Could be addressed by adding some token as URL parameter.