Note: this only reflects my personal work this week. Visit the BTC Map Blog for consolidated monthly reports.
Infra
Backup Server
BTC Map infrastructure is hacky, mostly because we lack contributors with strong ops skills. I handle most maintenance, but I’m no expert, and I tend to prioritize fun tasks over boring ones.
Backups are boring, but you can’t avoid them forever as the project grows. Our old backup system was too unreliable, so I finally forced myself to set up a dedicated backup server.
This server regularly fetches critical data from the API server. While the API server is accessible to the whole team, this server is only accessible by me. That protects our backups if someone else on the team is hacked, but if I’m hacked, it’s game over.
Not ideal, but better than the status quo, and the places themselves are hosted on OSM with an excellent decentralized backup system. More people with API server access should set up their own backups to improve the new setup, and I’m planning to help with that.
Ansible
Our servers are undocumented. That’s something we’ll need to fix long‑term. I started drafting Ansible configs to slowly document our existing fleet. It already partially covers two servers, but there’s a lot of work ahead.
Website
Merchant Page Speedup
The merchant page is one of the most‑used in the web app, and its performance was abysmal due to a full API sync dependence. A full sync means fetching up to a million JSON objects, which is not optimal for a random visitor with no pre-existing cache.
I’m not sure why it relied on a full sync, probably legacy UI design decisions that didn’t account for API capabilities. I added a few new endpoints to break away from the sync, leading to orders‑of‑magnitude performance improvements for cold clients. Things that often took minutes now load in seconds or less.
Events Map
The events map is still an unmerged draft, but it could be an important step for BTC Map web app (Android app has it already). In many regions, Bitcoin events and meetups are more popular than merchants, and there’s no good source for event data.
https://github.com/teambtcmap/btcmap.org/pull/757
Android
Preview builds are available here: https://github.com/teambtcmap/btcmap-android/releases/tag/preview
Improved Clustering
The new clustering approach offers a smooth user experience, but it required significant refactoring and testing. It finally feels stable enough to release, I’m planning to roll out a new Android app version next month.
A nice side effect: map rotation is back. The old clustering didn’t support it, so I had to disable it.
Website Styles
Custom user themes work fine for normal widgets, but the map isn’t a normal widget as it can introduce contrast issues. Some people also use light map styles in dark mode and vice versa.
The new Android app uses well‑tested website colors by default, which work well in both light and dark modes. I tested them with all supported map styles and liked the results.
You can still opt into custom Material colors through settings, or set your own. The Android app is now the most customizable Bitcoin map out there.
API
Logging
Our API logs all requests for analytics and debugging. That data isn’t connected to user accounts (users don’t even have accounts), and old records are auto‑erased, saving storage costs and ensuring we don’t keep permanent records.
The new logging system is much faster and saves additional fields like user agent. That’s handy for debugging, the latest example was accidentally banning our own e2e test runner for API abuse.
OG Cache
OpenGraph images are what you see when sharing links. For BTC Map merchants, you’ll see a map with a pin in the middle. These images are generated on the fly by our API, but they rely on OSM tile servers, and we don’t want to abuse their generosity.
The new cache ensures we only ask OSM servers once per merchant, reducing load on their infrastructure and improving our own latency.
New Database Structure
BTC Map’s database now consists of three simple files:
main.dbimages.dblog.db
The names are self‑descriptive, and the structure makes our data portable. For example, the backup server can just use sqlite3_rsync on these files for incremental backups.
Fetching Place Areas
This endpoint is handy when showing a BTC Map location and you also want to show which communities or country it belongs to.
https://api.btcmap.org/v4/places/20423/areas
Fetching Place Activity
This endpoint adds optional context to places, useful for third‑party apps. Currently, it shows core lifecycle events (created, updated, deleted). I plan to add “commented” and “boosted” events in the future.
https://api.btcmap.org/v4/places/8660/activity
Developer Portal
Since BTC Map clients don’t support user accounts, some sensitive operations can’t be done anonymously. We do have an auth system, used by moderators and third‑party integrations.
Onboarding new accounts has always been hard, so I created a simple website that automates signups and API key management.
Conclusion
It was a productive month. I’m especially proud of improving our fundamentals: cleaning up API data and dramatically speeding up the merchant page.