wiretap v0.2.15

wiretap v0.2.15

This release launches Wiretap's Starlight documentation site and clarifies the
relay project-reassignment command.

Documentation website

The new Astro Starlight site organizes Wiretap documentation around complete
tasks: installation, local traffic capture, receiving a first webhook,
request composition, transforms, relay hosting and administration, desktop
customization, configuration, CLI reference, limits, and troubleshooting.

Historical release notes remain in the repository. Superseded performance
investigations and duplicate top-level guides have been removed now that their
durable user guidance lives in the site.

Relay CLI flag

wiretap relay projects reclaim now accepts --client-id instead of
--new-client:

wiretap relay --url https://relay.example.com --admin-token TOKEN \
  projects reclaim project-a --client-id CLIENT_ID --force

Update automation that used the previous flag name.

Full changelog: v0.2.14...v0.2.15

wiretap v0.2.14

wiretap v0.2.14

This release adds first-class application themes to the desktop workbench and modernizes syntax highlighting without weakening Wiretap's large-payload safeguards.

A workbench that follows you

Choose an application theme from Settings > Interface > Application theme. The selection applies immediately and is saved locally for that desktop.

Included presets:

• System follows the operating system's light or dark appearance.
• Wiretap Dark keeps the original charcoal and mint workbench.
• Wiretap Light provides a clear, low-glare light appearance.
• Nord uses an arctic blue palette.
• Catppuccin Mocha provides a soft pastel dark palette.
• Catppuccin Latte provides the corresponding light palette.

Themes cover the complete application rather than recolouring only the page background. Navigation, panels, request and response inspectors, settings, dialogs, form controls, status indicators, CodeMirror, and payload syntax now share semantic design tokens. Text size and row-density preferences continue to work independently.

Lighter syntax highlighting

Compatible webviews now use the vendored Microlighter 2.1.0 runtime for JSON, JavaScript, HTML/XML, CSS, YAML, TOML, and GraphQL. It uses the CSS Custom Highlight API, keeping the payload as a single text node instead of inserting a DOM span for each token.

Older webviews degrade safely to Wiretap's existing JSON span highlighter or plain text. Syntax colours are driven by the active application theme in both implementations.

Large payloads remain bounded

Range-based highlighting reduces DOM overhead, but parsing and tokenizing a multi-megabyte structured document can still monopolize the UI thread. Testing with https://models.opencode.ai/api.json confirmed a valid 4,640,280-byte JSON payload and reproduced that cost.

Wiretap therefore retains:

• the 100 KiB syntax-highlighting limit;
• the 256 KiB initial body preview;
• progressive Show more loading; and
• the single-text-node plain-text renderer for large captures.

This keeps the inspector responsive while preserving explicit copy, save, and incremental inspection controls.

Documentation and development

• Added a dedicated theming guide covering preset architecture and extension points.
• Documented the Microlighter compatibility fallback and large-payload policy.
• Pinned the Tailwind CLI as a development dependency and exposed the reproducible npm run css build command.

Verification

The release was validated with the full Go suite, GUI-tagged tests, a production GUI build, frontend module syntax checks, a production dependency audit, and visual inspection across dark and light theme families.

Full changelog: v0.2.13...v0.2.14

wiretap v0.2.13

wiretap v0.2.13

This patch makes Linux credential storage follow the desktop's configured
Secret Service default collection.

The default collection is authoritative

Wiretap now uses ByteNess/keyring for native credential storage. On Linux,
Wiretap first calls Secret Service's standard ReadAlias("default") method,
validates the returned collection path, and passes the resolved concrete name
to ByteNess. This means the desktop configuration—not an application-specific
assumption—decides where credentials live.

Wiretap no longer:

• prefers a collection merely because it is named login;
• treats its wiretap service name as a collection name; or
• creates a new collection when the configured default already exists.

Relay-admin and client credentials continue to share the wiretap service and
remain isolated by distinct item keys inside the operating-system collection.

Existing client migration remains available

The existing protected-file migration is unchanged. If
relay-credentials.json contains a plaintext client_token, the first load
tries to store it in the resolved default keyring. After a successful write,
the file is rewritten with only the client identity, projects, and opaque
keyring reference. If the keyring is unavailable, the mode-0600 file remains
the fallback so the relay client can continue operating.

Wiretap deliberately does not inspect or copy credentials from other keyring
collections. A token saved by v0.2.12 in a separate login collection should
be re-entered or restored through the protected credentials file before that
collection is removed. Saved relay-admin profiles should be saved again after
connecting with their admin token.

Verification

The Linux integration suite resolves the live default alias, performs a full
Set/Get/Delete round trip, confirms the item exists in that exact collection,
and asserts that the collection inventory does not change. Unit coverage also
validates encoded collection names such as Default_5fkeyring.

Full changelog: v0.2.12...v0.2.13

wiretap v0.2.12

wiretap v0.2.12

This patch fixes Linux keyring persistence for saved relay-admin profiles and
consolidates all Wiretap secrets under one predictable service.

One Wiretap keyring service

Relay-admin tokens and the desktop's client token now use one service named
wiretap. They remain independent because each secret has a unique account
key; deleting an admin profile cannot delete the client token or another
relay's token.

Wiretap now uses Zalando's native keyring implementation exclusively:

• Secret Service on Linux
• Keychain on macOS
• Credential Manager on Windows

There is no second keyring implementation or backend-selection setting. For
the desktop client token, failure to reach a native keyring still activates
the existing mode-0600 file fallback. Saved relay-admin profiles remain
strict and do not store an admin token in plaintext.

Linux Secret Service fix

The previous 99designs adapter treated Wiretap's service label as a collection
object path. On affected GNOME installations, saving succeeded by creating a
new collection with a generated name, but the next open could not rediscover
that collection. Each retry could therefore create another
wiretap_relay_admin collection while loading the profile returned
secret not found.

The native implementation writes account entries into the user's default
keyring and retrieves them by the stable wiretap service and account pair.
An integration round trip on Secret Service now verifies Set, Get, and Delete
across separate calls.

Wiretap also reads a token back immediately before committing saved-profile
metadata. A backend that accepts but cannot retrieve a secret now produces an
error at save time instead of leaving an unusable profile.

Connection-state fix

Disconnect now clears the active relay-admin operation explicitly. This fixes
the Connect button remaining on Connecting... after connecting without a
custom profile name and then disconnecting.

Upgrade note

Profiles saved by the affected v0.2.11 Linux build may reference secrets in
the broken collections. Connect once with the relay URL and admin token and
leave Remember this relay enabled; saving the same URL replaces its profile
with a working entry under the wiretap service. The obsolete collections are
not deleted automatically because they are credential-store data. After the
new profile reconnects successfully, they can be removed manually with the
desktop's Passwords and Keys application.

Full changelog: v0.2.11...v0.2.12

wiretap v0.2.11

wiretap v0.2.11

This release makes repeat relay connections convenient without treating every
secret the same. Relay-admin access and the desktop's long-lived client
identity now use the operating system's credential storage where appropriate.

Saved relay administration

The GUI can remember multiple relay-server connections by name. A saved
profile contains:

• A user-chosen profile name.
• The canonical relay URL.
• Its last-used timestamp.
• An admin token stored separately in the operating system keyring.

The profile picker supports any number of saved relays and makes reconnecting
or forgetting one explicit. Temporary connections remain available. If the
keyring cannot store an admin token, wiretap keeps the active connection only
for the current session and does not write a plaintext fallback.

Supported secure backends are macOS Keychain, Windows Credential Manager,
Secret Service, KWallet, and pass. The encrypted-file and Linux KeyCtl
backends are deliberately excluded for saved admin profiles.

Keyring-first desktop identity

The relay client token used for automatic tunnel startup now benefits from a
separate keyring service. On registration, wiretap first attempts to store the
token there. The local relay-credentials.json then contains only the client
ID, project list, and an opaque keyring reference.

Existing credentials need no manual migration. The first successful load with
a supported keyring moves the plaintext token out of the JSON file while
preserving the client ID and all project assignments.

Headless hosts are intentionally different from relay administration. A client
token is required for unattended tunnel startup, and many servers have no
desktop keyring. When no supported keyring is available, wiretap automatically
retains the previous mode-0600 credentials file instead of disabling the
tunnel. There is no storage-mode setting to configure. GUI Settings reports
which storage path was selected.

Consistent CLI and GUI behavior

All client-credential paths now use the same manager:

• wiretap relay register --save
• wiretap relay projects add
• wiretap relay projects remove
• GUI registration and project management
• GUI and TUI tunnel startup

This removes the old CLI registration writer that bypassed credential-storage
policy. Admin tokens and client tokens use separate keyring services and
accounts, so forgetting a relay-admin profile cannot disturb the desktop
tunnel identity.

Upgrade notes

• No relay-server or database migration is required.
• Existing plaintext client credentials continue to work and migrate
  automatically when a keyring becomes available.
• A keyring reference requires access to the same operating-system user's
  credential store. On machines that never provide one, wiretap continues to
  use the protected credentials file.
• Saved relay-admin profiles from v0.2.10-compatible builds continue to use the
  same service name and remain available.

Full changelog: v0.2.10...v0.2.11

wiretap v0.2.10

wiretap v0.2.10

This release turns Settings into a workflow-oriented control surface and
completes project lifecycle management for relay operators.

Settings that follow the way wiretap is used

The previous desktop settings form placed every option in one long page.
Settings now has four focused workspaces:

• Relay connection for the endpoint, desktop identity, and projects owned
  by this desktop.
• Capture and delivery for automatic forwarding, local interception, and
  SQLite storage.
• Interface for desktop readability, title bar behavior, and the TUI theme.
• Relay server for privileged server administration.

The new navigation remains visible while moving between sections. Configurable
pages show whether there are unsaved changes and keep the save action close at
hand. The layout collapses into compact section tabs for narrow windows.

Complete relay project management

Relay administrators can now add a project path to any existing client from
the GUI. This is independent of client registration, so it does not create a
new client ID or rotate a token.

Each project row supports:

• Move, which changes the owning client and preserves queued relay history.
• Delete, which removes that project binding and its queued relay history.
  It does not delete local desktop deliveries or affect another project.

The server overview refreshes after every successful mutation. If the selected
relay and client match the current desktop, wiretap also synchronizes its saved
project list and restarts its tunnel automatically.

The ownership model has not changed: a client may own many projects, and each
project has one owning client. Multiple subscribers for one project remains a
separate future relay-model feature.

Relay API additions

• PUT /admin/projects/{project} assigns a new project to an existing client.
• DELETE /admin/projects/{project} deletes a project and its queued relay
  history.

Both routes require the relay admin token. Existing client-authenticated add
and remove routes remain available for a desktop managing its own projects.

Upgrade note

Upgrade wiretap-relay before using the new server-admin Add and Delete
controls. Existing databases, client identities, project bindings, and queued
history require no migration.

Full changelog: v0.2.9...v0.2.10

wiretap v0.2.9

wiretap v0.2.9

This release makes transforms portable and brings privileged relay identity
management into the desktop GUI.

Relay server management

Settings now separates ordinary desktop configuration from a privileged
Relay server workspace. Relay operators can:

• Connect using a relay URL and an admin token held in memory only.
• Inspect relay health, version, connected desktop sessions, clients, and
  project ownership.
• Create credentials for another client without replacing the registration
  used by the current desktop.
• Revoke a client after a warning that its project bindings and queued relay
  webhook history will be deleted.
• Move a project to another registered client while preserving the project's
  queued webhook history.

Client and project inventories display totals and use bounded scrolling for
larger installations. The Clients and Create client panels keep equal heights
at wide desktop sizes and collapse into a single column on narrower windows.

New client tokens are shown once for copying and are not written to the local
configuration. Leaving the Relay server workspace clears its admin token and
server snapshot from GUI memory.

The relay /health response now reports unique connected desktop tunnel
sessions. Upgrade wiretap-relay to v0.2.9 for an accurate Live tunnels
value. The other management controls use the admin APIs available since
v0.2.5.

Portable transforms

Transforms can now be exported and imported as strict, versioned JSON files.
The portable file includes the transform name, trigger, priority, enabled
state, and JavaScript program while excluding database IDs and timestamps.

Imports are limited to 1 MiB and reject unknown fields, unsupported versions,
missing names, invalid triggers, and trailing JSON. An imported transform opens
as an unsaved draft so it can be inspected and tested before persistence or
execution.

The transform editor also adds Duplicate. It copies the live program,
trigger, priority, and sample request into a disabled, unsaved draft. This
makes it safe to branch an existing transform without modifying the original.

Compatibility and upgrades

• No relay database migration or storage-schema change is required.
• The relay still assigns one owning client to each project. Multi-subscriber
  delivery and per-subscriber cursors are not part of this release.
• Existing clients, tokens, project assignments, local captures, and relay
  webhook history remain compatible.
• Transform files are a new optional workflow and do not alter transforms
  already stored in the local database.

Quality

The release includes GUI binding tests for relay administration and credential
isolation, relay health and unique-session coverage, strict transform-file
validation tests, frontend syntax checks, race-enabled tests across the
affected relay and GUI packages, production-equivalent GUI builds, and visual
review of empty and populated relay-management states.

Full changelog: v0.2.8...v0.2.9

wiretap v0.2.8

wiretap v0.2.8

This patch release corrects the visual balance of the request composer
introduced in v0.2.7.

Composer panel alignment

The request and response columns now stretch to the same grid-row height. The
empty response inspector also fills the complete response column and keeps its
prompt centered, removing the mismatched background block beneath the panel.

No request behavior, transform execution, storage format, or relay protocol has
changed.

Quality

The CSS change passed formatting checks and was visually verified against the
wide two-column composer layout.

Full changelog: v0.2.7...v0.2.8

wiretap v0.2.7

wiretap v0.2.7

This release adds explicit compose recipes for niche replay workflows while
preserving the general-purpose request composer introduced in v0.2.6.

Source recipes

Create a normal transform with the new on_compose trigger, then select it in
Compose > Source recipe. Paste source text or import a JSON file, choose a
target base URL, and run the recipe. The script receives the source as
request.body and can construct the complete method, URL, headers, and body.

Applying a recipe performs no network I/O. The result opens in the manual
composer, where every generated field is visible and editable before Send is
pressed. Automatic on_replay transforms are disabled for a generated draft
until the user explicitly opts back in.

Recipes are stored locally in the existing transform database and are selected
per preparation. Wiretap ships no provider-specific runtime behavior. A small,
provider-neutral source-record example is documented in the
recipe file.

Composer layout

The Compose workspace now has separate Manual request and Source recipe
modes. The manual view has focused Body and Headers tabs paired with a response
inspector, and it collapses cleanly for narrower windows. Opening a transform
from the sidebar keeps Compose visible beside it.

Every transform trigger now has an editable sample request test bench. Method,
URL, headers, body, and response status can be supplied in the transform editor,
and the transformed request is shown without touching the network.

The existing manual composer, request-envelope import, webhook and traffic
handoff, optional on_replay chain, and bounded response inspection remain
available.

Safety and compatibility

• Recipe application cannot send an HTTP request.
• Recipe targets and generated destinations must be absolute HTTP(S) URLs.
• Disabled recipes do not appear in the composer.
• Existing scripts and databases require no migration.
• The scripting sandbox remains filesystem-free and network-free with a
  five-second execution timeout.

Quality

Application and GUI-binding tests cover recipe discovery, enabled-state
filtering, source transformation, headers, draft safety, rejection, and URL
validation. The full Go suite, frontend syntax checks, generated Wails
bindings, and GUI build pass for this release.

Full changelog: v0.2.6...v0.2.7

wiretap v0.2.6

wiretap v0.2.6

This release adds a first-class HTTP Request Composer to the desktop GUI. You
can author requests from scratch, import JSON, continue from captured traffic
or webhooks, apply replay transforms, and inspect the endpoint response without
leaving Wiretap.

Highlights

Compose arbitrary HTTP requests

The new Compose workspace provides:

• HTTP method and absolute destination URL;
• editable multi-value headers;
• plain-text or JSON request bodies;
• optional execution of enabled on_replay transforms;
• response status, headers, body, size, duration, and truncation state.

Requests accept absolute http:// and https:// URLs, use a 30-second timeout,
and follow the same direct local transport behavior as webhook replay.

Import JSON

Use Import JSON to load a normal JSON document as a POST body with
Content-Type: application/json. JSON can also be pasted directly into the
body editor.

For complete request definitions, import a request envelope:

{
  "method": "POST",
  "url": "http://127.0.0.1:8080/webhook",
  "headers": {
    "Content-Type": ["application/json"],
    "X-Test-Event": ["order.created"]
  },
  "body": {
    "order_id": "test-123"
  },
  "apply_transforms": true
}

Header values may be strings or arrays. Non-string envelope bodies are
JSON-encoded and formatted automatically.

Continue from real traffic

Webhook and traffic detail panes now include Open in composer. Wiretap
copies the method, headers, body, and available destination into an editable
draft. Captured traffic loads the complete request body on demand instead of
silently using its bounded preview.

Safe response inspection

Composed responses are capped to a 2 MiB preview before crossing the desktop
GUI bridge. Responses with a declared Content-Length retain their exact total
size; chunked oversized responses are reported as truncated with the observed
lower bound. Copy and download actions operate honestly on the preview when no
larger body is available.

Composed requests and responses are intentionally ephemeral and are not added
to the traffic-capture database automatically.

Documentation

The Request Composer guide
covers request creation, JSON envelope fields, transforms, captured-data
handoff, response behavior, and limits. The README and changelog include the
new workflow as well.

Quality

The release adds application and GUI-binding integration tests for request
construction, headers, response serialization, URL validation, timing, and
large-response bounds. The full Go test suite, standard build, frontend syntax
checks, generated Wails bindings, and GUI-tagged build pass.

Full changelog: v0.2.5...v0.2.6