# content
Overview

This issue explores implementing a basic geosocial extension for Bonfire that enables location-based social interactions without the privacy concerns, gamification and corporate overhead of foursquare.

Relevant resources

Use cases and proposed implementation approach: hedgedoc.socialweb.coop/kUPv...

Geosocial task force github.com/swicg/geosocial (Issues are particularly relevant)

Small client for checking in places socialwebfoundation.org/2025...

Mockups

Create new activities in the composer

Currently, our composer only supports notes and articles. To enable check-ins/check-outs, we need:

Activity type selector: Dropdown next to user avatar in composer

Dynamic fields: Show relevant inputs based on selected activity type

For check-ins/travel/check-outs: Autocomplete location input

Here our standard component, but with a dropdown element next the user avatar to select the activity to publish

The dropdown shows the activity type available, based on the active extensions

Once the user chooses the activity, the composer includes the needed extra field, in this case for check-in it only adds a autocomplete input for selecting the location.

(I added a dropdown next to checkin for switching between checkin - travel - checkout, maybe it's better to show all the 3 options inline?)

The place page

Places should be first-class AP actor.

This transforms places from simple geotags into active participants in the federated web, allowing physical spaces to build communities and curate their digital presence.

This means also that a place should be managed by one or more user.

In the following mockups we envisioned a very basic place page: on the right sidebar there is the About widget, with some extra fields that can be included in the place settings such as: name, address, phone number, email, opening hours, plus some aggregated data if needed, like the amount of check-in in last day/weel/month etc.

The page would have different tabs based on what's most relevant for the place and the extensions enabled, here the check-in feed

and the events feed

We already have most of the building block ready for implementing this, at least for this basic version (eg. focusing only on "public" spaces, not including the event extension, focus on check-in/check-out functionalities).

Location Pages for Non-Actor Places

For locations from places.pub (or similar services) that aren't yet ActivityPub actors, we can create aggregation pages that function like more structured location-specific hashtag pages. Users can follow these locations and explore all related activities in one place.

See all the check-in that belong to a specific location

See the map with all the other locations nearby

See all the media published in that location

Next steps

Add a Map view mockup (we do already have one in the bonfire_geolocate extension) to navigate all the places in a interactive way

Add more geosocial activity preview to see how they appear in other feeds

Feedback on proposed UX flow

# preview.content
Overview

This issue explores implementing a basic geosocial extension for Bonfire that enables location-based social interactions without the privacy concerns, gamification and corporate overhead of foursquare.

Relevant resources

Use cases and proposed implementation approach: hedgedoc.socialweb.coop/kUPv...

Geosocial task force github.com/swicg/geosocial (Issues are particularly relevant)

Small client for checking in places socialwebfoundation.org/2025...

Mockups

Create new activities in the composer

Currently, our composer only supports notes and articles. To enable check-ins/check-outs, we need:

Activity type selector: Dropdown next to user avatar in composer

Dynamic fields: Show relevant inputs based on selected activity type

For check-ins/travel/check-outs: Autocomplete location input

Here our standard component, but with a dropdown element next the user avatar to select the activity to publish

The dropdown shows the activity type available, based on the active extensions

Once the user chooses the activity, the composer includes the needed extra field, in this case for check-in it only adds a autocomplete input for selecting the location.

(I added a dropdown next to checkin for switching between checkin - travel - checkout, maybe it's better to show all the 3 options inline?)

The place page

Places should be first-class AP actor.

This transforms places from simple geotags into active participants in the federated web, allowing physical spaces to build communities and curate their digital presence.

This means also that a place should be managed by one or more user.

In the following mockups we envisioned a very basic place page: on the right sidebar there is the About widget, with some extra fields that can be included in the place settings such as: name, address, phone number, email, opening hours, plus some aggregated data if needed, like the amount of check-in in last day/weel/month etc.

The page would have different tabs based on what's most relevant for the place and the extensions enabled, here the check-in feed

and the events feed

We already have most of the building block ready for implementing this, at least for this basic version (eg. focusing only on "public" spaces, not including the event extension, focus on check-in/check-out functionalities).

Location Pages for Non-Actor Places

For locations from places.pub (or similar services) that aren't yet ActivityPub actors, we can create aggregation pages that function like more structured location-specific hashtag pages. Users can follow these locations and explore all related activities in one place.

See all the check-in that belong to a specific location

See the map with all the other locations nearby

See all the media published in that location

Next steps

Add a Map view mockup (we do already have one in the bonfire_geolocate extension) to navigate all the places in a interactive way

Add more geosocial activity preview to see how they appear in other feeds

Feedback on proposed UX flow

# preview.summary
Overview
This issue explores implementing a basic geosocial extension for Bonfire that enables location-based social interactions without the privacy concerns, gamification and corporate overhead of foursquare.

Relevant resources

Use cases and proposed implementation approach: hedgedoc.socialweb.coop/kUPv...
Geosocial task force github.com/swicg/geosocial (Issues are particularly relevant)
Small client for checking in places socialwebfoundation.org/2025...

Mockups
Create new activities in the

# source.content
## Overview

This issue explores implementing a basic geosocial extension for Bonfire that enables location-based social interactions without the privacy concerns, gamification and corporate overhead of foursquare.

\
Relevant resources
------------------

* Use cases and proposed implementation approach: [hedgedoc.socialweb.coop/kUPv...](https://hedgedoc.socialweb.coop/kUPvzmd4SjyN1oGxyrzskQ#)
* Geosocial task force [github.com/swicg/geosocial](https://github.com/swicg/geosocial) (Issues are particularly relevant)
* Small client for checking in places [socialwebfoundation.org/2025...](https://socialwebfoundation.org/2025/07/14/seeking-interop-testing-for-geosocial-activitypub-client/)

## Mockups

### Create new activities in the composer

Currently, our composer only supports notes and articles. To enable check-ins/check-outs, we need:

* Activity type selector: Dropdown next to user avatar in composer
* Dynamic fields: Show relevant inputs based on selected activity type
* For check-ins/travel/check-outs: Autocomplete location input

Here our standard component, but with a dropdown element next the user avatar to select the activity to publish

\
![Image](https://github.com/user-attachments/assets/efc167f9-7bb2-48a8-942e-98f2b68148a7)\
The dropdown shows the activity type available, based on the active extensions

![Image](https://github.com/user-attachments/assets/cbdd2a62-ab0d-4a28-888e-a5e087835713)

Once the user chooses the activity, the composer includes the needed extra field, in this case for check-in it only adds a autocomplete input for selecting the location.

*(I added a dropdown next to checkin for switching between checkin - travel - checkout, maybe it's better to show all the 3 options inline?)*

\
![Image](https://github.com/user-attachments/assets/335d27e4-9a04-4972-afda-d7deb02a3113)

## The place page

Places should be first-class AP actor.

This transforms places from simple geotags into active participants in the federated web, allowing physical spaces to build communities and curate their digital presence.

This means also that a place should be managed by one or more user.

In the following mockups we envisioned a very basic place page: on the right sidebar there is the About widget, with some extra fields that can be included in the place settings such as: name, address, phone number, email, opening hours, plus some aggregated data if needed, like the amount of check-in in last day/weel/month etc.

The page would have different tabs based on what's most relevant for the place and the extensions enabled, here the check-in feed

![Image](https://github.com/user-attachments/assets/848fbbef-1ae2-413b-8a88-437659cfcc2e)

and the events feed

\
![Image](https://github.com/user-attachments/assets/289e91c3-1357-4853-b35f-50f5e8ad8b7d)

We already have most of the building block ready for implementing this, at least for this basic version (eg. focusing only on "public" spaces, not including the event extension, focus on check-in/check-out functionalities).

<br/>

## Location Pages for Non-Actor Places

For locations from [places.pub](http://places.pub) (or similar services) that aren't yet ActivityPub actors, we can create aggregation pages that function like more structured location-specific hashtag pages. Users can follow these locations and explore all related activities in one place.

<br/>

### See all the check-in that belong to a specific location

![Image](https://github.com/user-attachments/assets/bb5d41ef-b15f-4a87-8f7f-c2b7ef78eb63)

### See the map with all the other locations nearby

![Image](https://github.com/user-attachments/assets/3ba2b965-a530-4339-81be-c41236a9502f)

### See all the media published in that location

<br/>

![Image](https://github.com/user-attachments/assets/9eb5119f-c17c-4d79-bc2f-73db719b981e)\
\
Next steps

* Add a Map view mockup (we do already have one in the bonfire\_geolocate extension) to navigate all the places in a interactive way
* Add more geosocial activity preview to see how they appear in other feeds
* Feedback on proposed UX flow

# summary
Overview
This issue explores implementing a basic geosocial extension for Bonfire that enables location-based social interactions without the privacy concerns, gamification and corporate overhead of foursquare.

Relevant resources

Use cases and proposed implementation approach: hedgedoc.socialweb.coop/kUPv...
Geosocial task force github.com/swicg/geosocial (Issues are particularly relevant)
Small client for checking in places socialwebfoundation.org/2025...

Mockups
Create new activities in the