Add a Sites tab with real cache/freshness indicators

[JamesM92]

Why

Columba's four root destinations today are Chats, Contacts, Map, and Settings (confirmed against AppDestination.kt) — there's no dedicated place to browse NomadNet sites at all, and Map holds a full tab slot for a feature that's genuinely useful to some users but not a daily driver for most.

NomadNetPageCache also has no fetch-status awareness today — get() returns a markup string or null on a plain TTL, with no signal to the caller or the user about whether what's showing is fresh or up to 12 hours old.

Below is a proposed shape for both, along with a few implementation details worth getting right the first time rather than discovering the hard way.

1. What a Sites tab is for

A single, dedicated place to browse NomadNet content — not a byproduct of Network/Contacts, and not competing for tab-bar space with a map feature few people open daily. Concretely: cached content renders instantly on every visit, an automatic live check quietly confirms or corrects it behind that instant paint, a clear status — on both the open page and the list itself — always says what actually happened rather than leaving the user to guess, and getting to a page takes one tap, not a detour through diagnostic detail.

The sections below lay out each of those pieces. The last one makes the case for where this should actually sit in the tab bar — worth reading in that order, since the positioning argument only really lands once it's clear what it's being made for.

Populating the list itself isn't a new discovery mechanism — the same announce stream Contacts/Network already tracks, filtered to site-type (nomadnetwork.node) announces specifically.

2. Pair the cache with an automatic live check — not just a manual one

Columba already gets two things right here: cache-first display, and a pull-to-refresh gesture that forces a real fresh pull. Neither of those needs to change. What's missing is the check that happens without being asked for — pull-to-refresh covers the case where a user deliberately wants a fresh pull, but every open of a cached page should also, quietly and automatically, attempt a live pull behind that instant cached paint. The two aren't redundant: one is a user-initiated override, the other is the app keeping cache and reality from silently drifting apart on its own.

Why this matters, concretely, not just as a freshness nicety:

• A cache with no automatic live check has no way to ever self-correct. Content that changed, a reply that arrived, a status that flipped since the last visit — all stay invisible indefinitely unless the user specifically remembers to pull-to-refresh. Most users won't; they'll just act on whatever's on screen, unaware it might already be wrong.
• It breaks identity/session correctness specifically — this is the sharp edge, not a footnote. NomadNet has no cookies. A visitor's identity/session travels either as remote_identity (proven per-link, tied to the live Reticulum request itself) or as a session token embedded directly in the link's own parameters (see the field/link-parameter model in NomadNet's app-auth conventions). A cache keyed only on page path is blind to both — it has no way to know the visitor's identity state changed since the page was fetched, and if the link just followed carries a fresh session token, showing the cached response instead of making the real request means that token never reaches the server at all. The concrete failure this produces: navigate an identity-gated site, go through an identify/share-identity step, then follow a link to a page fetched earlier — a cached, pre-identity copy renders instead of a fresh request, so the page looks logged out again even though identity was just shared seconds earlier, with no automatic path back except the user happening to know to pull-to-refresh.
• The cost of checking is close to zero from the user's side. It doesn't block or delay anything they're already looking at — it runs behind the instant cached paint. There's effectively no downside being traded for the upside of correctness.
• It removes a judgment call the user shouldn't have to make. Deciding "do I trust this cached page, or should I pull to refresh" on every single page open is real, easy-to-skip friction. An automatic background check means the app carries that judgment continuously, instead of asking the user to remember to.

Concrete rule: any link carrying an identity- or session-affecting parameter, and any navigation immediately following an identify/login action, should trigger this automatic check without exception — that class of request isn't safely left to a manual pull alone.

3. Give the automatic check a visible language of its own

An automatic check that runs invisibly is the right default, but "invisible" can't mean "the user has no way to tell what's happening" — the moment its outcome actually matters (confirming the page is current, or surfacing that a check failed), it needs to show up as something small and unobtrusive, not a modal, not a full-page reload flash, and not silence. The four states below are that visual language: each is a distinct, low-key on-screen signal mapped to exactly one moment in the check's lifecycle, so a user can tell what's happening at a glance without it ever competing with the page content itself.

flowchart TD
    A[Open a site] --> B{Cached before?}
    B -- No --> C["Looking up for the first time\ncenter-screen loading wheel"]
    C --> G["First-time lookup failed\nreal empty/error state, no cache to fall back on"]
    B -- Yes --> D["Cached page shown instantly\nsmall wheel at the top — live check running"]
    D --> E["Live check failed\nred circle / × — still showing cached page"]
    D --> F["View is live\ngreen circle — confirmed current"]

Loading

• Looking up for the first time — center-screen loading wheel. Nothing cached yet; this is the one moment the user actually waits.
• Cached page shown, live check running — small wheel at the top, not blocking the content already on screen.
• Live check failed — red circle/×. Still the cached page on screen, now marked as unconfirmed this visit.
• View is live — green circle. The check succeeded; what's on screen is confirmed current, not just a cached guess.
• First-time lookup failed — a distinct case from the two above: there's no cached content to fall back on at all, so this isn't a red badge over a rendered page, it's a real empty/error state on its own — the direct on-page counterpart to the list's "Never loaded" row.

A common pitfall worth flagging directly: a cancelled fetch isn't a failed one. Navigating away mid-fetch throws a cancellation — if that's caught by the same handler as a genuine network failure, every quick back-navigation gets misreported as a failed pull. Cancellation needs its own branch, separate from an actual failure.

4. A real fetch-status indicator, on the sites list itself

Four states worth distinguishing per row — not just success/failure, and no timestamp needed to tell them apart. Each maps to one plain fact about visit history:

State	Meaning
Unvisited	You haven't visited this site before.
Working	You've visited before, and it was working the last time you checked.
Cached · offline	You've visited before and it loaded successfully at some point, but the last attempt didn't work.
Never loaded	You've tried this site before, but it has never worked.

A binary success/failure model collapses two genuinely different situations into one: a site that's never once been reachable, and a site that's unreachable right now but has loaded successfully before. Those need different affordances — "this has never worked" vs. "here's what loaded last time, but it's not answering right now." Shown as a small colored dot per row, consistent across the list and the open page.

5. One tap to view, not two

This is the actual point of a Sites tab existing at all, distinct from Contacts' own list of every known peer and announce — fewer steps to get to a page, for the person who just wants to read it.

Today, tapping a site entry surfaces its details (hop count, interface, raw announce data) rather than the site itself. That's the right default in Contacts — it's a technical/diagnostic surface, and someone browsing it is often specifically looking for that information. But it means viewing a page starts with an extra, unwanted stop: tap an entry, land on its details, then find and tap again to actually open the page — real friction for someone who has no interest in the details and just wants to read the site.

Sites should behave differently by design, not just by being a separate filtered list: tap a row, land directly on the rendered page, nothing in between. Keep the richer technical detail (interfaces, hops, raw announce data) exactly where Contacts already surfaces it well — that stays the right home for it, just not the default path for someone who only wants to browse. (Section 6 makes the case for renaming this tab to Network — its diagnostic role is exactly the reason.)

6. Rethink the tab bar around what each tab is actually for

Given everything above, here's where it should all actually sit:

• Sites replaces Map's tab slot. NomadNet site browsing gets a real destination alongside the rest of the app — it's what most users will reach for far more than a map; sites are how NomadNet content actually gets consumed.
• Map becomes an opt-in feature, enabled from Settings rather than occupying a permanent tab for everyone. It also reads as a more honest footprint for a feature that's meaningfully heavier than the rest of the app in storage and setup (per the offline-tile-rendering planning docs already in the repo).
• Rename Contacts → Network. It already functions as a network analyzer, not a personal address book — hop count, interface, raw announce data, dozens of entries most users will never open individually. The name should say what it actually is.
• Move favorites out of that shared hub and into the tab that actually uses them. A frequently-messaged contact's shortcut belongs in Chats; a frequently-visited site's shortcut belongs in Sites — each tab keeps its own favorites list natively, rather than routing two entirely different everyday workflows through a third tab just to reach a shortcut. Network stays the right home for full technical detail on everyone and everything known — it just stops being the forced detour to get to either kind of favorite.

[torlando-tech]

Upcoming release will lay the foundation to customize the tabs you want, including a nomadnet tab. This isn't everything you asked for, but it's a start.

If you want a more dedicated nomadnet browsing experience, RenBrowser is already great