Talebound

The trip is when you have something to write down. It's also when you have no signal, no laptop, and a phone at 12%. Talebound is built for that gap.

What it is

Talebound is an offline-first travel journal. Entries, locations, photos, and voice notes are captured to a local database on the device with no network in the loop. When connectivity comes back, your devices reconcile with each other. One person, several devices, no audience.

The architecture is deliberate about which copy is the truth. The app reads and writes a local SQLite database — that's what the UI renders, always, online or not. The server is a replication peer, not a data source. Postgres is authoritative only for reconciliation: a global sequence and a trigger stamp every write with a monotonic version, and the sync protocol resolves offline divergence with last-write-wins on updated_at.

What it does well

Nothing is silently dropped. When two devices edit the same entry offline, one write wins the merge and the other is preserved as a visible conflict copy. You resolve it, or you don't — but you're never told about a version that quietly disappeared.

The UI never waits on a network. Because the local database is the source of truth for display, there is no spinner state that depends on a tower. Sync happens in the background and shows its state in a badge.

Capture built for the moment, not the desk. Photos, GPS coordinates, and voice notes attach to entries as you go. The story gets written where it happened, not reconstructed three weeks later from a camera roll.

Single-user, multi-device. No sharing model, no followers, no feed. The sync protocol only has to reconcile you with yourself, which is why it can be simple enough to trust.

Who it's for

Long-trip travelers — thru-hikers, sabbatical takers, anyone whose trip outlasts their data plan.

People who have tried to journal in a notes app and ended up with 200 untitled fragments and no locations attached to any of them.

Anyone who has lost a trip's worth of writing to an app that assumed it could reach a server.

What it looks like in practice

Somebody two days into a backcountry stretch writes an entry, tags the location from the phone's last GPS fix, and records a thirty-second voice note about the weather. None of it touches a network. Four days later, at a trailhead with one bar, the sync engine pushes everything up and pulls down the two entries written on the tablet at home. Same story, both devices, no reconstruction.

What it's not

It's not social. There's no sharing surface, no feed, no follower graph.

It's not a cloud service you rent access to your own memories from. The server exists to move data between your devices.

It's not multi-user. The sync model is single-user by design, and that constraint is what makes the conflict handling tractable.

Pricing (planned)

| | | |---|---| | Free | Local journaling, unlimited entries, one device | | Talebound Sync | Multi-device sync, media backup |

Status

Server foundation and sync protocol are complete and tested — POST /v1/sync/push, GET /v1/sync/pull, ASP.NET Core Identity endpoints, health checks, and a Testcontainers-backed test suite running against real Postgres. The Flutter app has shipped its auth gate, journals, entry capture, and a live sync badge, with Keycloak-issued tokens validated server-side. Media storage on Cloudflare R2, search, and geocoding are the next plans. Tech: .NET 10 minimal API + Postgres (pgvector) + Flutter with drift/SQLite, deployed by Docker Compose behind a Cloudflare tunnel.