feat(photon): support rich link previews - #54646
Conversation
teknium1
left a comment
There was a problem hiding this comment.
Thanks for extending the Photon sidecar with an outbound rich-link path and preserving the v8-compatible inbound behavior.
Problems
plugins/platforms/photon/adapter.py:1529removes current main'sreturn resultafter exhausted retryable attempts (plugins/platforms/photon/adapter.py:1450-1455). The new fallthrough performs another plain-text_sidecar_send()for every exhausted retryable send, including ordinary text. A timeout can occur afterspace.send()accepted the earlier message, so that extra POST can duplicate a delivered response. The richlink-specific fallback is already handled by_sidecar_send()at PR lines 1565-1574.
Suggested changes
- Restore the exhausted-retry return for ordinary sends and add a regression test asserting that an exhausted retryable non-URL response makes no extra send.
Automated hermes-sweeper review.
| max_retries, error_str, | ||
| ) | ||
| return result | ||
| # Fall through to the plain-text fallback below. For URL-only |
There was a problem hiding this comment.
Please retain the existing return result for exhausted retryable failures. This fallthrough runs for ordinary text as well as URLs and makes another /send after the retry budget; an HTTP timeout can occur after space.send() accepted a prior attempt, so that extra POST can duplicate a delivered reply. Richlink-to-plain fallback is already handled inside _sidecar_send().
|
Merged via #73614 — cherry-picked with authorship preserved. Rich links + preview-artwork coalescing shipped; the preview-suppression logic composed cleanly with the FFFC wait machinery on main. |
What changed
Adds full Photon rich-link support for Hermes:
/send-richlinkendpoint, which wraps Spectrumrichlink(url)so iMessage can render native preview cards/sendtext if richlink sending is unsupported or failsrichlinkURL text, and preservestitle/summarymetadata when Spectrum has already exposed those as plain fields.pluginPayloadAttachmentpreview artwork that arrives immediately after a URL/richlink so the agent receives one link message instead of a follow-up attachment promptWhy
Fixes #50336.
This also supersedes/extends #50337. That PR handles the inbound
richlinkplaceholder bug; this branch includes compatible inbound handling and adds outbound richlink sending plus preview-art coalescing. Unlike #50337's original sidecar approach, this branch does not call lazytitle()/summary()accessors in the inbound stream. Photon docs describe those as lazy metadata accessors, and webhook docs intentionally keep richlink deliveries URL-only to avoid adding URL fetch latency or attack surface to delivery.Validation against Photon docs
Checked current Photon docs:
https://photon.codes/docs/llms.txtlists Spectrum rich links and webhooks docs.https://photon.codes/docs/spectrum-ts/content/rich-links.mddocumentsrichlink(url)for outbound URL preview cards and lazytitle(),summary(),cover()metadata accessors.https://photon.codes/docs/webhooks/overview.mdsays webhookrichlinkdeliveries ship theurlonly and omit resolved title/summary/cover metadata.Implementation follows that split: outbound uses
richlink(url); inbound preserves URL and any already-materialized title/summary fields without resolving lazy accessors itself.Tests
uv run --with pytest==9.0.2 --with pytest-asyncio==1.3.0 python -m pytest tests/plugins/platforms/photon -q— 133 passednode --check plugins/platforms/photon/sidecar/index.mjsgit diff --checkI also ran two reviews. One implementation review found no blocking issues.
One docs/API review flagged lazy inbound metadata resolution as risky; this was updated to avoid resolving
title()/summary()in the sidecar and only preserve plain fields when present.