1db79bfe1e188134a53c32066bea5d35367e1f26
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 teknium1
|
1866518574 |
feat(photon): group-chat mention gating for full channel parity
Adds the last missing parity piece vs the established channels: group chats can be made opt-in via a mention wake word, exactly like the BlueBubbles iMessage channel. - require_mention + mention_patterns, read from config.extra (config.yaml via the generic gateway bridge) or PHOTON_REQUIRE_MENTION / PHOTON_MENTION_PATTERNS env vars. Same shapes BlueBubbles accepts (list / JSON / comma / newline), same default Hermes wake words. - _dispatch_inbound drops unmatched group messages and strips the leading wake word from matched ones; DMs are never gated. - plugin.yaml + docs document both knobs and the config.yaml form. - New test_mention_gating.py (8 tests): default-off, group drop/pass, wake-word strip, DM bypass, custom patterns, env comma-list, invalid regex skip. The config.yaml -> extra bridge needed no core change — the generic shared-key loop in gateway/config.py already iterates plugin platforms (_shared_loop_targets += plugin_entries()), so require_mention / mention_patterns flow through automatically. Note: outbound media is the one capability Photon still can't reach — Photon exposes no HTTP send-attachment endpoint yet (documented API limitation), so the sidecar can't send files. Not faked. Validation: 34/34 photon tests; E2E confirms config.yaml require_mention + custom mention_patterns bridge through load_gateway_config into a live adapter and gate/strip correctly. |
||
|
teknium1
|
d7f42e368e |
feat(photon): full channel parity — gateway setup, pairing, PII redaction, doc fixes
Brings Photon in line with how every other Hermes gateway channel behaves, instead of being a one-off with its own surfaces. - gateway setup: register a `setup_fn` so Photon appears in `hermes gateway setup` (the unified wizard) and runs the same device-login + project + user + sidecar flow as `hermes photon setup`. Adds `cli.gateway_setup()` as the zero-arg entry point. - PII redaction: flip `pii_safe` False -> True. The comment already said iMessage E.164 numbers should be redacted; the value contradicted it. Now matches BlueBubbles (the other iMessage channel) which is in _PII_SAFE_PLATFORMS — phone numbers are stripped before reaching the LLM. - Pairing/authz: already worked via the registry's allowed_users_env / allow_all_env generic path in authz_mixin; documented it. The adapter forwards unauthorized DMs to the gateway (no intake gating), so the pairing handshake fires and `hermes pairing approve photon <CODE>` works. - Docs: fixed the `hermes photon status` output block to match the real labels (project key / webhook key, not project secret / webhook secret), added the missing PHOTON_API_HOST / PHOTON_DASHBOARD_HOST / PHOTON_HOME_CHANNEL_NAME env vars, and added gateway-setup + authorize-users sections mirroring the other channel docs. Validation: 26/26 photon tests, 6504/6504 gateway+plugins tests, registry E2E confirms setup_fn dispatch + pii_safe + authz envs all wired. |
||
|
teknium1
|
8f89c4615f |
chore(photon): clean up ty type-checker warnings from lint-diff bot
The advisory lint-diff bot flagged 17 new ty diagnostics. 6 are
`unresolved-import` for httpx/aiohttp/pytest, which is structural
(CI lint env has no project deps) and matches every other platform
plugin's noise floor. The remaining 11 are real and fixable:
- `Optional[callable]` → `Optional[Callable[..., None]]` (auth.py)
invalid-type-form on `callable` as a type expression. Added the
proper `typing.Callable` import. Two sites: on_pending in
poll_for_token, on_user_code in login_device_flow.
- Dropped three unused `# type: ignore` comments on
hermes_constants / hermes_cli.config imports — ty can resolve
those modules fine, the comments were dead.
- _supervise_sidecar(proc) widened `proc.stdout` from
`IO[Any] | None` to a narrowed local after an early `is None`
guard. Defensive against subprocesses launched without
stdout=PIPE.
- cli.py _cmd_setup: dropped the `has_existing_project = bool(...)`
intermediate, did the narrowing inline with `if existing_id and
existing_secret:` so ty can see project_id/project_secret are
non-None when create_user is called.
- test_inbound.py: replaced three `adapter.handle_message =
fake_handle # type: ignore[assignment]` with
`monkeypatch.setattr(adapter, 'handle_message', fake_handle)`.
Same behavior, no type-ignore, and the monkeypatch reverts
cleanly between tests.
Validation:
ty check plugins/platforms/photon/ tests/plugins/platforms/photon/
→ All checks passed!
tests/plugins/platforms/photon/ → 26/26 pass
py_compile clean
Windows footgun checker → 0 footguns
|
||
|
Teknium
|
3a0f6ac3d4 |
fix(photon): satisfy Windows footgun + CodeQL checks
CI red on three blocking checks; all addressed:
1. Windows footguns: os.killpg() flagged as POSIX-only despite the
sys.platform != 'win32' guard. Static scanner doesn't see flow.
Added the documented '# windows-footgun: ok' suppression.
2. test (3): tests/plugins/platforms/photon/__init__.py shadowed the
real plugin's __init__.py because test_plugin_platform_interface.py
looks at PROJECT_ROOT/plugins/platforms/<name>/__init__.py with
PROJECT_ROOT=tests/ (pre-existing bug in that test, made visible
by the new test directory layout). Dropping the empty test
__init__.py restores the prior NOTSET parametrize behavior.
3. CodeQL (7 alerts in new code):
- cli.py: stop printing the first 8 chars of the bearer token after
login — even prefixes are partial credentials.
- cli.py: stop printing the first 8 chars of project_secret after
setup, same reason.
- cli.py 'hermes photon webhook register': stop dumping the raw
register-webhook response (contained signingSecret) and stop
echoing PHOTON_WEBHOOK_SECRET to stdout. Write it directly to
~/.hermes/.env (0o600), preserving existing entries; fall back
to manual instructions only if the file write fails. Photon
still only returns the secret once; this just doesn't put it
in scrollback / shell history.
- cli.py setup + status: rename project_id/project_secret/token
locals to has_* booleans before printing, breaking CodeQL's
taint flow through f-string interpolations. Drop diagnostic
prints of phone / assignedPhoneNumber that flagged as
'sensitive data' false positives.
- sidecar/index.mjs: stop returning the raw error message
(potentially containing stack trace) in HTTP 500 responses;
supervisor logs the real error to stderr, client only sees
a generic 'internal sidecar error'.
Validation:
- scripts/check-windows-footguns.py --all → 0 footguns (518 files)
- tests/plugins/platforms/photon/ → 22/22 pass
- tests/gateway/test_plugin_platform_interface.py → 7/7 pass, collects
NOTSET (matches pre-PR state)
- tests/gateway/test_platform_registry.py → 50/50 pass
- node --check sidecar/index.mjs clean
|
||
|
Teknium
|
5b4e431e8c |
feat(gateway): add Photon Spectrum (iMessage) platform plugin
First-class iMessage support via Photon's managed Spectrum platform. Targeted as a successor to the BlueBubbles adapter — Photon allocates the iMessage line, handles delivery, and abuse-prevention so users don't have to run their own Mac relay. Free tier uses Photon's shared line pool. Architecture: - Inbound: signed JSON webhooks (X-Spectrum-Signature, HMAC-SHA256) delivered to a local aiohttp listener. Dedupes on message.id, rejects deliveries with >5min timestamp drift. - Outbound: small supervised Node sidecar that runs the spectrum-ts SDK. Photon does not currently expose a public HTTP send-message endpoint; the sidecar is the only way to call Space.send() today. When Photon ships an HTTP send endpoint we collapse the sidecar into _sidecar_send and drop the Node dep — every other layer of the plugin stays the same. - Setup: 'hermes photon login' runs the RFC 8628 device-code flow; 'hermes photon setup' creates a Spectrum-enabled project, creates a shared user (free tier), installs the sidecar's npm deps. - Webhook management: 'hermes photon webhook register|list|delete'. - Credentials persisted under credential_pool.photon / credential_pool.photon_project in ~/.hermes/auth.json. Plugin path (not built-in) — per current policy (May 2026), all new platforms ship under plugins/platforms/. Registers itself via ctx.register_platform() + ctx.register_cli_command(), zero edits to core gateway code. Tests cover: - HMAC-SHA256 signature verification (happy path, tampered body, wrong secret, drift, missing v0 prefix, empty inputs, non-integer timestamp) - Inbound dispatch for text DMs, group ids (any;+;...), and attachment metadata markers - Deduplication window - check_requirements gating when Node is absent - Device-code flow: request, header-based token return, body-fallback token return, access_denied propagation - Project/user/webhook API clients with mocked httpx Known limitations (current Photon API): - Attachments are metadata only — no download URL yet - Outbound attachment send not wired (sidecar can add easily) - Reactions / message effects not exposed yet Docs: website/docs/user-guide/messaging/photon.md + sidebar entry. |