Igor Bubelov

BTC Map October Recap

Mon, 02 Nov 2026 00:00:00 +0000

Note: this only reflects my personal work this month. Visit the BTC Map Blog for consolidated monthly reports.

The desktop app

Android

I predicted last month that the Compose Multiplatform rewrite would dominate this report, and it did. What started as a shared module and a proof of concept is now the whole app: Android runs the same Composables as the new desktop client, the old View layer is gone, and for the first time BTC Map has a native build for Linux, Windows and macOS.

Compose Multiplatform

The migration happened in the open, one slice at a time, and it touched every screen. The Android app is now a single host fragment wrapped around the shared UI root, and the pile of fragments, dialog fragments and XML layouts it used to carry is down to two layouts.

Moving code into the shared module also meant leaving the Android-only libraries behind:

OkHttp became Ktor, Gson became kotlinx.serialization, and java.time became kotlinx-datetime
The database layer turned suspending, which the upcoming web target needs, with a small bridge for the synchronous Compose screens
A wasmJs target now compiles the shared core, so a web client is no longer blocked at the data layer
Android and desktop share one string catalog, translated into all 36 app languages

Desktop App

The new :desktopApp module renders the shared UI in a desktop window.

The desktop app’s settings screen

There is no platform-specific UI to maintain, so desktop gets the same features as Android, plus a few that make sense with a mouse:

Right-click the map to add a place, event or note at the clicked point
Hover states on the area chips and the toolbar
Keyboard shortcuts and copy actions in the search field
A language setting that applies at the next launch

Compose Desktop has no native Wayland backend on Linux, so it runs through XWayland, and Java 2D applies only whole-number scales there. A KDE session at 275% arrived as 200%, and the shared UI looked smaller than it does on Android. The app now reads the real scale from the compositor and uses it as the window density.

Packaging

Conveyor builds the release packages on our Linux machine: a Linux AppImage, a Windows MSIX with an installer and a portable zip, and a signed macOS app with a Sparkle update feed. Previously we could only produce the AppImage, because jpackage cannot cross-compile. The Windows and macOS packages are still self-signed, so the installer asks the user to trust the certificate first, and the Windows build installs but does not start yet, which is an upstream MapLibre runtime issue.

Notes

Notes are a new feature I am quite happy about. A signed-in user drops a free-form text pin anywhere on the map, and it is private by default with an option to publish it. They are meant to add context regarding the surrounding area.

In the app, notes are a fourth marker layer next to merchants, events and exchanges. They are never clustered, they wear the standard marker colours (or a chosen icon), they sync incrementally like the other tables, and a new My notes screen lets you edit, flip visibility and delete them.

Events & Submissions

Submitting an event from the app was impossible until now. There is a proper add-event screen with date and time pickers and a positioning map, and the time is sent as a floating local wall-clock plus timezone=auto, so an event at 19:00 happens at 19:00 where it is, not where the submitter is.

The rest of the submission lifecycle came with it:

A My events screen listing every submission, upcoming first, with duplicate and revoke actions
Revoking a pending submission through the new self-service endpoint
An event review queue for event managers, admins and roots, badged with the number of pending submissions
An event sheet on the map, so an event opens in place instead of a separate screen
A delete action for the submitter while the event is pending, and for privileged roles at any time

Admin & Moderation

The app is no longer only for reading. Area managers get a Manage areas screen listing cached communities with never-verified areas first, a detail screen with the area polygon and its fields, and the ability to verify an area and edit its name and description. Admins and roots get user management (roles and geofence, following the server policy exactly) and a place image moderation screen for the new uploads.

Map Work

MapLibre Compose 0.20.0 landed this month, and most of the map work went into closing the gap with the old Google Maps implementation:

A compass above the community chips that appears whenever the view is not facing north
A map tilt setting, and rotation, tilt, centre and zoom all remembered
A place stays selected and the pin stays visible when you leave the map to report, boost or comment
The map’s features load before the first frame instead of waiting for a move
Correct CJK and Hangul labels through a bundled glyph provider with an OpenFreeMap fallback
Search accepts coordinates, and OpenStreetMap results from Nominatim now sit under the local BTC Map hits, paced to its one-request-per-second policy
Basemap points of interest that are not merchants open a small sheet with the localized name (with pinyin ruby), category and coordinates, plus “It accepts bitcoins” and “Save as note” actions

Beta Updates

Beta builds can finally update themselves in place: the update button downloads the APK with a progress bar and hands it to the system installer, the manifest carries a build time so a rebuild at the same version code is still offered, and the settings screen gained an About section with a manual update check.

Dev Tools

The devtools script grew into a real tool. app run covers the desktop app (under Compose Hot Reload) and Android, which now runs in Waydroid instead of a Google AVD, since the container boots Android on the host kernel and needs neither the emulator binary nor a system image. app deploy-beta takes the platforms to publish as flags, deploy-release became prepare-release, and the thin adb and Gradle wrappers are gone.

API

The API added the rest of the surface the new clients need. Most of it is the v4 REST API catching up with the RPC layer, since mobile apps never speak RPC.

Notes

The notes feature started on the API side. A new note table holds a coordinate, text, an icon and a public flag, and the v4 API exposes POST /v4/notes, GET|PATCH|DELETE /v4/notes/{id}, GET /v4/notes/search and GET /v4/users/me/notes. Public notes are geo-searchable, private ones are visible only to their author, and the owner list supports updated_since and include_deleted so clients can sync incrementally.

Place Images

Photos went from report evidence to a first-class store:

POST /v4/places/{id}/images lets signed-in users attach a photo to a place directly, and GET /v4/places/{id}/images serves the metadata
Photos are validated like report evidence: at most 10 MB decoded, at most 20k pixels per side, raster formats only
DELETE /v4/places/{id}/images/{image_id} removes an upload, but only the uploader, admin or root may call it
GET /v4/place-images lists the newest uploads across every place for moderation, and GET /v4/users/me/place-images lists your own
The uploader is exposed as a nested author object, resolved across image.db and main.db

Event Review

Events now carry a review status (pending, live or rejected) and an optional submitted_by attribution. Signed-in users submit through POST /v4/events, track their own through GET /v4/users/me/events, and revoke a pending submission with DELETE /v4/events/{id}. Event managers and above approve or reject through PUT /v4/events/{id}/status. Public reads stay live-only by default, and the geofence check moved into a shared service/geofence module used by both REST and RPC.

Areas

Area management opened up over REST:

POST /v4/areas creates an area with a fixed set of named fields, rejecting geofenced callers, since a new top-level area falls outside everything they manage
PATCH /v4/areas/{id} updates named fields only, with an immutable alias, nulls clearing optional tags and contact channels filtered through an allowlist
verified_at is now part of the area response and the delta sync
GET /v4/areas/{id}/reports returns a single area’s daily history in a typed shape instead of a raw tags map

Users & Access

GET /v4/users is an admin/root-only username search, and PATCH /v4/users/{id} updates roles and geofences while keeping admin as the role ceiling. Token versus user role precedence moved into one Auth::effective_roles helper so REST and RPC authorize identically.

I also started tracking last_used_at on access tokens, so unused or leaked tokens can be spotted. It is stamped on successful authentication and stays out of the updated_at trigger.

Dashboard

GET /v4/dashboard/infra serves the analytics dashboard to the dashboard, admin and root roles, mirroring the RPC gate.

Maintenance

A large part of the API’s month was paying down dependency debt, and it went deeper than version numbers:

rusqlite 0.40 and deadpool-sqlite 0.14, moving bundled SQLite to 3.53.2
nostr 0.45, matrix-sdk 0.19, argon2 0.6, sha2 0.11 and base64 0.23, with the breaking changes handled and existing password hashes still verifying
clap is gone, after disabling a default feature on names that pulled it in for a CLI we never use
Declared version floors raised to match Cargo.lock, so the manifest describes what we actually build

The most satisfying cleanup was the OpenGraph image renderer. We used the staticmap crate, which dragged in an old rustls and six RUSTSEC advisories. It is replaced by an in-house renderer that fetches the covering tiles, composites them with the image crate, draws the marker so its tip sits on the element and encodes a 600x315 JPEG.

Docs

The new endpoints came with REST documentation pages for notes, place images and the infrastructure dashboard, and the users page grew the admin search and update calls.

CLI

area get, area add and area update now use the v4 REST API instead of RPC, with percent-encoded path segments for aliases with spaces or non-ASCII characters
set-area-tag is replaced by area update, which supports --name, --type, --description with --clear-description, --geojson and repeatable --contact
area add requires --type and accepts an optional --name

Ansible

Infrastructure work was mostly maintenance this month, and it was a good reminder of why it matters:

Every host was running a kernel vulnerable to CVE-2026-98432, a remote root in the IPv4 TCP IP-options code. Several of them exposed Go listeners with no packet filter in front. All five hosts were upgraded, rebooted and verified with their services healthy.
Database replication on the backup host had been failing since August 17 because the deployed script used mkdir where the repo has mkdir -p, and every run after the first aborted under set -e. The snapshot timer kept compressing copies frozen at that date. The repo fix never landed because the inventory pointed at a hostname that does not resolve. The correct script is deployed and a full 4 GB sync plus an incremental run were verified.
The new Overpass host joined the inventory with a full system upgrade and SSH hardening. I also documented an API outage caused by fcgiwrap running a single worker, where one large query blocked every other request for about seven minutes. The fix is documented but not applied yet.

Future Plans

A few things on my mind:

Cut the 1.3.0 release.
Get the desktop builds to a state ready for public beta.
Keep pushing the web target, now that the shared core compiles for it.
Continue moving the CLI and the docs from RPC to v4.

BTC Map September Recap

Fri, 02 Oct 2026 00:00:00 +0000

Note: this only reflects my personal work this month. Visit the BTC Map Blog for consolidated monthly reports.

Thanks

Thanks to Nathanael for another round of bug reports and testing.

Android

It has been six months since our last Android release. Version 1.2.0 shipped on September 30, and most of the work below feeds into it.

1.2.0 Release

The release finally collects the offline, search and account work into a stable build. The headline items:

Global search covering places, communities and conferences
Full offline mode with a bundled world map and downloadable high-res region packs
Community pulse and community/country screens
Optional accounts with saved places and areas, and a personalized activity feed
Per-app language selection on Android 13+
Simplified add-location and verify/report flows
Human-readable opening hours and a database/image diagnostics screen

Offline First

This was the through-line of the month. The app now ships curated data snapshots so a fresh install is usable without a network:

Full place records, so the first sync only fetches the delta since the snapshot
The full areas snapshot, including borders
Place-comments and events snapshots, so comments and event search work offline
A low-zoom world basemap

The map, area screen, search and activity feed read from the local database and stay usable offline, and the sync state is centralized and observable through a new database stats screen.

I also added downloadable high-res offline map packs per region, using MapLibre’s offline manager, with a size estimate before download and progress and delete controls afterwards.

Places & Reports

A native place submission form with a draggable-pin mini map, replacing the external btcmap.org link
A native verify/report screen that posts to the new place-report endpoint, with the verify and report actions split
Place issues on the area screen, and OpenStreetMap deep links
Opening hours summarized per weekday with today highlighted
btcmap.org place links now open in the app instead of the browser
Boosted places now appear at the top of search results

Events & Activity Feed

A dedicated event screen with deep link support
The activity feed split into Local and Following tabs, with the filter moved into a dialog
Upcoming-event badges on area icons and clickable event cards on the area screen

Documentation

I published a new documentation website: android.btcmap.org. It is fully static, so it loads instantly, and its minimalistic Material-inspired design with plenty of screenshots makes the user guides a real pleasure to read. I am genuinely happy with how it turned out.

Bug Fixes & Polish

Fixed a pile of auth session races: token encryption, 401 handling, revoking tokens on sign-out and recovering undecryptable tokens
Sped up search by reading only the fields results need
Rendered outdated merchants with reduced opacity and gray icons, and filtered the oldest ones out by default
Disabled map rotation by default, with an opt-in setting
Hardened the map against rotation and edge-case input, and bounded the area geometry cache
Restored the Carto Dark Matter style as a bundled option and fixed several marker and layout issues

API

Most of my API work this month went into areas and events. I promoted both to first-class citizens by enabling incremental sync and proper localization support, so caching clients can finally treat them the same way they already treat places and comments.

Delta Sync

I extended the v4 delta sync from places and comments to areas and events, so caching clients can pull only what changed:

GET /v4/events now accepts updated_since, limit and include_deleted, returning a change log ordered by updated_at, id. Soft-deleted rows come back only with include_deleted=true and carry deleted_at, so clients can evict them locally.
GET /v4/areas gained the same incremental mode with an AreaDelta projection that exposes the bbox but no raw tags or geometry unless geo_json is explicitly requested.
The area delta carries localized_name and localized_description, built from the name:<lang> and description:<lang> tags, so a client can localize area names without a request per language.

I also fixed a subtle bug where comment timestamps in delta sync were compared as raw text instead of instants, which could make a client skip rows.

Events

Events used to be allowed without a start date. I made starts_at mandatory (migration 119 rebuilds the table with a NOT NULL constraint) and removed the now-dead “undated events are always returned” branches from get_events, /v4/events, the area upcoming events and search.

The bigger change is timezones. create_event and update_event now accept either an RFC 3339 timestamp with an explicit offset or a floating local time plus a timezone, where auto infers the zone from the event’s coordinates via tzf-rs (DST aware). The resolved offset is echoed back so callers can verify what was inferred. The unused cron_schedule column was dropped entirely.

Search

/v4/search now matches events by name alongside places and areas, keeping the same future-or-undated filter as /v4/events. Area results carry their icon, so clients no longer need a follow-up request per row.

I also added a lang query parameter to GET /v4/areas/{id} for localized names and descriptions, and attached upcoming events to the area lat/lon search results by testing each point against the area polygon. A new GET /v4/areas/{id}/events endpoint serves the same data with an optional date window.

Place Reports, Submissions & Images

I opened the user-facing write paths on REST, since mobile apps are less privileged clients that never use RPC:

POST /v4/place-reports and POST /v4/place-submissions mirror the report_place and submit_place RPCs for signed-in users, always recording origin='user' and the caller in a new submitted_by column.
POST /v4/places/{id}/images lets signed-in users attach a photo to a place directly, and GET /v4/places/{id}/images serves them.
Place reports accept optional photo evidence (at most five photos, raster-only, size and dimension limited)

I also taught the issue sync to prefix titles with the country and community tags, and to pass raw osm:<tag> extra fields (address, payment methods) through to the paste-ready OSM tag block.

Auth

POST /v4/auth/signout now revokes the bearer token that authenticates the request, while leaving the user’s other tokens valid. It mirrors the existing RPC method, so the mobile clients can stay on REST for the whole session lifecycle.

Maintenance

Guarded sync_elements with a process-wide atomic flag, so a manual or retried call can’t start a second sync
Stopped returning soft-deleted area_element links from the v4 places and areas endpoint, with a regression test
Added more element icons and refreshed the v4 and RPC docs

CLI

event create now requires --starts-at, and event update dropped --clear-starts-at
event create and event update gained --timezone (auto or an IANA name) and dropped the old cron-schedule flags
Fixed event update clobbering fields on partial updates and expanded its options

Event Admin

Added “Clone previous event” to the add form, listing past events by distance so a new event can start from a template
Removed the cron schedule and area fields from the event form
Added an editable UTC offset (defaulting to the browser timezone for the entered date), then switched to sending timezone: auto and let the server infer the zone from the location
Auto-bump the end date when the start date passes it

Infra

Overpass

For a long time we relied on a public Overpass instance for our OpenStreetMap sync. This month it became progressively less reliable: syncs would stall, and at times we lagged OpenStreetMap by 12 hours or more. New merchants and edits took far too long to reach the map, and the instance’s reliability was entirely out of our hands.

So I set up our own Overpass server at overpass.btcmap.org and switched the sync over to it. It is not ready for public use yet, but if it holds up we might offer it to the broader community in the future.

Fleet & Maintenance

Added a README with a server fleet table (roles, IP addresses, maintenance dates) and a MAINTENANCE.md log, replacing the informal notes
Recorded maintenance sessions for gitea, lnd and umami: full system upgrades, reboot autonomy tests and SSH hardening
Added the lnd, lnbits/nostr and umami hosts to the inventory

Website

Self-service signup with a username and password, so users no longer have to accept an auto-generated account
An events section on community and country pages, fed by the new /v4/areas/{id}/events endpoint
Android app metadata, and faster beta APK downloads via the CDN
Dropped a vestigial areas and reports sync from the leaderboard pages

Future Plans

A few things on my mind:

I’ve just started a Kotlin Multiplatform shared module and a Compose Multiplatform rewrite of the UI, with a desktop app as the eventual payoff. That will dominate the next report.
Cut the next Android release once the Compose work settles.
Continue the API docs cleanup.
Finish eradicating the legacy v2 endpoints from the website.

BTC Map August Recap

Tue, 01 Sep 2026 00:00:00 +0000

Note: this only reflects my personal work this month. Visit the BTC Map Blog for consolidated monthly reports.

Thanks

Thanks to Nathanael for testing the new geofences and admin interface in Switzerland.

API

The API absorbed the bulk of my time again this month. The big theme was access control, since we need to decentralize admin work and let locals maintain their own data. A new area_manager role and a per-user geofence that constrains both area and event managers to a region they are actually responsible for.

Geofences

I added a geofence column to the user table that holds a comma-separated list of area ids. When non-empty, its behavior is role-dependent:

event_manager callers are rejected if the event’s area_id or (lat, lon) falls outside every fenced area’s GeoJSON.
area_manager callers can only mutate areas with full id match regardless of GeoJSON, so they can’t touch nested areas, and add_area call is rejected outright (admins and roots still create areas on request).
admin and root are exempt, and an empty geofence means unrestricted.

A new set_user_geofence RPC sets or clears the whitelist.

Area Manager

The new Role::AreaManager unlocks add_area, get_area, set_area_tag, set_area_image, remove_area_tag, remove_area and search.

Place Reports

I added a new fire-and-forget report_place RPC that lets trusted external sources record typed reports (verified, refused_sats, out_of_business, …) against an existing BTC Map place. It comes with a new place_report table (place_id, origin_id, extra_fields JSON, ticket_url (populated by a future background job, not user-facing), and the usual soft-delete columns).

I also added the public GET /v4/place-submissions endpoint, which exposes open, non-revoked rows from place_submission with an optional source= filter.

RPC Refactor

Most area RPCs were moved from the flat src/rpc/ into dedicated src/rpc/area/ and src/rpc/event/ submodules. It is mostly churn, but it makes the directory tree match the docs tree.

I also renamed generate_bboxes to generate_area_bboxes for consistency, and generate_element_icons now iterates every element in the database via select_updated_since(UNIX_EPOCH, ...) instead of looping over an id range.

Docs

The area RPC docs were split from a single area-methods.md into per-method files under docs/rpc/area/, mirroring the structure already used by docs/rpc/event/. Each file follows the event pattern: Description, Params, Result Format, Allowed Roles, and Examples. I also added an event RPC API index page and refreshed the main index pages.

Auth & Logging

Handlers (and the rest::auth Auth extractor) now write the resolved user id into the request extensions via AuthenticatedUser. The Log middleware reads it back so the request table records who is calling each endpoint instead of always leaving user_id NULL.

I also replaced the raw Query returned no rows error that surfaced when calling an RPC with an unknown or revoked bearer token. It’s now a friendly Invalid bearer token JSON-RPC error, with focused tests for both cases.

Electrum

A new ping_electrum_servers RPC probes every configured electrum server in parallel with the standard server.ping JSON-RPC request and reports per-server success/failure.

Each server has a 5-second timeout. The outer call never fails because of a single unhealthy server — the results just carry ok + latency_ms or ok=false + error. Allowed for admin and root roles.

Area BBox Sync

add_area and set_area_tag (when applied with geo_json) used to leave the bbox_* columns stale until someone manually ran generate_bboxes. Both paths now derive the bbox from the stored GeoJSON via the existing BboxGenerator and update the columns in the same transaction. set_area_tag also validates geo_json before persisting it.

Maintenance

Pinned the build target CPU
Fixed a pile of clippy lints
Counted only active area_elements in generate_reports (it used to include soft-deleted ones)
Filtered soft-deleted area_elements from area-scoped feeds in new_places_for_area and get_comments, with a regression test
Fixed started_at being overwritten in the generate_reports response
Cleaned up several README files

CLI

The CLI picked up wrappers for most of the new API surface:

place report calls the new report_place RPC (the old import module was renamed to place to match)
electrum-server ping wraps ping_electrum_servers with an --include-deleted flag matching get_electrum_servers
area add wraps add_area
area generate-bboxes wraps the renamed generate_area_bboxes
element generate-icons was renamed from generate-element-icons to match the new no-argument RPC signature
area generate-element-mapping was renamed from generate-areas-elements-mapping

Dashboard

I hid bots and other non-user traffic from the unique IPs pie chart on the dashboard. They were swamping the slice for actual BTC Map users.

Event Admin

Event editing is now fully wired up. The marker popup got a Rename action that swaps the event name for an inline editor (Enter to save, Esc to cancel) and calls update_event via RPC, and an Edit button that opens the full event form.

I also fixed a shadowed event variable that was preventing update_event from firing, and surfaced the real error message from the API’s error.data envelope (e.g. Location (51.5, -0.1) is outside your geofence) instead of the generic Server error.

Android

Most of my Android work this month was around build infrastructure rather than features.

Build Infrastructure

Bumped AGP to 9.3.2 and Gradle wrapper to 9.5.0
Added release signing config (previously the signing key lived in CI; it now lives in app/build.gradle.kts and the CI workflow drops its signing block)
Added a new beta build type, with a matching app deploy command in the devtools script

Dev Tools

I added a devtools helper script at the repo root that wraps the common emulator and app commands: emulator start/stop, app install/run/uninstall/deploy. The script is documented in AGENTS.md.

OpenStreetMap Attribution

Added a small “© OpenStreetMap contributors” attribution overlay to the map fragment, with a settings toggle to show or hide it.

Bug Fixes & Polish

Fixed a ConcurrentModificationException in ViewportCache by snapshotting items before serializing GeoJson when onCameraIdle fires while a previous loadInBounds coroutine is still iterating
Updated the Material Symbols font to the 2026-08-28 snapshot, switched glyphs to the outlined variant, and added a handful of new icons (18_up_rating, destruction, dresser, favorite, info, water_drop)

Ansible

I moved the API backups to a new dedicated volume.

Website

I added Skate Spots as a new BTC Map app sponsor. Nothing else.

Blog

I migrated one of my old historical BTC Map posts from this site into the official BTC Map Blog, so all of our consolidated reporting now lives in one place.

Future Plans

A few things on my mind:

Cut a new Android release.
Keep working on RPC documentation.
Continue the RPC submodule migration.
Add a dashboard widget for the place-report data once we have enough volume to make it interesting.

BTC Map July Recap

Mon, 03 Aug 2026 00:00:00 +0000

Note: this only reflects my personal work this month. Visit the BTC Map Blog for consolidated monthly reports.

Events

API

Most of my July went into the API, and most of that went into the wallet subsystem.

Wallets

I implemented wallet xpub tracking in order to improve internal transparency and observability. On-the-fly electrs queries were pretty slow, so I also had to add a cache layer. The dashboard now reads from the snapshot instead of talking to Electrum directly.

Electrum

Electrum server configuration used to be a single conf.electrum_url string. I moved it to a dedicated electrum_server table managed by four new RPCs (get_electrum_servers, add_electrum_server, update_electrum_server, remove_electrum_server), with descending priority ordering and soft deletion.

I also added a small experimental SPKI-pinned Electrum client built on rustls + x509-parser for self-hosted Electrum servers with self-signed certs.

Platform Stats

I added platform stats to the dashboard RPC. It reports which platforms hit us (Android, web, etc.) over the 1/7/30-day windows and groups calls by platform/client app name (if supplied), which is useful for prioritizing our limited resources and for anomaly detection.

Config

Boost element prices moved from three hardcoded paywall_boost_element_{30,90,365}d_price_sat columns into a single boost_element_prices JSON array, so admins can configure arbitrary boost durations.

Maintenance

I unpegged the Rust toolchain, fixed a pile of clippy 1.96 lints, and derived strum::AsRefStr on most Columns enums.

Android

The big story this month is that MapFragment is no longer a god class. It shed roughly 500 lines and is now a thin orchestrator over a handful of focused components.

Caches

I extracted MerchantsCache into its own file (with proper async query handling and bounds-split across the antimeridian), then mirrored the pattern for events and exchanges via EventsCache and ExchangesCache. All three share a new ViewportCache<T> base class that handles the initial fetch in its init block, the camera-idle follow-ups, query cancellation, and id-based deduplication.

Controllers

Four controllers were extracted from MapFragment:

MapSetupController for map style and layer setup
MapSelectionController for place/event/exchange selection
SearchController for the search overlay
LocationController (with a constructor race fixed in ViewportCache)

A new publish.sh helper was added to the repo to streamline publishing new builds.

Area Screen

Upcoming events are now displayed as clickable cards with icons in the area screen, with a dedicated background drawable. The Phuket area screen got its website URL overridden and aligned to start. One-off events are listed alongside upcoming events, with upcoming events sorted by date.

Activity Feed

Local activity feed gained filter support, so users can scope it to a specific area and period (filter icon added, menu and layout updated). Area image loading was optimized to avoid redundant network calls.

Event Admin

I started a new internal project: Event Admin. It is a small static admin site that talks to the BTC Map API and lets admins browse, rename, and edit events directly on the map. The marker popup got a Rename action that swaps the event name for an inline editor (Enter to save, Esc to cancel) and calls update_event via RPC, and an Edit button that opens the full event form.

Dashboard

Dashboard caught up to the wallet work:

Added platform stats
Added wallet stats with snapshot timestamp
Added per-wallet transaction popup
Adapted the wallets UI to the new wallet RPC shape (add_wallet/get_wallets/update_wallet/remove_wallet)

CLI

The CLI gained wrappers for the new wallet and electrum server RPCs (wallet add/get/update/remove, electrum-server add/get/update/remove), a new event update-event command, and type-specific search commands. Existing event commands were synced with the new update_event/get_events shapes.

Future Plans

A few things on my mind:

Prepare a new Android release. The MapFragment refactor clears the runway.
Keep pushing on the wallet side. New transaction notifications and more ergonomic CLI would be nice.
Continue expanding the dashboard with more of the data we already collect.
General API cleanup. The DB layer needs some love, and I also need a better taxonomy for all the RPCs we have.

BTC Map June Recap

Wed, 01 Jul 2026 00:00:00 +0000

Note: this only reflects my personal work this month. Visit the BTC Map Blog for consolidated monthly reports.

Dashboard

I started a new internal project this month: BTC Map Dashboard. It is a small static site that talks to the BTC Map API and renders the analytics snapshot from the new dashboard RPC. I kept it deliberately tiny: no bundler, no framework, no build step, just plain HTML, CSS, and a few ES modules. The goal is to give admins a quick health check without having to SSH into our servers.

Dashboard

API

The biggest chunk of my month went into the API.

Auth

I finally stabilized RPC auth flow for third party integrations:

signup is the new registration endpoint
signin issues an access token
signout revokes the current token
get_api_keys and revoke_api_key let users inspect and invalidate their active sessions
whoami returns the linked account

All non-auth RPCs now require an authenticated session. Anon access is limited to signin and signup. I also added support for scoped tokens, so the dashboard can be issued a token that can only call dashboard and nothing else.

Area Images

This is the feature I am most excited about, after the dashboard. Up to now, area icons and banners were scattered between the main DB, the filesystem, and a few half-broken scripts. I introduced a dedicated image.db table for area images, plus a new v4/area-image REST endpoint with type and dimensions hints.

Place Import Stats

Place import origins used to be hardcoded in a few Rust constants, which made it painful to onboard new wallets and merchant sources. I moved them into a dedicated DB table and exposed stats on the dashboard endpoint, including per-origin success/failure counts. A few long-dead endpoints and startup checks were deleted along the way.

Observability

The dashboard RPC now also returns log volume and counts of logged requests over the 1/7/30-day windows. A new top_rest_api_calls block lists the ten busiest REST endpoints in the last 24 hours, which is useful for spotting abuse and unintentional hot paths. I also added LND and storage stats to the same response, refactored the log queries, and started logging HTTP methods on every request.

Maintenance

I bumped geojson to 1.0, unpegged the Rust toolchain, refreshed dependencies, and added native CORS handling so we can stop relying on the reverse proxy for it. The old btcmap.db and images.db files were renamed to main.db and image.db to match the rest of the naming.

CLI

The CLI now speaks the new auth API. signin returns the token under the api_key field, signout revokes the current token. I added two area image commands (generate-area-icons and set-area-image) and a simple install script, and reorganized the command tree now that there are quite a few subcommands.

Website

The tagging-issues and leaderboard pages were still hitting now authorized-only JSON-RPC endpoints. I migrated them to the public REST API, so our website is now finally RPC-free.

Android

Local activity feed got filter support, so users can scope it to a specific area and period. I also optimized area image loading and added a dedicated activity feed icon. MapLibre and a few other key dependencies were bumped.

Ansible

Image database backups were not actually happening. I added image.db to the backup playbook, updated the snapshot script, and pruned a couple of dead helper files.

Future Plans

No exact plans, but I’ll probably be improving dashboard and working towards a new Android app release.

BTC Map May Recap

Thu, 04 Jun 2026 00:00:00 +0000

Note: this only reflects my personal work this month. Visit the BTC Map Blog for consolidated monthly reports.

Ansible

BTC Map servers are managed by different people and have no setup instructions, which makes it hard to maintain or reproduce our infrastructure. I’m trying to fix this with Ansible and have made some progress cleaning up and formalizing a few things on our main API server.

The most notable change is our API logging. We had a few discussions, and the consensus was that we should keep logs for only 30 days. Logs are valuable for debugging, but we don’t want our users to leave a permanent record, even if it’s just IP addresses and other non-personally-identifiable information.

Aside from privacy concerns, we don’t have much disk space, and keeping more data than necessary slows down our workflow. Now, 30-day log retention is automated.

Observability

On the API side, I included top user agents in the daily infra report and added a few new analytical RPCs documenting the most useful queries.

I also started working on a general admin dashboard endpoint. It may become part of our website or live as a standalone service at dashboard.btcmap.org or something.

Android

The update checker logic was tangled up with the main UI controller, which made it hard to maintain and test. I pulled it into a standalone component and added a few tests.

I also tightened up back button and gesture handling and removed a couple of shared mutable state issues that occasionally caused some annoying bugs.

Future Plans

I don’t have any specific plans or hard commitments, but I will probably focus on these three areas:

Dashboard endpoint + UI, to improve observability
Refactoring and improving the place import pipeline to onboard new wallets and other merchant sources
More infrastructure documentation and formalization to simplify maintenance and address the bus factor

BTC Map April Recap

Sat, 02 May 2026 00:00:00 +0000

Note: this only reflects my personal work this week. Visit the BTC Map Blog for consolidated monthly reports.

Activity feed

Auth

BTC Map now has opt-in authentication, and it’s a necessary step in the project’s evolution. In organic communities, admins often start as regular users, so onboarding new admins is difficult without a pool of user accounts that have built up digital reputation over time.

Another reason to sign up is the ability to save places and areas, which enables personalized activity feeds based on your locations of interest.

Activity Feeds

Looking at maps is fun, but it’s almost impossible to see what’s changed since your last visit. Maybe your city had 50 Bitcoin merchants and now it has 51. How do you find that needle in a haystack?

Solving such problems requires a temporal activity feed. The feed can be scoped to a local area or a set of your favorite places and areas. I believe this feature will improve BTC Map’s usability in a big way.

Performance

My performance work focused on improving cold start time in the Android app. Previously, it queried all places and fed them to a clustering engine, which took about a second to complete. As a result, users stared at an empty map while waiting for places to load.

The new algorithm only queries the visible area, with some safety margins, to avoid re-querying the database if the user moves the map slightly.

Website

No contributions

API

REST authentication
New endpoints for managing saved places and areas
Allow binding events to areas
Support cron-like schedules for recurring events
Support wide icons for areas
Documentation updates

Android

Implement authentication
Add saved places and areas management UI
Implement activity feed
Display upcoming events in the activity feed based on cron schedules
Filter out outdated places by default
Speed up cold start
Add area screen
Improve module isolation and composition
Increase test coverage

Future Plans

The Android app will need some polish before it’s ready for the next release, so I suspect I’ll be busy with that. There are also quite a few things to refactor and optimize on the API side, so that will be my secondary priority.

BTC Map March Recap

Wed, 01 Apr 2026 00:00:00 +0000

Note: this only reflects my personal work this week. Visit the BTC Map Blog for consolidated monthly reports.

Nearby communities

Global Direction

My focus in March was on performance, discoverability, and multi-language support.

Those things might sound random, but if you’ve ever used the BTC Map website, you probably know that some pages are borderline unusable. They can take a few minutes to load or just hang forever. Websites are not something I have a lot of experience with, but I was able to improve things on the performance front.

Performance can only get you so far if you don’t know where to look. BTC Map data is fragmented across many pages with weak or no interlinking. The best improvement I was able to deliver was showing nearby communities to users browsing the map. Many users are unaware that we offer interesting insights on local communities, and that we help communities onboard new members by showing their main contact links.

Speaking of language, only half of our users prefer English (based on browser language preference), but it was the only supported language until recently. I believe that improving language support can bring us more users, as many local bitcoiners in the place where I live aren’t comfortable using English at all.

Website

Performance-wise, I was able to speed up our leaderboards, including top editors, top countries, and top communities. Those pages now often load in under a second, even from a cold start.

There are no gains in discoverability yet, aside from showing more data on our dashboard. But it’s a good start, since it reminds us that most of our communities have missed their re-verification deadline (set to one year). We need to fix this ASAP.

I also authored a few patches improving multi-language support and added a Russian translation. Neither is perfect yet, but at least things are set in motion.

API

Most API changes I authored focused on supporting localized names and adding optimized endpoints aimed at improving website performance.

I also conducted an experiment using LLMs to translate hard-to-parse OSM working hours into a human-readable format. This feature is working fine, and I rolled it out to a few regions.

Our Overpass sync started having some hard-to-debug issues, which motivated me to improve observability in that area. Now our API saves all the important details about every Overpass sync run, whether successful or not.

I was also able to repair country flags and pave the way for storing all area images in an SQLite database, which is our medium-term goal.

Android

I finally released BTC Map Android v1.1.0, which is something I worked on since November 2025. Here are some release highlights:

Add Carto Dark Matter map style
Display current country and nearby communities on the map
Enable map rotation
Display localized place names
Improve opening hours display and translation
Improve clustering
Make adaptive color scheme opt in, default to website colors
Improve payment flow
Add support for many new languages
Improve testability and test coverage

If you’re an Android app user, I encourage you to update and leave your feedback.

Conclusion

Another productive month, but there’s still a lot of technical debt to address and new ideas to experiment with.

One thing I’ve been considering is adding a list-based activity feed alongside our default map view. Something like a social media activity feed, but scoped to Bitcoin-only activity in your area or the areas you’re watching. As a cherry on top, we could add bitcoiner event notifications there, improving discoverability by interlinking the lesser known features we offer.

BTC Map February Recap

Sun, 01 Mar 2026 00:00:00 +0000

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.db
images.db
log.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.

https://developer.btcmap.org/

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.

BTC Map January Recap

Sun, 01 Feb 2026 00:00:00 +0000

Note: this only reflects my personal work in January. Visit BTC Map Blog to get consolidated monthly reports.

Discord Is No More

I’m proud to report that BTC Map is no longer dependent on Discord. I migrated the remainder of our channels and bots to our new Matrix space.

We’ve also removed the Discord links from the landing page footer. I guess we’ll just let the old server slowly fade away.

Android Clustering

There’s been good progress on a new clustering method for the Android app. The animations feel smooth, but there’s a noticeable performance hit. I’ll keep working with this API since the old one has been deprecated by MapLibre.

Health Checks

The API health checks are working fine, but I noticed a few website health check failures. I’ve added more logging, and it looks like there are some SSL issues (curl exit code 35):

healthcheck[898007]: [111B blob data]
healthcheck[898007]: * IPv6: (none)
healthcheck[898007]: * IPv4: 75.2.60.5
healthcheck[898007]: *   Trying 75.2.60.5:443...
healthcheck[898007]: * ALPN: curl offers h2,http/1.1
healthcheck[898007]: } [5 bytes data]
healthcheck[898007]: * TLSv1.3 (OUT), TLS handshake, Client hello (1):
healthcheck[898007]: } [1554 bytes data]
healthcheck[898007]: * SSL Trust Anchors:
healthcheck[898007]: *   CAfile: /etc/ssl/certs/ca-certificates.crt
healthcheck[898007]: [2.1K blob data]
healthcheck[898007]: * TLS connect error: error:00000000:lib(0)::reason(0)
healthcheck[898007]: * OpenSSL SSL_connect: Connection reset by peer in connection to btcmap.org:443
healthcheck[898007]: [76B blob data]
healthcheck[898007]: * closing connection #0
healthcheck[898007]: curl: (35) Recv failure: Connection reset by peer

I’m not entirely sure what’s causing it, but it looks like the issue is on Netlify’s side. I’ll keep monitoring that curl call to collect more data.

Event API

Events are still an experimental feature I added for fun in the Android app. The goal is to see if there’s any organic demand for it.

I personally maintain a few events in Asia, but we were recently contacted by the guy behind BitcoinWalk, who wanted to sync our databases.

The problem was, we didn’t have an event API or event-scoped admin roles. So I built the missing endpoints, and they’re now live. BitcoinWalk is already using the new API, which is why you can see dozens of new events in the BTC Map Android app.

If you’re a web or iOS developer and want to see events on your platform, pull requests are welcome.

Payment Infra

We care about privacy, but we also don’t want spam, so we’ve spent a lot of time messing with paywalls. Our apps don’t require signups, but some stuff, like anonymous comments and boosts, will cost you a few sats. We weren’t sure if users would bite, but we’ve seen a steady trickle of paid invoices.

Our old invoicing server is a total hack job though. It’s unreliable and held together by digital duct tape. My main mission in January was to finally fix this mess.

I looked at a few options and ended up with a new server running Bitcoin Core/Knots and LND. Our old setup used the LNBits API, which was always the weakest link. The other headache was CLN, which is a maintenance nightmare. I’m a big fan of the single-binary approach (thanks, bitcoind), and LND gets that right.

The new server is live. I’ll probably keep the old one around as a backup. By routing all new invoices to the new box, I can finally poke at the old one without breaking everything.

I also wrote up my whole node setup quest in a dedicated post. I’ll probably follow up with a few more deep-dives, but this is a solid start.

BTC Map December Recap

Wed, 31 Dec 2025 00:00:00 +0000

Note: this only reflects my personal work in December. Visit the BTC Map Blog for consolidated monthly reports.

Improve Startup Time

I’m gradually moving BTC Map API chat automations from Discord to Matrix. The first experimental Matrix integration was blocking and significantly increased API server startup time (from ~2 seconds to ~10+ seconds). In December, I set up an asynchronous lazy initialization, and it seems to be working well.

Drop Boosts Table

Boosts now use the REST API and can be performed anonymously. That means it’s not a good idea to rely on the old boosts table, which is tied to admin RPC and requires specific fields like an admin user ID. It was causing issues in the internal reporting, so I decided to remove the table entirely. The generic invoice table is sufficient and is already fully integrated into our REST API. Anonymous users can request invoices for sat-walled actions like leaving a comment or boosting a merchant. Once those invoices are paid, we perform the associated actions directly, no extra tables are needed, and we can rely on invoice metadata alone.

RPC Log

We still have a few Discord hooks that fire when sensitive admin RPC calls are made. Since we’re moving from Discord to Matrix, I spent some time reviewing those ad-hoc notifications and realized our current approach doesn’t scale well.

So I created a dedicated table to log all RPC calls. This enables a few new uses. We can still monitor the log and send Matrix notifications for critical events, but it’s also a fully structured storage that we can expose via the same API. That opens a path to building our own admin web interface.

Storing the log in a structured, platform-agnostic way is a solid improvement, and it also lets us simplify the code quite a bit.

Health Checks

We’ve always had a hard time tracking whether our most critical systems were actually up. We used to rely on an external “uptime bot”, which caused constant headaches with false positives and sneaky, almost DDoS-like behavior.

I ended up writing a few scripts that probe the health of our key components. Now if something goes down, the script can send a notification straight to Matrix.

Organize RPC Calls

The rpc module is a mess, so I spent time cleaning it up. The work is far from done, but at least there’s progress!

BTC Map November Recap: Steady Growth, Challenges, and Community Contributions

Sun, 01 Dec 2024 00:00:00 +0000

Dev Updates: Stability, Observability, and Performance

November was a relatively quiet month, with a focus on addressing technical debt and resolving performance bottlenecks in the BTC Map backend. No other development activities related to BTC Map were reported.

Admin Updates: Growing Areas Backlog

Rockedf continues to manage our places backlog efficiently, with no tasks left unhandled. However, the areas backlog continues to grow due to limited admin activity.

South Africa - 410 changes
Brazil - 220 changes
Italy - 116 changes
Thailand - 107 changes
Switzerland - 67 changes

South Africa led the way with the most changes, primarily focused on data updates. Brazil added nearly 100 new places and re-verified many existing ones. Italy saw significant data quality improvements due to dedicated maintenance efforts. Thailand’s changes were driven by a new local community. Switzerland experienced a minor data quality improvement, mostly related to a local ATM network.

Bitcoin merchant in Thailand.

A big thanks to Rockedf for contributing to almost every region!

Bitcoin Amantikir - 92 changes
Bitcoin Witsand - 79 changes
Bitcoin Cape Town Monthly Meetup - 50 changes
Bitshack - 35 changes
FREE Madeira - 33 changes

Bitcoin Amantikir achieved a flawless 100% up-to-date rating through dedicated efforts. Bitcoin Witsand maintained its high rating, solidifying its position as one of Africa’s top Bitcoin hubs.

Global Metrics

Verified merchants increased by 1.3% to 7,055, continuing the upward trend.
Total merchants grew by 3.2% to 12,689, double the long-term trend.
The average verification age increased by 4% to 357 days, slightly reducing data reliability.

New merchant additions are at an all-time high, but maintaining up-to-date records remains a challenge. The main bottleneck continues to be the lack of local maintainers.

Conclusion

Overall, progress is positive, but we need to address the following key issues:

Many locations are outdated, and we need additional maintainers to verify merchant status and Bitcoin acceptance.
We aim to highlight top-performing merchants to improve discoverability. Comments are currently unavailable on our iOS app and website due to a lack of active developers. We welcome contributions from anyone with relevant skills.

The best way to help is by re-verifying outdated locations in your area.

BTC Map Monthly Recap - October 2024

Fri, 01 Nov 2024 00:00:00 +0000

Merchant Comments

I released merchant comments API last month, and I was busy integrating it in our Android app. Here are my key observations:

Comments are a solid quality indicator, so I decided to show the number of comments on map pins, making it super easy to discover the highest quality merchants
Comments are extremely valuable, they often contain useful tips and warnings, and they also mention discounts and promotions
Comments are currently our best source of data on real user activity. Areas without comments are suspicious, so we can use comment data to identify fake or abandoned areas

Map markers with the number of comments

Vector Maps

We had some good progress on switching to open source vector map dataset, powered by OpenFreeMap. After some initial discussions and tests, we decided to go ahead and roll out vector maps in the coming weeks. OpenFreeMap is a really cool project, our users can even self-host their own map data provider by following the official instructions.

Brazil - 309 changes
Netherlands - 202 changes
Italy - 154 changes
Spain - 130 changes
El Salvador - 84 changes
South Africa - 80 changes
Kenya - 77 changes
Slovakia - 77 changes
Germany - 66 changes
United States of America - 61 changes

Top 5 countries are well-known bitcoiner hubs, but South Africa and Kenya never showed up in our top trending countries list. Something might be brewing there, but only time will tell.

Big thanks to Rockedf for contributing to almost every region!

Porto Alegre Bitcoin - 89 changes
Bitcoin Dada Nairobi - 77 changes
The Core - 77 changes
Arnhem Bitcoin City - 58 changes
Einundzwanzig Portugal - 56 changes
Einundzwanzig Schweiz - 44 changes
Bitcoin Association Switzerland - 44 changes
Free Madeira - 44 changes
Dezentralschweiz - 44 changes
De Bitcoin Meetup - 41 changes

Porto Alegre vent from 60% up-to-date to 100% up-to-date, thanks to Go BTC contributions.

Global Metrics

The number of verified merchants has increased from 6,747 to 6,935 (+2.8%), reversing previous month-on-month decline. It looks like we’re able to keep ~7,000 merchants up-to-date, and we need more local maintainers if we want to bump those numbers.

The total number of merchants has increased from 11,842 to 12,222 (+3.2%), which is ~x2 our long-term trend. The stream of new merchants is stronger than ever, but we’re just struggling to keep some of them up-to-date.

The average number of days since the last verification has increased from 340 to 344 (+1.2%), which means that our data is slightly less reliable than it was a month ago. This is yet another confirmation that our main bottleneck is the lack of local maintainers.

Conclusion

Things are looking good overall, and I think that we need to focus on the following issues:

There are many outdated locations, we need more maintainers who can contact those merchants and verify that they are still in business and still accept sats
Some merchants are just better than others, we need to make the best ones more discoverable. Comments is a good first step but there are many other things we can do to highlight our rockstar merchants!
Our iOS and Web apps need some love, it would be cool to onboard more devs who can fill the feature gap and fix some known bugs

The best way to help us is to re-verify some outdated locations in your area, if you have any:

https://btcmap.org/map?outdated

BTC Map Monthly Recap - September 2024

Tue, 01 Oct 2024 00:00:00 +0000

Merchant Comments

I extracted about 900 valuable comments from our verification reports and I exposed them via BTC Map sync API. Comments turned out to be extremely valuable since they often add important context to certain Bitcoin merchants. The next steps are client app support and automating new comments.

Feed Reader Support

Some people are only interested in new places or comments in their areas, so they don’t want to install our apps and check them all the time. BTC Map data is open, and we never intended to lock users in, that’s why I created a few experimental Atom data feeds. Let’s say you want to get notified of new places and comments in the Netherlands, so now you can just add the following feeds to your feed reader of choice:

https://api.btcmap.org/feeds/new-places/nl

https://api.btcmap.org/feeds/new-comments/nl

Of course, you can mix and match any number of BTC Map areas, communities and countries alike. Web feed links are always available on our website, in area activity section.

RPC Interface

Most of our administrative tasks are now centralized, which means that processing new change requests might take a long time, depending on how busy we are. This model can’t scale, that’s why we’re building an admin API, alongside GUI and CLI tools which can be used to simplify access to many local administrative tasks. There is no ETA on that, but I think we’ll be able to delegate most tasks to local community managers pretty soon.

Netherlands - 190 events and comments
Italy - 173 events and comments
Germany - 169 events and comments
Spain - 101 events and comments
Portugal - 98 events and comments
El Salvador - 95 events and comments
United Kingdom - 83 events and comments
Brazil - 78 events and comments
Switzerland - 77 events and comments
Czechia - 74 events and comments

Many merchants in the Netherlands were re-verified by Comino, which shows that a single maintainer can keep the whole country up to date. Having a single maintainer per country would allow us to keep the whole world up to date, so if your country has some old and outdated merchants, we need your help!

Italian re-verification effort can mostly be attributed to mpbin. This user not only re-verified many existing places but also added some missing general tags such as contact details and so on. Those tags are extremely valuable, so even if your area is up-to-date, you might want to check if you have enough contact details for every merchant. This account apparently belongs to Bitcoin Italia Network, and it looks like they’re taking ownership over the whole region.

Germany’s data was enhanced by many different accounts, but 65% of German locations are still outdated, so this country needs more love from local editors. Spain continues to be in a good shape, thanks to descubrebitcoin efforts, and Portugal data quality continues to improve, thanks to Sxajne.

Big thanks to Rockedf for contributing to almost every region!

Satoshi Spritz - 176 events and comments
Einundzwanzig Deutschlan - 169 events and comments
Einundzwanzig Portugal - 98 events and comments
Einundzwanzig Schweiz - 78 events and comments
Bitcoin Association Switzerland - 77 events and comments
Dezentralschweiz - 77 events and comments
Bitcoin Berlin - El Salvador - 60 events and comments
Free Madeira - 51 events and comments
Berlin 2140 - 48 events and comments
Einundzwanzig Berlin - 48 events and comments

Global Metrics

The number of verified merchants has dropped from 6,867 to 6,734 (-2%), which means that we’re struggling to keep more than 5-7 thousands of places up-to-date, and we need more contributors who can re-verify outdated merchants.

The total number of merchants has increased from 11,685 to 11,833 (+1.3%), which is in line with our long-term trend. The stream of new merchants has no signs of tapering, we’re just struggling to maintain the old ones in certain regions.

The average number of days since the last verification has increased from 323 to 340 (+5.3%), which means that our data is now significantly less reliable than it was a month ago. This is yet another confirmation that our main bottleneck is the lack of local maintainers.

Conclusion

Our main issue is growing number of outdated locations, and getting more maintainers can take some time. It’s not the only way to improve BTC Map though, so we can focus on highlighting the best quality merchants, which I’m intending to be busy with during October. I have a few ideas on using different quality signals, and it might make sense to simply mark or hide outdated or unreliable merchants.

The best way to help us is to re-verify some outdated locations in your area, if you have any:

https://btcmap.org/map?outdated

BTC Map Monthly Recap - August 2024

Sun, 01 Sep 2024 00:00:00 +0000

Merchant Reviews

I bet most bitcoiners are aware of the concept of revealed preferences, and we noticed that many BTC Map users are abusing our merchant verification form and leave place reviews instead of short notes on how they verified a merchant in question.

Here is a couple of examples:

How did you verify this?

I went and got my haircut after hearing about the adoption that was happening here in Arnhem. There was the business owner and one of his employees. The employee didn’t know that they accepted bitcoin but luckily since the owner was there - he assured him that they do. Mission success for a haircut and a shave.

How did you verify this?

The level of customer service of this restaurant is excellent 10/10

We have hundreds of reviews like the ones above, and it’s clear that many bitcoiners want to share their experience and add some context to certain locations. Since those reviews aren’t properly organized, it will take some time to extract old reviews from our archives and make them public. As a next step, I think we should add a dedicated review button with a Lightning paywall in order to filter out spam reviews.

Brazil - 173 changes
Netherlands - 101 changes
Italy - 84 changes
Australia - 67 changes
Czechia - 52 changes
Germany - 50 changes
Portugal - 45 changes
Suriname - 42 changes
United States of America - 32 changes
United Kingdom - 27 changes

Brazil is keeping its lead in Bitcoin adoption with 36 new and 121 re-verified places. It has 1,062 Bitcoin merchants in total, and 729 of them have been recently verified.

Netherlands is one of the first centers of Bitcoin adoption, with a famous Arnhem Bitcoin City, which have been boosting Bitcoin adoption since 2014. It looks like August was a busy month in the Netherlands, and now it has 50 more Bitcoin merchants.

Italy is a big country with many Bitcoin-accepting merchants, but most of them are outdated, so we can’t be certain that all the data is reliable. Italian bitcoiners are working on solving this issue, and they were able to re-verify 71 merchant in August.

Big thanks to Rockedf for contributing to almost every region!

Bitcoin Island Philippines - 97 changes
Satoshi Spritz - 87 changes
Bitcoin é aqui! Rolante/Riozinho-RS-BRASIL - 81 changes
Einundzwanzig Deutschland - 51 changes
Einundzwanzig Portugal - 45 changes
Free Madeira - 29 changes
Einundzwanzig Schweiz - 21 changes
Dezentralschweiz - 21 changes
Bitcoin Association Switzerland - 21 changes
Bitcoin Sydney - 17 changes

Bitcoin Island Philippines has many outdated locations, and most of them no longer accept bitcoins. Removing outdated merchants is very important, thanks ctboss for cleaning this region in August!

As you can see, we only have 10 communities with 17 or more changes during the last 30 days, which is concerning. We clearly need to find more ways to reach out to unmaintained communities and encourage them to keep their data up to date and onboard more merchants.

Global Metrics

The number of verified merchants has dropped from 6,900 to 6,879 (-0.3%), which means that we need more contributors if we want all the regions to stay up-to-date. We’re talking about ~20 additional verifications a month, which can be done even by a single dedicated contributor.

The total number of merchants has increased from 11,532 to 11,687 (+1.3%), which is in line with our long-term trend. The stream of new merchants has no signs of tapering, we’re just struggling to maintain the old ones in certain regions.

The average number of days since the last verification has increased from 309 to 322 (+4.2%), which means that our data is now significantly less reliable than it was a month ago. This is yet another confirmation that our main bottleneck is the lack of local maintainers.

Conclusion

Merchant adoption has no signs of slowing down, and we’re working on providing BTC Map users with all the relevant tools to discover and maintain their local Bitcoin merchant data. I believe that collecting and displaying place reviews can help us highlight the best places and give users more confidence in our data set.

The best way to help us is to re-verify some outdated locations in your area, if you have any:

https://btcmap.org/map?outdated

BTC Map Monthly Recap - July 2024

Tue, 13 Aug 2024 00:00:00 +0000

I didn’t post for a while due to an unexpected trip to Russia, but now I’m back in Phuket and here are my thoughts on BTC Map progress in July.

Events + Areas

There are a few important events which can happen to a BTC Map merchant, namely:

Creation
Edit
Boost
Deletion

That’s the basic lifecycle of any merchant. Unfortunately, it wasn’t possible to associate a specific event with a specific BTC Map area, which limited our analytics. I was busy with removing this limitation during the last couple of weeks, and now we can easily rank different areas such as countries and communities by the number of important events. I think it’s the best way to find trending areas for a specific time period.

So, let’s use this new capability to see what was trending in July:

It’s nice to see some good progress in Italy, and Brazil is still one of the most active countries on BTC Map. Most edits in Austria were authored by descubrebitcoin, and they seem to be ATMs. There is also a notable re-verification effort by Bitcoinshire in the United Kingdom.

Most of the new places in Japan belong to COCOROTUS FOODTRUCK and I have no idea what it actually is, but they mentioned us on their website. Georgia is still exceptionally well-maintained, thanks to empty_child, and United States is slowly picking up steam, which is long overdue.

Big thanks to Rockedf for contributing to almost every region!

Satoshi Spritz 176
Einundzwanzig Deutschland 64
Bitcoin Austria 57
Tokyo Citadel 45
Bitcoin Association Switzerland 33
Einundzwanzig Schweiz 33
Dezentralschweiz 33
Porto Alegre Bitcoin 31
Einundzwanzig Portugal 30
Bitcoin Bulgaria 23

Global Metrics

The number of verified merchants has dropped from 7,188 to 6,918 (-3.7%), which means that we need more contributors if we want all the regions to stay up-to-date. We’re talking about ~300 additional verifications a month, which can be done even by a single dedicated contributor.

The total number of merchants has increased from 11,215 to 11,521 (+2.8%), which is in line with our long-term trend. The stream of new merchants has no signs of tapering, we’re just struggling to maintain the old ones in certain regions.

The average number of days since the last verification has increased from 288 to 308 (+7%), which means that our data is now significantly less reliable than it was a month ago. This is yet another confirmation that our main bottleneck is the lack of local maintainers.

Conclusion

We were able to improve our analytics, and we have a better understanding of the current trends on BTC Map. While the total number of Bitcoin-accepting merchants keeps growing at a consistent pace, we’re struggling with re-verification of our existing merchants, which is supposed to be done at least once a year.

The best way to help us is to re-verify some outdated locations in your area, if you have any:

https://btcmap.org/map?outdated

BTC Map Weekly Recap

Sun, 19 May 2024 00:00:00 +0000

Help Needed: Delivery

Enabling you to spend sats in your local shops is our core mission, but it would be wrong to limit your shopping options while many remote shops offer nationwide and global delivery. The most important thing to understand about BTC Map, is that it’s only as good as its data and its community. So, let’s take a look at our delivery data:

https://overpass-turbo.eu/s/1LH0

There are less than 100 places with a delivery tag, most of them being cafes and restaurants, so there is noting to show to BTC Map users yet. I’m pretty sure there are thousands of places which can send you all kinds of stuff for sats, we just need to find them and tag them, and we need your help. All you need to do is to add this tag to the places you know, and we’ll take care of showing those places in our web and mobile apps.

Key Metrics

The number of verified merchants has dropped by 54, which means we’re struggling to support more than ~7,000 up-to-date merchants globally. In order to stay reasonably up-to-date and reliable, a place needs to be re-verified at least once a year, so let’s do some simple math.

How many places do we need to verify daily in order to have 7,000 verified places every year? 7,000 / 365 ~= 20. If the number of verified places is dropping, it means we don’t have enough contributors to verify at least 20 places daily, on average. Let’s hope that this situation will improve in the near future.

The total number of merchants has increased by 73, which is in line with our long-term trend. The stream of new merchants has no signs of tapering, we’re just struggling to maintain the old ones.

The average number of days since the last verification increased from 268 to 270, which means that our data is now slightly less reliable than it was a week ago. This is yet another confirmation that our main bottleneck is the lack of local maintainers.

What’s Next: Kotlin Multiplatform

While BTC Map is available on iOS, our iPhone app lacks many important features and performance updates, and this feature gap will only widen with time. The reason is simple: we don’t have any permanent iOS devs, and we can’t be certain that this issue will be resolved any time soon.

Luckily, we have a reasonably up-to-date web app, which works on every platform, but web apps are lacking certain features which are eiter very valuable or absolutely critical to us, namely:

BTC Map should not require a server, centralization is both risky and expensive
BTC Map should not require you to trust us, but you can’t avoid trusting us if you blindly fetch any HTML and JS which our server sends to your browser tab
It’s not even our server, the web app is hosted on Netlify
We need to minimize and tightly control any network transfers
We want our code to be easily inspectable and digitally signed by the devs or third-party distributors such as F-Droid
Native apps are closer to hardware, which leads to better performance, all else being equal, which is especially important on low-end hardware

There are many other reasons to have native apps, but there are also reasons to have a web app:

Not having enough contributors on certain platforms, our iOS situation is the latest example
Our native apps are aimed at regular users, and they’re optimized for small screens. The web app can do that too, but power user / community admin features is where it stands out
Redundancy is extremely important. It’s not too far-fetched to assume that our native apps can be banned by App Store and Google Play, so it’s important to have additional options

We believe that the best way forward is to try merging our Android and iOS code bases as much as possible, which should make it easier to support them and even introduce new platforms such as desktop or PinePhone. Kotlin Multiplatform seems like our best bet since our Android code base is in a good shape, and it can be gradually refactored in a platform-agnostic way.

Unlike many other cross-platform options, Kotlin Multiplatform doesn’t force us to sacrifice app performance, and we can keep using native UI components of every target platform in order to have the best look and feel and a responsive UI.

I’ve been busy building a multiplatform database layer recently, and I stumbled upon a few issues, but they aren’t critical, so we’ll continue with this effort, and hopefully we’ll be able to have feature parity between all the native platforms in the long run.

BTC Map Weekly Recap

Sun, 12 May 2024 00:00:00 +0000

API V3

BTC Map always had an offline-first architecture, meaning that you don’t need an Internet connection in order to see all the bitcoin-accepting merchants in your area or even globally. Our users are the only real owners of their apps and their copies of BTC Map data, they can keep it forever and there is nothing we can do to change that.

That said, fetching the recent changes and updates is often desirable, as well as downloading new map tiles to cover more regions. BTC Map API is strictly read only, and it’s sole purpose is to provide the most recent changes to all the interested users. Keeping all the data locally has its price, and the storage and transfer requirements are growing together with global Bitcoin adoption.

API V3 is our latest attempt to optimize the size of the data which needs to be transferred in order to keep your data snapshot up to date. My tests are showing 30% reduction in data transfers, so you only need to fetch ~3 KB a day in order to stay up to date. It shouldn’t be a big deal even if you’re using Tor or a chain of VPN servers.

Key Metrics

The number of verified merchants has increased by 60, which is a significant improvement both in terms of quality and quantity. Most locations were verified by Rockedf and the local mappers.

Here are the top 5 countries by the number of new merchants:

Brazil
Australia
South Africa
Switzerland
El Salvador

The total number of merchants has increased by 39, which is slightly below average. The main reason is Argentina data cleanup, it had many outdated merchants so their removal boosted our signal-to-noise ratio in that region.

The average number of days since the last verification decreased from 269 to 267, which serves as another confirmation of our improving data reliability. I expected no change, so I once again underestimated the local mappers.

What’s Next: Delivery

The problem: many users are living in areas with a low number of local bitcoin-accepting merchants. While this number is growing steadily, life is short, and people want to build circular economies and escape the fiat system ASAP.

The solution: we need to identify all the merchants who offer either nationwide or global delivery, which would significantly expand the choice of goods and services available to an average BTC Map user. Of course, distance requires trust, and that’s one of the reasons we don’t support pure services with no physical location. If you made an order, and you aren’t happy with the result, it shouldn’t be possible for a merchant to avoid any responsibility. Please note that we can’t really guarantee that all locations are real, the final judgement call is on you, you should carefully investigate merchants before making remote orders and sending your sats God knows where.

What’s Next: Improving Resilience

BTC Map client apps are pretty resilient already, but they tend to depend heavily on the following components:

Tile servers (for rendering maps)
BTC Map API (for merchant data updates)

In light mode, the app uses OSM tile servers, and we’re also hosting Stadia Maps tile server in case you’re joined the dark side. It would be cool to give the users more choices, as well as to allow setting their own tile server URLs. We can’t embed the tiles into the app, because a full tile set would require terabytes of storage, so the second-best thing is to let the users choose their own tile servers, in case the default options aren’t available or aren’t desirable for some reason. Some people may even prefer to self-host their own map tiles, self-hosting is not uncommon among hardcore bitcoiners who value their privacy and don’t want anyone to know which map regions they viewed.

Our API is fully open source, so you can also self-host your own instance, if you feel like it. While you can do it by recompiling the app, it’s better to let users change their API URL in settings.

BTC Map Weekly Recap

Sun, 05 May 2024 00:00:00 +0000

New Feature: Data Bundling

It’s hard not think about building resilient software in the light of the recent events, that’s why we decided to include the most recent data snapshots with every new BTC Map release. In short, if our servers go down, for whatever reason, you won’t be affected. It’s also impossible to censor us via Google Play, since the app is available on F-Droid, GitHub, and it can also be built from the source.

Data bundling also speeds up the initial sync by an order of magnitude!

New Feature: Companion App Warnings

You only need a Lightning wallet in order to pay to the vast majority of our merchants, but there are two exceptions:

Czech Republic (Querko restaurants)
South Africa (Pick n Pay supermarkets)

Some of the places do require a third party companion app in order to generate BOLT 11 invoices, so you need to install those apps if you want to pay with bitcoins. Usually, we don’t tolerate that, but perfect is the enemy of good, and we decided to accept them on the following conditions:

The app should generate a real Lightning invoice, payable with any LN wallet of user’s choice
KYC is not acceptable under any circumstances

Those places didn’t have proper warnings, so I fixed it in the latest release:

New Feature: Navigate to Merchant

Building routes is hard, that’s why we aren’t doing it. You need to know a lot of things, including traffic jams, accidents, planned roadworks and so on. I know it well because I used to work for a taxi company which operated in London. Still, many users want to be able to quickly navigate to a selected merchant, so I decided to delegate this task to an external app. Most of the solutions on StackOverflow were dependent on Google Maps, but there was an interesting solution which seems universal. It appears to be working, but we’ll need more testing and user feedback to confirm that.

I don’t know why I waited so long, but it seems to be a must-have feature. As a power user, you don’t really miss it, since you can always open a place on OSM and see the nifty-gritty details, but it’s not a good way of sharing a bitcoin-accepting place with your friends.

Key Metrics

The number of verified merchants has increased by 41, half of the last week’s number. Most locations were verified by Rockedf and the local mappers.

Here are the top 5 countries by the number of new merchants:

Brazil
Spain
Germany
Czech Republic
The Netherlands

The total number of merchants has increased by 8, which is unusually small. The main reason is Boracay data cleanup which was done by a Pouch team. They had many outdated merchants so their removal boosted our signal-to-noise ratio in that region.

The average number of days since the last verification didn’t change, which means that our data is as reliable as it was a week ago. I expected a decline since I didn’t do any mapping, but it looks like the locals are finally starting to maintain their own data, which reduces our dependency on remote edits done by a few of our team members.

What’s Next: Syncing in Adverse Conditions

Next week, I want to focus on our server software and infrastructure. The main goal is to release a v3 API, which is supposed to improve sync speed and lower the bandwidth requirements. Users like snappy software, but the real driving factor is the ability to make our API usable via TOR and other privacy preserving overlay networks. Even a normal VPN can slow down your network connection to the point where every byte counts, so it makes sense to make our API as lightweight as possible.

BTC Map Weekly Recap

Sun, 28 Apr 2024 00:00:00 +0000

New Merchant Notifications

Adding your shop to BTC Map will now notify all the users within a 100 km radius, so they’ll be able to discover your shop in no time. As a user, don’t forget to send us your feedback when you visit new places, it’s very important to us, and we often boost the most trusted and popular places for free, so your feedback is a good way to support BTC Map merchants. We also have a few shady and unreliable places, but we can’t remove them unless we have a report from a local user, so both positive and negative user feedback regarding our locations is the best way to support BTC Map and help your fellow bitcoiners.

Legacy Data Is No More

This week concludes the end of my ancient data verification push. My goal was to re-verify all the places which were added before the latest BTC Map restart (September 2022).

Some users might not know that, but BTC Map existed since 2015, and it even featured a bunch of shitcoins. I stumbled upon coinmap.org back in 2015, and I really liked the idea. I think coinmap was made during some hackathon in Eastern Europe, so it was probably done in a rush, and then it was quickly abandoned. I did some basic reverse engineering and I figured out that coinmap just fetched the data from OSM, and then it got out of sync and started to rot. Lesson learned, it’s better not to fork OSM datasets, unless you want to maintain the whole world by yourself.

Taking an “add whatever you want, I don’t care” stance on shitcoins was a mistake, and onchain Bitcoin transactions didn’t really fit the retail use cases, so the project was quickly abandoned, and it was also too boring to do that alone. I regained my interest in promoting Bitcoin as a medium of exchange in spring 2022, after some experimentation with the Lightning Network. This time it wasn’t just an Android app, there are many other components which are created and maintained by other bitcoiners from different parts of the world. Hopefully, I’ll be able to gradually disappear and focus on the other, more technical bottlenecks in Bitcoin infra, but I feel like our core team is still too small and fragile to do that safely, so I’m not going anywhere unless I’m confident that the project won’t fade away after losing a couple of active contributors.

Key Metrics

The number of verified merchants has increased by 81, which is about the same as last week. Most locations were verified by Rockedf and me, but we also had a significant number of verifications made by the locals.

Here are the top 5 countries by the number of new merchants:

Italy
Brazil
United Kingdom
Germany
France

The total number of merchants has increased by 66, which is a healthy trend.

The average number of days since the last verification dropped from 271 to 268, which means that our data is slightly more reliable now. This is a global average, and regional data reliability can vary. You can always find your community or a country in order to check the local trends.

What’s Next: Decentralized Data Ownership

I believe we built enough tools to enable locals to take control of their regions. From now on, I will limit my global edits and focus on maintaining Thai merchants since I’ve been living here for 10 years, and it’s my current country of residence. Thai data is in a good shape already, but I want to learn more about all the merchants and there are many other useful tags except currency:XBT which need to be surveyed.

Since we still don’t have enough editors, I expect many regions to disappear from the map in the long run, and I don’t really see it as a problem. We gave them everything to kickstart their regions and get a feel of the future, now it’s up to them.

The future is already here – it’s just not evenly distributed. ― William Gibson

BTC Map Weekly Recap

Sun, 21 Apr 2024 00:00:00 +0000

Data quality remains the main bottleneck, followed by the discoverability of the new merchants.

Key Metrics

We added 93 verified merchants, which is about the same as last week. Most locations were verified by Rockedf and me, but we also had a significant number of verifications made by the locals.

Most of the new places are located in Brazil, Italy and Germany.

The total number of merchants dropped by 112, mostly due to my re-verification of extremely outdated merchants. It certainly boosted our signal-to-noise ratio.

The average number of days since the last verification dropped from 307 to 272, which is a very significant improvement. In the long run, this metric will become our key data health indicator, but we need to deal with the remaining outliers first.

Extreme Outliers

We still have some ancient places, and it’s our biggest problem. The date of the oldest verification was December 2017 in the end of last week, and now it’s April 2021.

Android App: Background Sync

Background sync is working reliably, and it will be included in the next Android app release. I hope the Web and iOS clients will follow. The app should always show you the latest data as fast as possible, no matter how long you were absent.

What’s Next: Local Activity Notifications

BTC Map doesn’t have any tracking capabilities, which is extremely rare for a modern app. We don’t know how many users we have, and we know nothing about our users. Our server is read-only, which means that we can send you new data if you ask us for it, but we never send any data back to the server.

Most notifications are initiated by the server, but we can’t do it, since we aren’t using Google or Apple notification infrastructure, and we don’t even know where to send those notifications, because the recipient address is user data, and we don’t store user data.

It is also possible to send a notification from the local app itself, so, while we don’t have your private data, the app on your phone can have it and can use it to notify you. If you granted BTC Map your GPS location access, it doesn’t mean our servers have it. In fact, your location will never leave your device, and you can verify it yourself by examining the source code. Since the app can know your location, it can notify you of new merchants nearby, if it finds them during the background sync. That’s what I’ll focus on next week.

BTC Map Weekly Recap

Sun, 14 Apr 2024 00:00:00 +0000

I’m not a big fan of mapping, but some things just need to be done. Once we attract more local editors, I’ll be able to focus on a more technical stuff, but data quality is the main bottleneck at the moment.

Key Metrics

We added 102 verified merchants, which is two times more than we added during the last week.

The total number of merchants dropped by 64, mostly due to my re-verification of extremely outdated merchants. It certainly boosted our signal-to-noise ratio.

The average number of days since the last verification dropped from 354 to 315, which is a very significant improvement. In the long run, this metric will become our key data health indicator, but we need to deal with the remaining outliers first.

Extreme Outliers

We still have some ancient places, and it’s our biggest problem. The date of the oldest verification was April 2015 in the end of last week, and now it’s December 2017.

Outdated Merchants

It’s a really nice feature introduced by secondl1ght:

https://btcmap.org/map?outdated

Opening this link allows you to see all the outdated merchants around you. It’s very handy for anyone who wants to verify their local merchants. We are trying to make it as easy as possible for people to take ownership of their local data.

In Progress: Background Sync

Every time you open BTC Map, it needs to download all the changes since your last visit. The overall sync performance depends on how long you were absent, and the quality of your Internet connection. That’s not really a big deal, but it doesn’t allow us to interact with the users asynchronously. Let’s say someone added a new bar in my area, but I won’t know about that until I open BTC Map again. Having a background sync would make sure that I will be able to see all the new places immediately after opening the app, but it also clears the patch to asynchronous notifications.

In Progress: Local Activity Notifications

We’ll start with notifying the users of any new bitcoin-accepting merchants nearby, but it’s just the beginning. We want to decentralize map editing, which means that the locals should be in charge of their data. For instance, we can create an opt-in notification channel which will notify local maintainers of any new issues with their data. It would also allow them to remove all the spam and scam promptly.

We can also make boosts more appealing by notifying the users of newly boosted places. Boosts aren’t really a significant source of money for BTC Map, but they also act as a proof that a merchant is serious about accepting bitcoins and that it has a functional Lightning wallet.

Igor Bubelov

BTC Map October Recap

Table of Contents

Android

Compose Multiplatform

Desktop App

Packaging

Notes

Events & Submissions

Admin & Moderation

Map Work

Beta Updates

Dev Tools

API

Notes

Place Images

Event Review

Areas

Users & Access

Dashboard

Maintenance

Docs

CLI

Ansible

Future Plans

BTC Map September Recap

Table of Contents

Thanks

Android

1.2.0 Release

Offline First

Places & Reports

Events & Activity Feed

Documentation

Bug Fixes & Polish

API

Delta Sync

Events

Search

Place Reports, Submissions & Images

Auth

Maintenance

CLI

Event Admin

Infra

Overpass

Fleet & Maintenance

Website

Future Plans

BTC Map August Recap

Table of Contents

Thanks

API

Geofences

Area Manager

Place Reports

RPC Refactor

Docs

Auth & Logging

Electrum

Area BBox Sync

Maintenance

CLI

Dashboard

Event Admin

Android

Build Infrastructure

Dev Tools

OpenStreetMap Attribution

Bug Fixes & Polish

Ansible

Website

Blog

Future Plans

BTC Map July Recap

Table of Contents

API

Wallets

Electrum

Platform Stats