-
New Feature
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
None
Note: Core user area function is going to be implemented in MetaBrainz OAuth instead, see LB-1549.
This ticket has been adjusted to allow for a LB interface for setting additional areas (if wanted), which the mockups are still relevant for, but this shouldn't be implemented before LB-1549.
Displaying all events for artists is easy-ish (LB-1537), but if we want to display upcoming events in the user feed (LB-1351) then we need to know what events are taking place in the users area. It may come in handy for other future features as well.
This needs to be optional, and we need to let users know that this data will be public.
We could either incorporate this into the 'Timezone' settings page (maybe rename it to something like Location), or make a new 'Location' settings page.
Mockup:
The area field/search searches and correlates to the MusicBrainz area table (this is required, because then we can map MusicBrainz events to the user area).
Stretch goals (might be more suitable for a new ticket):
- It would be cool to be able to set additional/secondary areas - for instance, if someone lives in one place, but is travelling or often visits another town for work or for family, then they may want to be informed of events in that area as well. We could add a '+ add secondary area' button under the primary search field, which adds more fields.
- ?
[LB-1538] Set additional user locations/areas (e.g. for events)
i think the location info should be a an array of locations.
i live in hasselt < limburg < flanders < belgium.
belgium isn't that big so for me i would enter belgium as my location.
but since i live close to the netherlands an germany, i sometimes go to gigs over the border.
but germany is to big. i would only go to gigs in the provence next to the border.
so for me, the list of places where i would go to gigs would be:
- belgium
- limburg < netherlands
- noord-braband < netherlands
- cologne < Noordrijn-Westfalen < germany (i only add 1 city because that is the only city where i went to some gigs to because it is just within driving distance, but Noordrijn-Westfalen is to big to add as a whole)
The "additional areas" will certainly be very helpful. I haven't checked yet how this is currently managed, but it would be great to have the ability to set a radius around the area, similar to what last.fm was offering.
As in the ticket description:
This needs to be optional, and we need to let users know that this data will be public.
My personal opinion is that when we add identifying data (including optional) that we use to generate public stats or data we need to assume it will be 100% public. Partly because it's clearer, which enables users to make better decisions about their data. Partly because I don't think MetaBrainz has the security structure to make privacy guarantees once we start linking data together in complex ways.
In other words, I don't know if this will be in the API, or for listen stats by region, but I would assume that it will be.
Had a question about this recently on the IRC channel, about the user location. And the answer was it was against the privacy of users [if it was something "forced", like Spotify does ?].
If user location will be added as an opt in setting, then... will this data be used to retrieve listen stats by region?
Will user's location [area mbid] be available via API?
I know these are questions not totally related to the request, but they are related to how this data will be implemented, if ever.
Thanks shivamjha68 - I asked the main LB devs for input on that and here's lucifer's answer:
"area mbid likely, we can always cache the names in the backend if we need to speed it up."
I intend to work on this. Quick question:
Should the schema store the name locally or should it only store the mbid of the area and use the API to fetch the name of the area when it is needed?
sanojjonas that's what I was imagining as well - as far as I can tell that would already be supported by how MusicBrainz areas are set up, where there is a hierarchy (e.g. we have parent areas).