Flag protected nanopublications, and say when the services are restricted or unavailable

[tkuhn]

Two related things a Nanodash instance never said out loud: what kind of deployment it is talking to, and when that deployment cannot answer. Both surface in the title bar, one commit each.

Protected nanopublications and restricted services (#671)

Registry 1.12.0 and Query 1.26.0 accept and serve nanopubs typed npx:ProtectedNanopub when configured as local/private instances, and nanopub-java 1.94.0 exposes both facts to clients (Nanopublication/nanopub-java#143, #144, #145).

• A protected nanopub gets its own 🔒 flag next to its ID. Until now NanopubUtils.getTypes picked the type up from the publication info and NanopubItem rendered it as an ordinary grey type tag — indistinguishable from a domain type, and linking to a listing of everything else that happens to be protected. The type is now left out of the tags; the publication info still shows the underlying triple, since the flag replaces the tag, not the RDF.
• ServiceMode probes both services once at startup — the registry through RegistryInfo.isLocalInstance(), the query service through its Nanopub-Query-Local-Instance response header — and a 🔒 restricted marker says when either is local. It is a property of the instance, not of a page, so it shows on all of them. A service that cannot be reached reads as "not restricted": the marker is additional information and must never keep the interface from working.

A note when a service cannot answer (#681)

QueryCall admits a query instance only when it reports READY or LOADING_UPDATES, and ServerIterator skips a registry that is not ready/updating. When nothing is admitted, every query-driven part of a page fails separately with a bare API call failed. and nothing says why. ServiceHealth now watches both and the title bar says it once.

A service that is still loading and one that cannot be reached get different wording, because what the reader should do differs: the first passes by itself, the second is an outage. The check runs on its own scheduled thread, since health changes while an instance runs; request threads only read the last answer, keeping the probes off the request path (#600). A state that could not be established stays UNKNOWN and shows nothing.

Verification

Built a local/private stack for this — Registry 1.12.1 with REGISTRY_LOCAL_INSTANCE=true and Query 1.28.0 with NANOPUB_QUERY_LOCAL_INSTANCE=true, mirroring the public network (89,433 nanopubs) — and drove Nanodash against it:

• A protected nanopublication signed with a throwaway key published to the local registry and read back, still protected. The same publication attempt against the public registries is refused by nanopub-java without contacting them for anything but their info, as intended.
• Both markers render: 🔒 restricted in the title bar, 🔒 protected on the nanopub, with no ProtectedNanopub type tag left.
• The health note appeared while the query service was doing its initial load, and cleared by itself within one check interval of it becoming ready:

  13:20:30  query UNKNOWN -> LOADING,  registry UNKNOWN -> HEALTHY
  13:22:01  query LOADING -> HEALTHY,  registry HEALTHY -> HEALTHY
  

Full suite: 1285 tests, 0 failures, 0 errors. New tests cover isProtected (including the type sitting outside the publication info, which does not count), the type-tag exclusion, the rendered flag, the mode probes, and the note wording for each state.

Two findings this turned up, filed separately

• Persistent API cache is shared across deployments: results from a restricted stack are served by a public one (and vice versa) #682 — the persistent API cache is keyed by query and parameters alone, with a fixed path per home directory, so a restricted deployment and a public one share it. Protected content cached from a local stack is read back by an instance pointed at public services. Not fixed here.
• With a cold cache and no healthy query service, NanodashSession's constructor throws in UserData and every page 500s, the error page included — which also defeats the note in this PR, since nothing renders. Pre-existing; not filed yet.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LqfrG3VXH5tzWXPvYJzXML