I want to be able to share my location with my friends on social media. Twitter (RIP) had a way to attach an optional location to a post. Facebook still lets me check in to venues. But neither ActivityPub (Mastodon) nor AT Protocol (BlueSky) allow me to do that.
I've been banging on about this for a while so was delighted to be invited to chat with the GeoSocial Task Force on their monthly call.
But, before I start, please remember that these proposals are not mandatory. If you don't want to share your location, then please don't share your location. This is an optional feature which shouldn't be used by people with a strong need for privacy.
We were primarily discussing the nascent Geographical Microsyntax proposals.
Firstly, I love the idea of being able to share my location. I want my friends to know I'm in town for a gig. I want people to think I'm cool because I'm seeing some experimental theatre. I want to virtue signal that I'm giving blood.
Similarly, I want to be able to find social media posts by location. What's happening right now in Paris? Did anyone else hear that sonic boom in London? Which cool people are also at this gig with me?
But, I do think these proposals have some issues which need to be addressed.
User Research
The primary thing missing from the proposal is any form of understanding what users want to do with a geotagged post.
You see a post like:
Hanging out with friends. I just checked in to Leicester Square.
What do you expect to happen when you click that link?
- See who is at the location?
- Read more information about the place being discussed?
- Find all posts at that specific address?
- Discover posts which are close to there?
- Something else?
What other things do people want to do with geotagged posts?
- Find all posts within 5Km of me?
- Discover users who have posted near me?
- Get emergency alerts for the city I'm in?
- See what's trending in a specific country?
Without knowing what people might want to do with this information, it's rather hard to design a service which meets their needs.
To micro or not to micro?
Where I disagree with the proposals is the idea of using inline text as a form of microsyntax.
Proposals like "I am in /London/ eating ice-cream" or "Checked in to Leicester Square L:N123456" fail for a couple of reasons.
Things like #hashtags and @mentions developed organically on social networks before they were eventually adopted by the platforms themselves. It is rare that a top-down diktat can be used to tell people how they should be formatting their posts.
More importantly, people are crap at formatting things consistently! Every event I go to has people using #Event alongside #Event2026 or #Event26 or a hundred variations.
Even if users could format it consistently, names are ambiguous. Is 🌐:Paris the one in France or Texas?
I'm strongly of the opinion that text is for text, not syntax.
Openness 🆚 Centralisation
Saying that you're on a specific point on the globe doesn't always provide useful information. Even with altitude, it isn't always possible to work out if your in the Starbucks or the Costa next door. Do you want to say you're in a train station, or a distinct platform, or even a specific train journey?
There are various services which offer unique IDs per loosely-defined place.
Google Maps provides a Place ID for every thing that it knows about. There's a similar service from FourSquare. But both of those are closed and proprietary systems - they can only be updated by the company that creates them.
Wikipedia's Wikidata has IDs for lots of places, similarly OpenStreetMap has nodes with names which can be used to identify locations.
But all of these suffer from the same flaw; they are centralised.
If Google kills its service then all those Place IDs die.
This has happened before. Yahoo used to run the Where On Earth IDentifier service but discontinued it.
While OSM and Wikipedia are great projects, they're still centralised. If you're banned from OSM, you can't create a new node.
So, to my mind, the primary way of identifying a place has to use a fully open, globally agreed, and unrestricted standard.
Location Plus Plus
The obvious choice is latitude and longitude as defined by WGS 84. It allows for arbitrary precision anywhere on the planet.
No one can stop you issuing lat/long just because a country is under sanctions. The standards community can't revoke your access to it. The co-ordinates are well understood by almost all software.
There are some alternatives. Google's Plus.Codes build on top of lat/long to make something more human readable. But, crucially, human readability is not the issue here. This is metadata which should never be shown to a human. If a user interface wants to format a lat/long they can do so as a Plus.Code or any other format.
GeoJSON
There are dozens of competing ways to mark up a location.
It seems sensible to me that, given most major social media protocols use JSON, adding GeoJSON would be the simplest way to add geographic information to a post's metadata.
At its most basic, a single "Point" can be shared like so:
JSON
{ "type": "Feature", "geometry": { "type": "Point", "coordinates": [-0.13005,51.5103] } }
It can have as much or as little precision as needed.
If the place being checked into has a name, it can also be added - this could be used for display purposes within the message
{ "type": "Feature", "geometry": { "type": "Point", "coordinates": [-0.13005,51.5103] }, "properties": { "name": "Leicester Square" } }
The properties can be as complex as the sender wants. For example it could add Wikidata references, OpenStreetMap IDs, telephone numbers, or some cool new thing which hasn't been invented yet.
Here's a maximalist example of checking in to a park:
{ "type": "Feature", "geometry": { "type": "Polygon", "coordinates": [ [ [-0.1303791,51.5099976], [-0.1295305,51.5100444], [-0.1297077,51.510947 ], [-0.1308786,51.5105859], [-0.1308893,51.5105793], [-0.1303791,51.5099976] ] ] }, "properties": { "name": "Leicester Square", "WikiData": "Q848912", "OSM": "4082589", "GooglePlaceID": "ChIJPcTFENIEdkgR94E58rgB69o", "PlusCode": "9C3XGV69+4X", "Quinfrob": "🌐89451_𰻝", "address": { "road": "Leicester Square", "neighbourhood": "St. James's", "quarter": "East Marylebone", "suburb": "Covent Garden", "city": "City of Westminster", "ISO3166-2-lvl8": "GB-WSM", "state": "England", "ISO3166-2-lvl4": "GB-ENG", "postcode": "WC2H 7NA", "country": "United Kingdom", "country_code": "gb" } } }
What's Next
My personal opinion is that the following needs to happen:
- Talk to some users - find out what they might use this for.
- Work with privacy advocates to reduce possible harms (for example, being able to redact a location from a previously shared post).
- Discuss with developers about how they'd work with this metadata.
- Clients should start adding GeoJSON metadata to their posts, even if it can't be displayed yet.
You can read the minutes of the meeting and I'd encourage you to join the next call.
15 thoughts on “Scattered thoughts on social geolocation”
@blog
As a user I would probably often want to see posts within a societal boundary, more than a radius around a (somewhat arbitrary) physical point. All posts in Osaka city for example; or posts from Okinawa prefecture.
| Reply to original comment on fosstodon.org
@Edent nice article!
I notice you didn't mention as:Place in #ActivityStreams vocab. In your previous article you mentioned "there is good news and bad news" around as:Place, and I deduced the bad news was that Mastodon didn't support it.
Regarding the #SWICG #GeoSocial task force proposal, you wrote:
> The primary thing missing from the proposal is any form of understanding what users want to do with a geotagged post.
In both the observation on Mastodon support and mention of a geotagged *post* there's an implicit assumption on the application domains this pertains to: (micro)blogging social media.
I gather that the range of business/app domains that may have geosocial capabilities is much broader than that. And while a list of generic use cases can be brainstormed for support, things will be quite solution-specific. And the TF perhaps better provide good guidance and building blocks for that.
Broader question is whether fedi is already tied shut in a microblogging straitjacket.
activitystreamsgeosocialswicg
| Reply to original comment on social.coop
@blog
Cross-referencing to the post I just made on the microblog post with the summary of this blog post. 😅
https://social.coop/@smallcircles/116963628874003173
PS. On the delightful fediverse experience curated list I have a separate category for #GeoSocialNetworking ..
https://delightful.coding.social/delightful-fediverse-experience/#geosocial-networking
| Reply to original comment on social.coop
@Edent It’s not for me but I can see this work out really well in a Pixelfed account to share where a photo was taken.
I envisage maps with dots and then you can click a dot to see how dozens of people have photographed the same thing in dozens of different ways.
| Reply to original comment on mastodon.social
@Edent
Because this was double-posted (microblog Note + blog Article) on my timeline, I will copy/paste here, that on the delightful fediverse experience curated list I have a separate category for #GeoSocialNetworking solutions ..
https://delightful.coding.social/delightful-fediverse-experience/#geosocial-networking
#ActivityPub #SocialWeb #GeoSocial
activitypubgeosocialgeosocialnetworkingsocialwebdelightful fediverse experience
| Reply to original comment on social.coop
@Edent there was a short-lived but healthy discussion about this in the ATProto camp which has vanished because of SSL issues with the discourse.lexicon.community site / the problem(s) remains that no one appreciates the size of the geo-iceberg or has the stomach to operate it as a free public service / some early examples of trying to work through things in code are https://github.com/schuyler/garganorn and https://github.com/whosonfirst/go-whosonfirst-spatial-atproto / the latter tries to address privacy issues dating back to "fire eagle" days
GitHub - schuyler/garganorn: Garganorn is intended to be a test bed for experimenting with adding location data to the ATmosphere.
| Reply to original comment on orthis.social
There's a fair bit of prior art at indieweb.org/checkin - something to discuss on Saturday?
| Reply to original comment on bsky.app
@blog In my opinion, we need to think about two different and not necessarily related objectives at this time:
| Reply to original comment on poliversity.it
100% to this. I already tag many of my blog posts with my geolocation (it occurs to me that I'm probably not using meta "geo.position" on these; I should fix that); and many of these crosspost to e.g. Mastodon... and that data is lost in translation. Would love for it to come along for the ride!
The absence of native geolocation in ActivityPub and AT Protocol likely stems from a deliberate architectural choice to prioritize privacy over convenience, given the inherent risks of correlating social metadata with precise coordinates. It would be interesting to see if the GeoSocial Task Force considers a user-controlled, ephemeral geotagging mechanism that allows sharing location only within trusted, private instances or direct message threads rather than public timelines.
| Reply to original comment on infosec.exchange
@blog yes plenty of times I want to tag I am exactly here come find me, or I am in London msg me and we can organise somewhere to meet. I would also want to be able to set up triggers and searches for contacts so I can get notified if they are posting near me. I miss tools like Google latitude, but not the privacy nightmare they became.
| Reply to original comment on mastodon.social
@Edent Great idea to have optional geolocation added to social media posts.
I would make it default off and optional on per post, so you can't inadvertently leave it on.
And +1 for using GeoJSON, the simplest Point annotation could be automatically added, while it is open for expansion using any of the other shapes
Then it's up to the implementation to provide tooling (what about using OSM to look up the boundaries of a neighborhood etc)
| Reply to original comment on mastodon.online
@Edent No. Absolutely not. Too much of that information is already tracked. (I know you said optionally, but people think about privacy and circumspection far too little these days. They don't realise they are putting themselves, and sometimes others, at risk by posting.)
| Reply to original comment on mastodon.me.uk
@blog I follow your reasoning on not relying on special microsyntax for text formatting.
There can be privacy risks when it comes to invisible metadata, though. Does the user remember that their location is automatically being attached to posts? Does attaching a photo with some EXIF location metadata translate into that location data being shared? I think the pattern has typically been to strip invisible metadata because of these accidental oversharing risks.
https://privacypatterns.org/patterns/Strip-invisible-metadata
| Reply to original comment on techpolicy.social
@blog @Edent that might come down mostly to implementation advice: check with the user every time before posting invisible attached sensitive metadata like location. But federation might also make that tricky -- posts that are boosted or federated could distribute the attached metadata to new contexts the user didn't anticipate, and removing attached locations may not be feasible. Maybe that's no different from the existing, very real privacy risks/confusions of using a federated social network.
| Reply to original comment on techpolicy.social
More comments on Mastodon.