I'm excited to show off #Atlas - a social mapping server for the #Fediverse.
General Discussion
65
Posts
19
Posters
117
Views
-
@sl007 Yes, I'd love to work together on geocoding, too.
Right now, there's not much to it..
I'm using commercial geocoders to translate addresses into Lat/Long, then including that in 1) the ActivityStream document, and 2) the search results.
I'd love to work with https://places.pub in some way, but I'm not sure (yet) what that integration would look like, or what we'd get out of it.
So yes: let's keep talking about how we make this seamless. There should be one standard, not six :)
cool. I am doing funded work for taxiteam and menschys and for redaktor (CMS) and Public Spaces Incubator (EBU and Public Broadcasters), fulltime, anyway :)
About places.pub - did post the code to federate OSM a long while ago https://gist.github.com/sebilasse/ca76c60955e5414cff2c253f1cd89af4
this snippet comes with a bunch of other modules.
An OSM to JSON-LD proxy like places.pub is super nice but what we need in taxiteam is a bit more.
Our database is a consolidated cache of OSM and wikidata knowledge but organized as hierarchical Collections, both political-administrative as well as by geohash.
So, if you are down to Country "DE"
https://gist.github.com/sebilasse/9b4c50bfabad43879c9c43c3adbe9ca1 it is a Collection of Federal States with its own id (2nd file).
With ActivityPub, we have the ability to define these hierarchies starting by Collection Q2 having the M49 regions as items with ['Collection', 'CollectionPage'] and that goes down to e.g. country/state/adm3/city/district/suburb/"hood" …🧵 1/3
-
cool. I am doing funded work for taxiteam and menschys and for redaktor (CMS) and Public Spaces Incubator (EBU and Public Broadcasters), fulltime, anyway :)
About places.pub - did post the code to federate OSM a long while ago https://gist.github.com/sebilasse/ca76c60955e5414cff2c253f1cd89af4
this snippet comes with a bunch of other modules.
An OSM to JSON-LD proxy like places.pub is super nice but what we need in taxiteam is a bit more.
Our database is a consolidated cache of OSM and wikidata knowledge but organized as hierarchical Collections, both political-administrative as well as by geohash.
So, if you are down to Country "DE"
https://gist.github.com/sebilasse/9b4c50bfabad43879c9c43c3adbe9ca1 it is a Collection of Federal States with its own id (2nd file).
With ActivityPub, we have the ability to define these hierarchies starting by Collection Q2 having the M49 regions as items with ['Collection', 'CollectionPage'] and that goes down to e.g. country/state/adm3/city/district/suburb/"hood" …🧵 1/3
The hoods have then all the street addresses, relations, boundaries like places.pub (with icons cached static etc. pp).
So, you know all the administrative parents from any address -
but what makes it really special is that any taxiteam instance could add info to any address (just as with your annotated places …).
As said, described it just very briefly in https://github.com/w3c/activitystreams/issues/582
It includes federated _reverse_ geocoding too but Lat/Long would not be cool for this, so we use geohash for the Service Actor.
https://en.wikipedia.org/wiki/Geohash https://geohash.softeng.co/Let's see a practical example:
A new fair
taxiteam forms in any city to "FCK UBER". They install an instance and choose a geohash they would like to geocode.
E.g. the square for Hamburg and some other cites.
These might overlap, it doesn't matter cause geohash is strictly hierarchical too.
We do also have a server for all Germany by default, anyway:
The instance once fetches the cache of needed infos up to street addresses.
🧵 2/3 -
The hoods have then all the street addresses, relations, boundaries like places.pub (with icons cached static etc. pp).
So, you know all the administrative parents from any address -
but what makes it really special is that any taxiteam instance could add info to any address (just as with your annotated places …).
As said, described it just very briefly in https://github.com/w3c/activitystreams/issues/582
It includes federated _reverse_ geocoding too but Lat/Long would not be cool for this, so we use geohash for the Service Actor.
https://en.wikipedia.org/wiki/Geohash https://geohash.softeng.co/Let's see a practical example:
A new fair taxiteam forms in any city to "FCK UBER". They install an instance and choose a geohash they would like to geocode.
E.g. the square for Hamburg and some other cites.
These might overlap, it doesn't matter cause geohash is strictly hierarchical too.
We do also have a server for all Germany by default, anyway:
The instance once fetches the cache of needed infos up to street addresses.
🧵 2/3Then it once sends an Update to all attached taxiteam machines meaning „Hey there, we are new and geocode ["u1"]“ (or ["u1r","u1w","u1x"]) then the network knows.
Now any taxidriver can add infos, warnings etc. directly.Next time when a user clicks on a map, we once decode Lat/Long to geohash, if your own instance doen't have it, it can ask the best suited option (e.g. serer proximity, load or trust).
As smaller the instance area is, as more detailed infos about em places ith might have :)
User now knows "You clicked on Fischmarkt Hamburg but unfortunately the area is currently flooded. Flashflood warning, go away" -
well, or maybe " … and your cab arrives in 1 minute" or "… cool exhibition nearby" or whatever.Sorry if I got either too complicated or short :)
We have frequent team mmetings, next is Saturday but I am also looking forward to the dev meeting with @reiver re. https://digitalcourage.social/@reiver@mastodon.social/115317680720978044🧵 3/3
-
Interesting point. Age verification laws around the world are going to make everything a lot more tricky.
Though Mastodon's argument doesn't make sense to me: IP addresses inherently map to location data, so we all receive *some* location, whether we're listening or now.
I don't have a good solution for this, right now.
It'll probably need to be baked into new user registrations, which admins would need to choose in some way.
Do you have a solution you'd recommend?
@benpate
no idea, I imagine a lot of my answers involve fixing the laws themselves haha.Bluesky offloads some of that responsibility to the PDS (i.e. I can tell my PDS that I'm an adult and it'll tell Bluesky that I'm verified) so (very) long-term I think I'd like that sort of service provided by the C2S server, so clients wouldn't have to think about it.
But yeah, I'd assume you'd have to implement it during the registration process and have admins use a method of their choice for verifying age (and optionally let them turn it off entirely if they can confidently say that nobody from XYZ location will ever be using the site)
-
I'll build whatever people say is most important. These policies will likely be up to individual server owners.
After spammers found Bandwagon, I've been kicking around ways to do moderation before profiles and posts become public.
But whether we're using maps or toots, the issues would still be the same. Bad actors will need to be identified quickly, and dealt with decisively.
I'm adding this into the project board. Feel free to pile on: https://github.com/orgs/EmissarySocial/projects/3/views/1?pane=issue&itemId=135226795&issue=EmissarySocial%7Cemissary%7C566
benpate@mastodon.social you may want a way to gain consent before allowing posting of a location + mentioned people. The other thing you may want to do is have moderation UI that allows searching for all notes for a specific location, and potentially banning the usage of certain locations in notes. i.e., if you see a doxing, then your mods can prevent that location from being tagged, and delete the note. If a person is tagged as at a certain location, they should need to accept the tag before that shows up in the Note.
You could also do things like limit posts being added within a certain region to a certain radius (based on geoip).
-
Somewhat relevant, I believe mastodon's argument for not supporting age verification is that they don't collect location data and so there's no way for them to determine if their users are somewhere where age verification applies. I don't know how well that works on legal grounds, but probably worth thinking about if you're building social apps that require geolocation
tom@tomkahe.com said in I'm excited to show off #Atlas - a social mapping server for the #Fediverse.:
> Somewhat relevant, I believe mastodon's argument for not supporting age verification is that they don't collect location data and so there's no way for them to determine if their users are somewhere where age verification applies. I don't know how well that works on legal grounds, but probably worth thinking about if you're building social apps that require geolocationYeah, this justification just doesn't pass scrutiny. Mastodon does collect the user's recently active IP addresses, and from that you can use geoip to resolve to a country/state. This could also all be handled by a FASP.
In other words, Mastodon could indeed implement age verification, the only remaining question is: what would that gate access to?
-
Agreed, even if they didn't collect/save IP addresses, I don't think you could get around it just by telling a court you didn't want to collect that data. I imagine they'd just tell you that you need to collect it.
(looked up the source so I'm not just randomly attempting to quote things from memory https://techcrunch.com/2025/08/29/mastodon-says-it-doesnt-have-the-means-to-comply-with-age-verification-laws/)
The social nonprofit explains that Mastodon doesn’t track its users, which makes it difficult to enforce such legislation. Nor does it want to use IP address-based blocks, as those would unfairly impact people who were traveling, it says.
-
@thisismissem @benpate i was also thinking how this is solved by the foursquares etc., aside from moderation. limiting notes to pois instead of arbitrary latitude-longitude-tuples may also be a viable strategy, and that might make it easier to figure out whom to even ask for consent, or who may be able to manage allowlists or similar mechanisms. not arguing to replicate that exactly, but remember foursquare mayors? the fediverse might have elected janitor groups.
i'm aware that i'm sharing half-finished thoughts, and i hope i'll find a bit more time for this.
-
@thisismissem @benpate i was also thinking how this is solved by the foursquares etc., aside from moderation. limiting notes to pois instead of arbitrary latitude-longitude-tuples may also be a viable strategy, and that might make it easier to figure out whom to even ask for consent, or who may be able to manage allowlists or similar mechanisms. not arguing to replicate that exactly, but remember foursquare mayors? the fediverse might have elected janitor groups.
i'm aware that i'm sharing half-finished thoughts, and i hope i'll find a bit more time for this.
@computersandblues @thisismissem
Half finished thoughts are the best!
And, I know I'm dipping into some choppy waters here, but I think "consent" relates to what content the server wants to share, and not consent of the "property/location owner."
I recognize there's potential for abuse (i.e. doxxing someone) but that exists outside of a mapping app, too.
But there's also cool use cases for non-consensual digital graffiti.. something in the spirit of:
https://observer.com/2025/10/artists-indigenous-ar-intervention-met-american-wing/
-
@thisismissem @benpate i was also thinking how this is solved by the foursquares etc., aside from moderation. limiting notes to pois instead of arbitrary latitude-longitude-tuples may also be a viable strategy, and that might make it easier to figure out whom to even ask for consent, or who may be able to manage allowlists or similar mechanisms. not arguing to replicate that exactly, but remember foursquare mayors? the fediverse might have elected janitor groups.
i'm aware that i'm sharing half-finished thoughts, and i hope i'll find a bit more time for this.
@computersandblues @thisismissem
But back to your original point, it could be interesting to roll up all of the notes about a particular POI, to say something meaningful about what's going on there.
That's probably out of scope for me right now, while I'm just learning how to make maps. But I'm making a note to research this some time down the road.
Fortunately, we have a lot of "closed source" research that we can lean on, then just cherry pick the best ideas and make them "open."
-
@computersandblues @thisismissem
Half finished thoughts are the best!
And, I know I'm dipping into some choppy waters here, but I think "consent" relates to what content the server wants to share, and not consent of the "property/location owner."
I recognize there's potential for abuse (i.e. doxxing someone) but that exists outside of a mapping app, too.
But there's also cool use cases for non-consensual digital graffiti.. something in the spirit of:
https://observer.com/2025/10/artists-indigenous-ar-intervention-met-american-wing/
benpate@mastodon.social there's multiple levels of consent. If you create a post with me mentioned in it with my location, I should probably have to accept that post for me to be mentioned in it. Otherwise someone can see me out and about, and create a post without me knowing that gives other people my location.
Hence, to tag other people at a location, they should have to accept that tag:
- Allow anyone to tag me at locations (potentially unsafe)
- Allow my followers to tag me at locations
- Allow my following to tag me at locations
- Allow this specific collection of Actors to tag me at locations
- Don't allow anyone to tag me at locations.
This could be achieved through an interaction policy on the Actor (though that's not yet a thing? I think interaction policies in GTS are only on Notes/objects)
-
@ddlyh Cool. And thank you. I'll check it out. I can't really compare features until I've done the class reading --but Atlas is pretty bare-bones right now, so I'll have a lot of catching up to do for anything that's already out there.
The good thing is that Atlas is an empty slate, and we can make it do whatever we need.
So, for favorites: is this to mark locations in your inbox as "favorite" locations to review later?
What are the important things we should put into this app?
-
I'm expecting this kind of street-level annotation to have lots of uses, from groups of friends replicating #FourSquare, to communities organizing events, or citizen #Journalists recording what's going on in their neighborhood.
Please share this with anyone who might benefit from sharing location notes online. It's time for me to start collecting some needs from real-world users.
@benpate @yala
Great idea ! My first reaction is : why not integrate it in @mobilizon ? That should be useful at the same time for their normal calendar of events and for conversations about discoveries on their system. -
@benpate @yala
Great idea ! My first reaction is : why not integrate it in @mobilizon ? That should be useful at the same time for their normal calendar of events and for conversations about discoveries on their system.This should integrate WITH @mobilizon very nicely. I'll need to verify, but Emissary should be able to index events in Mobilizon easily - if the server owner chooses. I think this is probably what you mean?
On a technology level, this uses a completely different technology and language that can't just be written into an existing app like Mobilizon.
Fortunately, the PROTOCOL matters, not the LANGUAGE, so we should be able to work together over ActivityPub.
-
Found it here: https://codeberg.org/openEngiadina/geopub
I'm checking it out now. Thanks for the link!
-
Found it here: https://codeberg.org/openEngiadina/geopub
I'm checking it out now. Thanks for the link!
@benpate
Hey Ben,
just for reference, this was initially planned in AP …
pukkamustard made a Talk in the first official ActivityPub Conf, I organized in 2019 i Prague. We have a video channel in peertube https://conf.tube/c/apconf_channel/videos - you should find it there.
Re. todays team meeting we talked mainly about how to integrate Public Transport from GTFS feeds, like https://transitous.org/ - anyway.
In the model which I described for federated geocoding, the difference to geopub is that geoohashes are ActivityPub Collections.
@yala @ddlyh -
@benpate
Hey Ben,
just for reference, this was initially planned in AP …
pukkamustard made a Talk in the first official ActivityPub Conf, I organized in 2019 i Prague. We have a video channel in peertube https://conf.tube/c/apconf_channel/videos - you should find it there.
Re. todays team meeting we talked mainly about how to integrate Public Transport from GTFS feeds, like https://transitous.org/ - anyway.
In the model which I described for federated geocoding, the difference to geopub is that geoohashes are ActivityPub Collections.
@yala @ddlyh -
@thisismissem Yes, you're raising some important points that we should cover. And, it's easy to see the potential for someone to post harmful content on a map.
But I don't see it being any different from posting harmful content in any other medium they have. Witness the dude live tweeting celebrity plane locations.
Fundamentally, people *should* be able to talk about others behind their backs. Maps or not, if they post data they shouldn't, then it's probably an issue for server mods, yes?
-
I read up on Interaction Policies. They're a great idea, but it looks like these are requests that only work if other servers enforce them.
I'm suspicious of things like this that can't be enforced beyond my own server because (as we've seen too many times) only the good guys will follow the rules, leaving the bad guys with an unfair advantage.
-
This should integrate WITH @mobilizon very nicely. I'll need to verify, but Emissary should be able to index events in Mobilizon easily - if the server owner chooses. I think this is probably what you mean?
On a technology level, this uses a completely different technology and language that can't just be written into an existing app like Mobilizon.
Fortunately, the PROTOCOL matters, not the LANGUAGE, so we should be able to work together over ActivityPub.
@benpate @yala @mobilizon
I think I understand the insisting point of "WITH". I guess it would be really nice. So, there would be two associated posts on two different servers, those two posts being linked by some sort of threads if I don't misunderstand.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
あのアカウントの人、#WordPress のプラグイン #ActivityPub の更新をしてないな…。たぶん。
-
Selbst mein kleines, privates @blog hat inzwischen 400 Follower: https://kaffeeringe.de/
Da soll noch jemand sagen, hier sei nix los!
#ActivityPub #WordPress #Fediverse#Mastodon
-
nate.mecca1.net/posts/2025-12-…
New blog post, a bit of an addendum to my older microblogging protocols comparison post(s) until I do an updated version at some point. It mostly just goes over a handful of big events and shifts I've personally noticed since my last post in the summer of 2024.
-
Posting for historical purposes:
#Misskey is NOT getting rid of #ActivityPub support
-
@mayel @evana @scottjenson @mastodonmigration @stefan It would only make it a little more difficult. The 'brigading' is now a two-step process for every participant.
The vector is really the 'followers-only' option. If we want to keep it, no way around sending a mandatory copy to a designated 'brigading moderator'.
-
@erlend Appreciate it! Could you expand on how you envision a group following another group working?
-
@bonfire backing!
Very happy to hear compatibility with the threadiverse is a goal. On that note, I hope you’ll consider pioneering the ability for groups to follow other groups:
-
I've improved federation support for Lemmy and other servers that support FEP-1b12 Group Federation.
I had to increase the number of available file descriptors on my personal server 4x because of the resultant inbound volume of ActivityPub activities! I liked a federated post and DOSed my server.
