Location-based social networking has had some incredible successes. Foursquare pioneered the concept of social check-ins, gamifying exploration of cities and discovery of new places. Swarm, its spiritual successor, still maintains a dedicated community of users who love sharing their adventures and competing for mayorships. These platforms proved there’s genuine demand for location-aware social experiences.

Yet location features have remained surprisingly fragmented across the broader social media landscape. Each platform has its own approach, its own limitations, and its own reasons for prioritizing or de-emphasizing location features.

Photo by Nick Hillier on Unsplash

Now, as developers migrate to Bluesky and the AT Protocol, there’s an opportunity to rethink location-based social networking from the ground up. The question is: how do you add geolocation to a protocol that was designed to be extensible, decentralized, and future-proof?

More importantly, could we recreate the magic of early Foursquare and Swarm, but in an open, federated way where users control their location data instead of it being locked in corporate silos? For many developers and users who care about data ownership and platform independence, this represents exactly the kind of future worth building toward.

The answer, it turns out, is both elegant and complex — and it’s happening right now through a grassroots effort led by developers who believe location should be a first-class citizen in the decentralized social web.

The Current State: Bluesky Has No Location Features

As of mid-2025, the official AT Protocol lexicons maintained by Bluesky include zero location-related fields. You can’t tag your location in a post. User profiles have no “location” field. There’s no built-in way to find nearby users or content.

This isn’t an oversight — it’s by design. The AT Protocol was built with extensibility at its core through a system called Lexicon, which allows developers to define custom record types and schemas. Rather than baking every possible feature into the core protocol, ATProto enables innovation at the edges.

But this philosophical choice left an obvious gap. Location is fundamental to how we experience the world, and social platforms without location feel incomplete. So the community stepped up.

Enter the Lexicon Community: Standardizing Location Data

The catalyst for the current location work was Foursquare’s release of their open source Places dataset, which suddenly made high-quality venue data freely available to developers. This breakthrough, combined with growing demand for location features on ATProto, prompted Bluesky to fund community research through their AT Protocol Community Fund.

The most significant work on ATProto geolocation is happening through the Lexicon Community initiative, spearheaded by Nick Gerakines, creator of Smoke Signal (an events app built on ATProto). This community-funded effort is developing standardized location schemas under the `community.lexicon.location.*` namespace, ensuring that all ATProto applications can share a common vocabulary for representing places and positions.

The community has defined four core location types that can represent virtually any place or position:

Geographic Coordinates (`community.lexicon.location.geo`)

The foundation of digital mapping: latitude and longitude stored as strings to preserve precision, with optional altitude and a human-readable name field.

{ 
 "$type": "community.lexicon.location.geo",
 "latitude": "40.785091",
 "longitude": "-73.968285",
 "name": "Central Park"
}

Street Addresses (`community.lexicon.location.address`)

Structured postal addresses with fields for country, locality (city/town), region (state/province), street, postal code, and an optional name.

{ 
 "$type": "community.lexicon.location.address", 
 "street": "350 5th Ave", 
 "locality": "New York", 
 "region": "NY", 
 "country": "US", 
 "postalCode": "10118", 
 "name": "Empire State Building"
}

Foursquare Venues (`community.lexicon.location.fsq`)

References to places in Foursquare’s open POI dataset, storing a `fsq_place_id` with optional coordinates and name. This provides access to a massive, curated database of venues without requiring apps to duplicate that data — a direct benefit of Foursquare’s open source release.

H3 Geocells (`community.lexicon.location.hthree`)

Represents locations using H3, a hexagonal geospatial indexing system. Perfect for describing areas or regions rather than specific points — think “downtown Manhattan” rather than a specific address.

Photo by Aranxa Esteve on Unsplash

How Projects Are Using Location Data Today

The beauty of the community lexicon approach is that it’s already being deployed in real applications. Here’s how different projects are tackling location:

Smoke Signal: Events With Rich Location Context

Smoke Signal was the pioneer, creating event records that include a `locations` array containing any combination of the location types above. An event might have both specific coordinates and a street address, or reference a Foursquare venue for a restaurant while including a backup address.

{ 
  "$type": "community.lexicon.calendar.event",
  "title": "Coffee & Code Meetup", 
  "locations": [
   { 
     "$type": "community.lexicon.location.fsq", 
     "fsq_place_id": "4b8c3d1af964a5201f5633e3",
     "name": "Blue Bottle Coffee" 
   },
   { 
     "$type": "community.lexicon.location.address", 
     "street": "66 Mint St",
     "locality": "San Francisco",
     "region": "CA", 
     "country": "US" 
   }
  ]
}

ATProto Geo Marker: Location as Content

The experimental atgeo-marker project takes a different approach, creating dedicated “marker” records that tie content to locations. Think of it as creating a location-based content aggregation system where you could mark Central Park and then associate multiple posts with that place.

In this followup article about the Geo Marker vs. the Anchor approach i’ve written a bit more on the pros and cons of each.

NoshDelivery: Business Location Records

For commerce applications, projects like NoshDelivery create separate record types for merchant locations, reusing the community lexicon types internally. This creates a database of places that can be referenced across the platform.

Two Architectural Approaches Emerge

As these projects mature, two distinct patterns are emerging for how to structure location data:

Embedded Location Objects

Most social applications embed location data directly within their records. A post about visiting a restaurant might include location objects inline, making the post self-contained with all its context.

Separate Location Records

Some use cases create dedicated records for locations that can then be referenced by URI in posts. This works well for business directories, venue databases, or when the same location will be referenced frequently.

Both approaches use the same underlying community lexicon types, ensuring interoperability while allowing flexibility in how data is structured.

Experimenting with Anchor: Testing the Waters

This is where our location-based check-in app, Anchor, comes into the picture — not as a finished solution, but as an experiment to test how well the community lexicon standards work in practice and identify what’s still missing.

Anchor is currently more of a research project than a consumer app. The reality is that location-based social networking needs official client support to gain real traction. But by building with the community lexicon standards now, we can discover gaps in the schemas, test integration patterns, and be ready when broader location support arrives.

Our experimental approach embeds location data in standard Bluesky posts using the community lexicon types. We post normal `app.bsky.feed.post`records so check-ins appear in everyone’s feed, but embed rich location data using a custom `app.dropanchor.checkin` record.

Here’s what an Anchor check-in looks like under the hood:

{ 
 "$type": "app.bsky.feed.post",
 "text": "Dropped anchor at Café de Plek 🍻",
 "createdAt": "2025–06–07T14:05:00Z", 
 "embed": { 
   "$type": "app.bsky.embed.record", 
   "record": { 
     "uri": "at://did:example/app.dropanchor.checkin/123", 
     "cid": "bafyreigh2akiscaildc…" 
   } 
  }
}

The embedded check-in record contains the structured location data:

{ 
 "$type": "app.dropanchor.checkin", 
 "text": "Café de Plek 🍻", 
 "createdAt": "2025–06–07T14:05:00Z", 
 "locations": [ 
 { 
   "$type": "community.lexicon.location.geo", 
   "latitude": "52.0705", 
   "longitude": "4.3007", 
   "name": "Voorburg" 
 }, 
 { 
   "$type": "community.lexicon.location.address", 
   "street": "Julianalaan 1", 
   "locality": "Voorburg", 
   "region": "ZH", 
   "country": "NL", 
   "postalCode": "2273JA",
   "name": "Café de Plek" 
 } 
 ]
}

This experimental approach is helping us understand several things:

• Schema completeness: Whether the community lexicon types cover real-world check-in scenarios

• Integration patterns: How location data should be embedded vs. referenced in social posts

• User experience gaps: What breaks when location data exists but clients don’t support it

• Performance implications: How location-rich records affect sync and storage

The goal isn’t to build the definitive check-in app, but to stress-test the emerging location infrastructure and contribute learnings back to the community standards.

The Power of `$type`: Self-Describing Data

One of the most elegant aspects of the ATProto location ecosystem is how it uses `$type` fields to create self-describing data. Every location object includes a `$type` that points to its lexicon definition, allowing any client to understand and validate the data structure.

This means a photo-sharing app could read location data from an Anchor check-in, or a map application could aggregate location data from multiple different ATProto apps, all without requiring specific integrations or API negotiations.

In fact, developers are already experimenting with this interoperability. Community members like Brian M have shared experiments embedding location data directly in posts, demonstrating how the schemas work in practice and paving the way for broader adoption.

Photo by Ellena McGuinness on Unsplash

What’s Missing (And What’s Coming)

While the community has made impressive progress, there are still gaps:

• No official Bluesky client support: The main Bluesky app doesn’t yet recognize or display location data

• Limited tooling: Developers need better libraries and debugging tools for location schemas

• Discovery mechanisms: We need ways to find location-enabled content and apps

• Privacy controls: Granular location sharing permissions and privacy settings

But these gaps represent opportunities. As more developers build location-aware ATProto applications, the ecosystem will mature rapidly.

Why This Matters

The approach being taken by the ATProto community represents something fundamentally different from how location has been handled on previous social platforms. Instead of a top-down decision by a platform owner, we’re seeing organic standardization driven by developer needs and user demand.

This bottom-up approach has several advantages:

• Innovation without permission: Developers can experiment with location features without waiting for platform approval

• Interoperability by design: Apps using community lexicons automatically work together

• Resistance to platform changes: Location data exists in the protocol itself, not just in one company’s API

• Extensibility: New location types can be added as needs evolve

Photo by Jakob Owens on Unsplash

The Road Ahead

As someone experimenting in this space, I’m optimistic about where location on ATProto is heading. The community lexicon approach provides a solid foundation, and projects like Smoke Signal, the various geo marker experiments, and experimental apps like Anchor are proving that rich location features are possible on the decentralized web while helping identify what still needs to be built.

The next year will be crucial. If enough developers adopt these standards and build compelling location-based experiences, we could see official client support from Bluesky. More importantly, we might finally get the location-aware social web that users have been wanting for over a decade — but this time built on open protocols where users own their data.

Imagine recreating the best parts of Swarm’s social discovery and friendly competition, but in a federated system where your check-in history isn’t trapped in one company’s database. Where location-based apps can interoperate freely, where you can switch clients without losing your data, and where innovation happens at the edges rather than waiting for platform approval.

Whether you’re a developer curious about building on ATProto, a user frustrated with corporate control over your location data, or just someone interested in how decentralized systems evolve, the location work happening in the ATProto community is worth watching.

Because for the first time in social media history, location isn’t just a feature that a platform decides to build or abandon — it’s becoming infrastructure that no single company can control.

This is a re-post of an article I published on Medium earlier.

— -

Want to read more about AT Proto and geolocation? In this followup article about the Geo Marker vs. the Anchor approach i’ve written a bit more on the pros and cons of each. And in this more high level story i’ve written up what it would take to make a full open source Foursquare clone.

— -

If you’re interested in following our research or contributing to ATProto location standards, find us on Bluesky at @dropanchor.app

All code examples and schemas referenced in this article are available in the Lexicon Community repository and the ATProto documentation.