Or just use the Surfingkeys extension - it has a bit of a steep learning curve to customize it, but it's worth every piece of effort.

My advice is to build such solutions around open products like Signal, XMPP or Matrix if possible. Or even Telegram.

On top of providing a better developer experience compared to Meta's ultra-locked and limited APIs, they aren't subject to the whims of a giant faceless company that can kill your product for no apparent reason with no chances of appeal.

Especially if you're doing these projects for folks in the developing world. Let's not lock them in proprietary American spyware like the whole West has already done :) from a user's perspective, if things are done properly, it'll just be a matter of installing another app.

And btw using a Matrix server with a WhatsApp bridge could also be a temporary solution to bypass the ban. But I haven't tested it with business accounts.

As the developer of a GPS tracking app that relies a lot on OpenStreetMap, I've faced many of these problems myself. A couple of learned lessons/insights:

- I avoid relying on any generic location name/description provided by these APIs. Always prefer structured data whenever possible, and build the locality name from those components (bonus points if you let the user specify a custom format).

- Identifying those components itself is tricky. As the author mentioned, there are countries that have states, others that have regions, other that have counties, or districts, or any combination of those. And there are cities that have suburbs, neighbourhoods, municipalities, or any combination. Oh, and let's not even get started with address names - house numbers? extensions? localization variants - e.g. even the same API may sometimes return "Marrakesh" and sometimes "Marrakech"? and how about places like India where nearby amenities are commonly used instead of house numbers? I'm not aware of any public APIs out there that provide these "expected" taxonomies, preferably from lat/long input, but I'd love to be proven wrong. In the absence of that, I would suggest that is better to avoid double-guessing - unless your software is only intended to run in a specific country, or in a limited number of countries and you can afford to hardcode those rules. It's probably a good option to provide a sensible default, and then let the user override it. Oh, and good catch about abbreviations - I'd say to avoid them unless the user explicitly enables them, if you want to avoid the "does everybody know that IL is Illinois?" problem. Just use "Illinois" instead, at least by default.

- Localization of addresses is a tricky problem only on the surface. My proposed approach is that, again, the user is king. Provide English by default (unless you want to launch your software in a specific country), and let the user override the localization. I feel like the Nominatim's API approach is probably the cleanest: honor the `Accept-Language` HTTP header if available, and if not available, fallback to English. And then just expose that a setting to the user.

- Bounding boxes/polygons can help a lot with solving the proximity/perimeter issue. But they aren't always present/sufficiently accurate in OSM data. And their proper usage usually requires the client's code to run some non-trivial lat/long geometry processing code, even to answer trivial questions such as "is this point inside of this enclosed amenity?" Oh, and let's not even get started with the "what's the exact lat/long of this address?" problem. Is it the entrance of the park? The middle of it? I remember that when I worked with the Bing in the API in the past they provided more granular information at the level of rooftop location, entrance location etc.

- Providing localization information for public benches isn't what I'd call an orthodox use-case for geo software, so I'm not entirely sure of how to solve the "why doesn't everything have an address?" problem :)

The irony of watching this 2017 TED video in 2025, and find out that my NoScript extension reports half a dozen of JS trackers and ads providers on this page - including Google, doubleclick.net, sail-personalize and sail-track.

Oh, and if you navigate to this page without NoScript, AdBlocker or a PiHole DNS you'll probably be presented with a cookie consent banner, a bunch of ads on the page and before watching the video, and your data being shared with at least half a dozen partners (a number that can increase dramatically if you visit the page of any news outlet instead of ted.com).

So yeah, I guess that the message of this video aged like fine wine.

I'd assume that self-hosting is not an option for this user?

Otherwise the alternatives would be pretty much a nobrainer for me:

Microsoft Office 365 -> Nextcloud Bitwarden -> self-hosted Bitwarden/Vaultwarden GitHub -> Sourcehut/Codeberg/Gitea/Forgejo Google search -> Searxng Reddit -> Lemmy Hackernews -> Lobsters Twitter/LinkedIn -> Mastodon / any Fediverse software