v0.7.0

Feature release: three links into the mesh instead of one, and Nostr peer discovery as an opt-in. Installs in place over any earlier release via the automatic update prompt, Check for updates, or sideload — identity, settings and app data are kept.

Changes since v0.6.1

• Fallback bootstrap peers (Settings → Bootstrap peer, on by default). The node used to have exactly one link — the bootstrap server you picked — and everything else was routed through it, so that server going down meant no mesh until it came back. It now also peers with two more public servers in other regions (test-uk01 and test-us01 alongside the default test-de01), so one outage does not take the mesh with it. Each extra link is one short heartbeat every 20 seconds (10 with Battery saver off).
• Configured peers are re-found through Nostr. Every configured peer now carries via_nostr: its static address is dialed first, and the endpoints it advertises on the relays are appended as fallback, so a bootstrap that moves to a new address is found again without a settings change.
• Discover peers via Nostr (Settings → Connectivity, off by default). Turns on fips's open discovery — linking to nodes that announce themselves on the relays, not only the bootstraps — but capped at three such links, freshest announcements first, through a new fips knob written for this (open_discovery_max_peers: a ceiling on the discovered pool as a whole, where fips's own setting only bounded the queue and a phone would have gone on collecting links up to 128). Honest caveat, also on the Settings page: on the public test mesh most announcements are from nodes that no longer answer an offer, so expect fewer than three — in the maintainer's runs on an emulator and a Pixel, the cap held and none of the three picks answered. It stays off by default for that reason.

The embedded fips daemon moves to android-hooks @ f4a811e (the discovery ceiling and the address-family fix from 0.6.1). No dependency changed; THIRD-PARTY-NOTICES.md is unchanged.

Known issues

• After the mesh reconnects itself — a mesh-app or relay change, a !FIPS hotspot joining or leaving, an IPv6 route change — the link to a peer can take ~15 s to come back even though Overview already shows Connected. Under investigation; seen since 0.5.0.
• Peers listed in Diagnostics still show npubs, not the mesh names you gave them.

Install

Sideload the APK matching your device (adb install -r or open it on the phone); min SDK 26 (Android 8.0). Verify the download against the matching .sha256, or update from within the app.

• universal — all three ABIs in one file. Installs anywhere; larger. Use this if unsure.
• arm64-v8a — every 64-bit ARM phone from roughly 2016 on; the device-verified build.
• armeabi-v7a — old 32-bit phones. Compiles and packages; not exercised on real 32-bit hardware.
• x86_64 — Android emulator, Chromebooks.

Release APKs are signed with the key whose certificate SHA-256 is
aa905e32bd0058874d252990abba26c78ddd8fca018195ebd1cd232a99a7a8e1 — check a
fresh download with apksigner verify --print-certs <apk>. This matters most on a
first install: there is no previously installed signature for Android to
compare against, so the checksum and this fingerprint are the only things
identifying a genuine build. Subsequent updates are enforced against the key
automatically.

Caveats

Only arm64-v8a is exercised on real hardware. This release's arm64 APK was installed in place over the previous build on a Pixel 9 Pro (Android 17) and connected with the three bootstrap links as designed. The discovery toggle was exercised on the same phone on a pre-review build of the same change: it held its cap of three while none of the picked nodes answered; the two changes since (a bookkeeping fix in the daemon, text and constant changes in the app) are covered by tests and were checked on the Android 14 emulator. armeabi-v7a compiles and packages but has not been run on a 32-bit device; x86_64 is emulator-verified.