fips_setup/plans/fips-browser-extension-possibilities.md

FIPS Browser Extension — Possibilities Discussion

Context

FIPS uses Nostr keypairs (secp256k1) as node addresses. Browsers access FIPS sites via .fips hostnames (e.g., npub1abc...xyz.fips) that resolve to fd00::/8 IPv6 addresses through a local FIPS DNS resolver on port 5354. Traffic is encrypted with Noise IK (hop-by-hop) + Noise XK (end-to-end), but browsers see plain HTTP and show "Not Secure" warnings.

nos2x is an existing browser extension that provides Nostr signing via a window.nostr API. Since FIPS uses the same secp256k1 keypairs, a nos2x-based extension could serve double duty: Nostr signing + FIPS features, sharing one keypair.

This document explores everything a FIPS browser extension could do, grouped by problem domain.

---

Problem 1: DNS Resolution for .fips Domains

The Problem

Chromium-family browsers use their own DNS resolution path that bypasses the system resolver. Even when dig, getent, ping, and curl all resolve .fips correctly, Chromium shows ERR_NAME_NOT_RESOLVED. Firefox works because it follows the system resolver path. Current workaround is pinning .fips hostnames in /etc/hosts, which is manual and fragile.

What the Extension Could Do

Option A: webRequest DNS interception

Use the webRequest API to intercept requests to *.fips domains before they hit the browser's DNS resolver. The extension resolves the hostname itself (either by querying the local FIPS DNS on 127.0.0.1:5354, or by computing the IPv6 directly from the npub) and redirects the request to the resolved IPv6 address.

• Pros: Works without modifying browser DNS settings; portable
• Cons: webRequest is being restricted in Manifest V3; may need declarativeNetRequest instead; URL bar still shows .fips which is good, but the connection goes to the IPv6

Option B: proxy API with custom PAC script

Use the proxy API to provide a Proxy Auto-Config (PAC) script that matches *.fips domains and routes them through a custom proxy handler. The extension resolves the .fips name and connects directly to the IPv6 address.

• Pros: Clean separation; PAC scripts are well-supported
• Cons: More complex; need to handle the proxy connection logic

Option C: Direct npub → IPv6 computation in the extension

Since the npub → IPv6 derivation is pure computation (npub → public key → SHA-256 → node_addr → fd00::/8 IPv6), the extension could compute the IPv6 address directly without any DNS query. The extension parses the npub1...fips hostname, decodes the bech32 npub, hashes it, and derives the IPv6 address.

• Pros: Zero network dependency for resolution; works even if FIPS DNS isn't running; instant
• Cons: Only works for direct npub addresses (npub1xxx.fips), not friendly hostnames (mysite.fips); friendly hostnames still need a lookup against /etc/fips/hosts or the FIPS DNS resolver

Option D: Hybrid — compute for npub addresses, query for friendly hostnames

Combine Option C with a DNS query fallback. For npub1*.fips, compute the IPv6 directly. For other *.fips names, query the local FIPS DNS resolver on 127.0.0.1:5354 (or a configurable remote address).

• Pros: Best of both worlds; npub addresses always resolve; friendly names work when FIPS DNS is available
• Cons: Slightly more complex implementation

---

Problem 2: Security Indicators — "Not Secure" Warning

The Problem

FIPS traffic is encrypted with double-layer Noise protocol encryption (IK hop-by-hop + XK end-to-end), but the browser sees plain HTTP to an IPv6 address. The URL bar shows "Not Secure," which is misleading — the traffic is actually more encrypted than standard TLS.

What the Extension Could Do

Option A: Toolbar badge/icon

Show a custom toolbar icon that changes state based on whether the current page is a .fips site. When on a .fips site, show a green "FIPS" badge or lock icon. Clicking it shows a popup explaining the FIPS encryption (Noise IK + Noise XK, end-to-end encrypted, mesh-routed).

• Pros: Simple, reliable, no browser security model conflicts
• Cons: Doesn't change the URL bar "Not Secure" text; users have to notice the badge

Option B: Page-level banner/indicator

Inject a content script that adds a small banner or corner badge on .fips pages showing "FIPS Encrypted" with details on hover. Similar to how the Tor Browser shows onion circuit information.

• Pros: Visible on the page itself; can show rich detail
• Cons: Can be spoofed by page content (though extension can verify the URL is .fips first); visually intrusive

Option C: Local TLS proxy (MITM approach)

Run a local proxy within the extension (or a companion native app) that terminates TLS for .fips domains. The extension generates self-signed certificates for .fips hostnames on the fly and installs them as trusted. The browser sees HTTPS with a valid cert; the proxy handles the actual FIPS connection underneath.

• Pros: Browser shows the green lock; proper HTTPS UX
• Cons: Complex; requires native messaging component; certificate trust management is fragile across browsers; security implications of MITM; may conflict with browser security policies

Option D: Custom protocol handler (fips://)

Register a custom protocol handler for fips:// URLs. Instead of http://npub1abc.fips, users would use fips://npub1abc. The extension handles the protocol, resolves the address, and displays the content. The browser wouldn't show HTTP security warnings because it's not HTTP.

• Pros: Clean separation from HTTP; no "Not Secure" issue; distinct UX
• Cons: Links and bookmarks need to use fips://; not all browser APIs work with custom protocols; may have rendering limitations; breaks compatibility with existing .fips HTTP URLs

Option E: Badge + popup with circuit details (Tor Browser style)

Combine Option A with a detailed popup that shows the FIPS "circuit" — which peers your traffic is routing through, the encryption layers, the destination npub, and the mesh path. Modeled after Tor Browser's circuit display.

• Pros: Educational; builds trust; shows real security information
• Cons: Requires access to FIPS daemon routing info; more complex

---

Problem 3: Nostr Signing (nos2x Feature Parity)

The Problem

Nostr users need a signing extension to interact with Nostr applications (signing events, encrypting/decrypting messages). nos2x provides this via window.nostr API. Since FIPS uses the same secp256k1 keypairs, the extension should provide this functionality too.

What the Extension Could Do

Full nos2x parity:

• Inject window.nostr object into web pages
• Implement the NIP-07 API: getPublicKey(), signEvent(), getRelays(), nip04.encrypt(), nip04.decrypt(), nip44.encrypt(), nip44.decrypt()
• Prompt user to approve/reject signing requests (popup with event details)
• Maintain a whitelist of sites allowed to request signatures

FIPS-specific signing:

• Sign FIPS authentication challenges (prove you own the npub that a FIPS service expects)
• Sign FIPS peer introduction messages
• Use the same keypair for both Nostr and FIPS identity — your window.nostr public key IS your FIPS node address

Multi-identity support:

• Manage multiple keypairs (different Nostr/FIPS identities)
• Switch between identities per-site
• Each identity has its own npub, .fips address, and IPv6

---

Problem 4: FIPS Identity Management

The Problem

Users need to generate, import, and manage their FIPS keypair. Currently this is done via command-line scripts (03-configure-identity.sh). The extension could provide a GUI for this.

What the Extension Could Do

• Generate new keypair — Create a new secp256k1 keypair; show the npub, .fips address, and IPv6
• Import existing nsec — Import a Nostr private key to use as FIPS identity
• Export keypair — Backup your private key (with encryption/password protection)
• Display identity info — Show your npub, .fips address, IPv6 address, and QR codes for sharing
• Multiple identities — Create and switch between multiple FIPS/Nostr identities
• Identity linking — Show that your Nostr identity and FIPS identity are the same key

---

Problem 5: FIPS Node Status and Monitoring

The Problem

Users need to know if their FIPS node is running, connected to peers, and reachable. Currently this requires fipstop TUI or fipsctl CLI. The extension could show this in the browser.

What the Extension Could Do

• Connection status — Show if the local FIPS node is running and reachable
• Peer list — Show connected peers, their npubs, aliases, and transport types
• Mesh status — Show network size, your tree depth, routing coordinates
• Your address — Show your npub, .fips hostname, and IPv6 address
• Health alerts — Notify if FIPS node goes down, peer count drops to zero, etc.
• Traffic stats — Show bytes sent/received over FIPS mesh

Implementation: The extension would communicate with the local FIPS daemon via its control socket/API (same API that fipsctl uses). This could be via HTTP, WebSocket, or a native messaging port.

---

Problem 6: FIPS Hosts Management (Friendly Hostnames)

The Problem

Friendly .fips hostnames (like mysite.fips) require entries in /etc/fips/hosts on the visitor's node. This is a manual command-line operation. The extension could provide a UI for managing these mappings.

What the Extension Could Do

• View host mappings — List all friendly hostname → npub mappings
• Add/edit/remove mappings — GUI for managing /etc/fips/hosts entries
• Auto-add from Nostr — If a Nostr profile lists a FIPS address, auto-suggest adding it to hosts
• Bookmark .fips sites — Save and organize .fips sites you visit
• Share host mappings — Export/import host mapping lists
• Sync via Nostr — Publish your host mappings as a Nostr event so followers can import them

Implementation: The extension would need to either (a) write to /etc/fips/hosts via native messaging, or (b) maintain its own host map and use it for DNS resolution (combining with Problem 1's hybrid approach).

---

Problem 7: FIPS Address Detection and Linkification

The Problem

When someone shares a FIPS npub address in a web page, chat, or Nostr note, it's just text. Users have to manually copy it and construct a .fips URL. The extension could make npubs clickable.

What the Extension Could Do

• Detect npubs on pages — Scan page content for npub1... patterns and .fips URLs
• Linkify npubs — Convert npub1abc... text into clickable links to http://npub1abc.fips
• Context menu — Right-click an npub to open it as a .fips site, copy the .fips URL, or add to hosts
• QR code generation — Generate QR codes for .fips addresses for easy sharing
• Omnibox support — Type an npub directly in the address bar and have it resolve to the .fips site

---

Problem 8: FIPS Content Discovery

The Problem

There's no directory of FIPS-hosted services. Users have to know the npub of the node they want to visit. The extension could help users discover FIPS content.

What the Extension Could Do

• FIPS directory — Maintain a curated or crowd-sourced list of known FIPS services (websites, relays, git servers, etc.)
• Nostr integration — Use Nostr events to discover FIPS services (e.g., a NIP that publishes "I host a FIPS service at npub X")
• Bookmarks — Pre-populate with known FIPS services from the project
• Search — Search across known FIPS services by name, type, or npub

---

Problem 9: Gateway/Proxy for Non-FIPS Users

The Problem

Only people running a FIPS node can access .fips sites. This limits the audience. A gateway could let non-FIPS users access FIPS content through a public FIPS node.

What the Extension Could Do

• Gateway routing — Route .fips requests through a public FIPS gateway node when no local FIPS node is detected
• Gateway selection — Let users choose a trusted gateway (or run their own)
• Trust indicators — Show whether you're accessing FIPS directly (full encryption) or through a gateway (gateway sees traffic)
• Fallback mode — Automatically fall back to gateway mode when local FIPS node is down

Caveat: Gateway access breaks the end-to-end encryption promise — the gateway operator can see traffic. This should be clearly communicated. This is similar to how Tor has entry nodes vs. running your own relay.

---

Problem 10: Mixed Content and Resource Loading

The Problem

A .fips web page might load resources (images, scripts, CSS) from the regular internet, creating a mixed content situation. Some resources are FIPS-encrypted, others are not.

What the Extension Could Do

• Mixed content indicator — Show what percentage of page resources are FIPS vs. clearnet
• Resource list — Show which resources loaded over FIPS vs. regular internet
• Upgrade to FIPS — If a resource is available over FIPS (same npub), automatically upgrade the request
• Block non-FIPS resources — Option to block all non-FIPS resources on .fips pages for maximum privacy

---

Problem 11: FIPS Peer Management

The Problem

Adding FIPS peers currently requires command-line scripts (08-add-peer.sh). The extension could provide a GUI for peer management.

What the Extension Could Do

• View peer list — Show configured peers with their npub, alias, transport, and connection status
• Add/remove peers — GUI for adding new peers (npub + transport address)
• Peer discovery — Discover peers via Nostr (e.g., people publishing their FIPS node address in Nostr profiles)
• Bootstrap peers — One-click add of known bootstrap peers
• Peer health — Show latency, packet loss, and uptime per peer

Implementation: Via native messaging to the FIPS daemon, or via the FIPS control API.

---

Problem 12: Qubes OS Integration

The Problem

In Qubes OS, the browser runs in an AppVM while FIPS runs in sys-fips ProxyVM. The extension in the AppVM browser needs to communicate with the FIPS node in a different VM.

What the Extension Could Do

• Cross-VM status — Show FIPS node status from sys-fips in the AppVM browser
• Qubes-aware DNS — Handle the Qubes DNS forwarding path (AppVM → sys-fips dnsmasq → FIPS DNS)
• VM health — Show if sys-fips is running and properly chained
• Auto-configure — Detect Qubes environment and configure DNS resolution accordingly

---

Problem 13: Nostr-FIPS Crossover Features

The Problem

Since FIPS and Nostr share the same keypair, there are natural crossover features that neither system alone provides.

What the Extension Could Do

• Nostr profile → FIPS address — When viewing a Nostr profile, show their FIPS .fips address and offer to visit it
• FIPS site → Nostr identity — When visiting a .fips site, look up the npub on Nostr and show their Nostr profile, posts, and relay list
• Verified identity — Cross-verify: the FIPS node you're connected to proves it owns the npub, and the Nostr profile proves the same npub — therefore the FIPS site is authentically operated by that Nostr identity
• Nostr relay over FIPS — Connect to Nostr relays hosted on FIPS nodes (e.g., ws://npub1abc.fips) with the extension handling both the FIPS connection and Nostr signing
• FIPS service announcements via Nostr — Publish and consume Nostr events that announce FIPS services (kind: FIPS service descriptor, content: service type, npub, port)

---

Architecture Considerations

Manifest V2 vs V3

• webRequest blocking is restricted in Manifest V3 (Chrome). Firefox still supports it with some changes.
• declarativeNetRequest is the MV3 replacement but is less flexible.
• For DNS interception, the proxy API may be more future-proof.
• Firefox supports both MV2 and MV3; Chrome is MV3-only.

Native Messaging

Some features (writing to /etc/fips/hosts, communicating with FIPS daemon, managing system-level config) require native messaging — a companion native app that the extension communicates with via stdio.

• Pros: Full system access; can talk to FIPS daemon directly
• Cons: Requires installing a native component; not portable to all platforms; more complex setup

Shared Keypair Architecture

The keypair is the foundation. The extension should:

1. Store the private key securely (browser extension storage, encrypted)
2. Derive everything from it: npub, .fips address, IPv6 address
3. Use it for both Nostr signing and FIPS identity
4. Optionally sync with a hardware signer (NIP-46, Nostr Connect)

Communication with FIPS Daemon

Options for talking to the FIPS daemon from the extension:

• HTTP API — If FIPS exposes a control API on localhost
• WebSocket — If FIPS exposes a WebSocket control interface
• Native messaging — Companion app that talks to FIPS daemon
• File-based — Read /etc/fips/fips.yaml, /etc/fips/hosts, /etc/fips/fips.pub directly (via native messaging)

---

Summary: Feature Priority Map

Feature	Problem Solved	Complexity	Impact
DNS resolution for .fips	Chromium can't resolve .fips	Medium	Critical — nothing works without this
Security indicator badge	"Not Secure" warning is misleading	Low	High — user trust
Nostr signing (nos2x parity)	Nostr app interaction	Medium	High — core feature for Nostr users
Identity management GUI	Key management is CLI-only	Medium	Medium — convenience
Node status monitoring	No visibility into FIPS state	Medium	Medium — operational
Hosts management GUI	Friendly hostnames are CLI-only	Low	Medium — convenience
npub linkification	npubs aren't clickable	Low	Medium — UX improvement
Content discovery	No way to find FIPS sites	High	Medium — ecosystem growth
Gateway for non-FIPS users	Only FIPS users can access	Very High	High — adoption, but breaks E2E
Mixed content handling	Partial encryption visibility	Medium	Low — edge case
Peer management GUI	Peer management is CLI-only	Medium	Low — operational
Qubes integration	Cross-VM communication	High	Low — Qubes-specific
Nostr-FIPS crossover	Identity verification, discovery	High	High — unique value proposition

---

Open Questions for Discussion

1. Which of these features feel most essential vs. nice-to-have?
2. Is the gateway/proxy approach (Problem 9) worth exploring, or should we focus on users who already run FIPS?
3. How much of this should be in the extension vs. a companion native app?
4. Should we target Firefox first (better webRequest support, system DNS) or Chrome/Chromium first (bigger user base, worse DNS behavior)?
5. Is the Nostr-FIPS crossover (Problem 13) a compelling enough unique feature to prioritize?
6. Should the extension try to replace the FIPS DNS resolver entirely (computing npub → IPv6 in the extension), or work alongside it?