Outstanding: Backend-aware cross-platform deep links per message #24

New issue

Closed

opened 2026-08-22 04:17:54 +00:00 by kayg · 1 comment

kayg commented

2026-08-22 04:17:54 +00:00

Owner

Current state

Outstanding. Existing issue #4 requests deep links generally; this issue fixes the required addressing contract for message-level links. A link must identify the conversation and message and encode which Hermes gateway backend it belongs to, so it resolves unambiguously when multiple backends exist. The address must work on macOS and be usable by a future iOS app.

A custom URL scheme is weak on iOS: ownership is not exclusive and routing is not a strong proof of the intended app/backend. An HTTPS universal link is the preferred direction because its host can encode the backend identity, while its path/query can encode the session and message. The backend identity must not be inferred from whichever backend happens to be active locally.

Acceptance criteria

Every message deep link contains an explicit, canonical backend identity plus session/conversation and message identity.
Resolution is unambiguous when two Hermes gateway backends are configured.
The same address model works on macOS now and leaves a valid path for a future iOS app.
Prefer an HTTPS universal-link design whose host encodes the backend; document any macOS custom-scheme compatibility only as a secondary mechanism.
Opening a link selects the correct backend, conversation, and exact message, or reports a precise unavailable-target error.
Existing issue #4 is either superseded or explicitly linked; this issue must not silently omit its scope.

## Current state Outstanding. Existing issue #4 requests deep links generally; this issue fixes the required addressing contract for message-level links. A link must identify the conversation and message and encode **which Hermes gateway backend it belongs to**, so it resolves unambiguously when multiple backends exist. The address must work on macOS and be usable by a future iOS app. A custom URL scheme is weak on iOS: ownership is not exclusive and routing is not a strong proof of the intended app/backend. An HTTPS universal link is the preferred direction because its host can encode the backend identity, while its path/query can encode the session and message. The backend identity must not be inferred from whichever backend happens to be active locally. ## Acceptance criteria - Every message deep link contains an explicit, canonical backend identity plus session/conversation and message identity. - Resolution is unambiguous when two Hermes gateway backends are configured. - The same address model works on macOS now and leaves a valid path for a future iOS app. - Prefer an HTTPS universal-link design whose host encodes the backend; document any macOS custom-scheme compatibility only as a secondary mechanism. - Opening a link selects the correct backend, conversation, and exact message, or reports a precise unavailable-target error. - Existing issue #4 is either superseded or explicitly linked; this issue must not silently omit its scope.

kayg added the

outstanding

label

2026-08-22 04:17:58 +00:00

kayg commented

2026-08-22 04:24:00 +00:00

Author

Owner

Closing as a duplicate of canonical issue #4. The added cross-platform and multi-backend requirements, custom-scheme authority format, and deterministic-id status have been recorded on #4.

kayg closed this issue

2026-08-22 04:24:00 +00:00

No labels

delivered

outstanding

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

kayg/hermternal-apple#24

No description provided.

Rows
Columns