Previous post

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.