SupportRelay
Carrying a support conversation between a member and a creator over the platform — relay modes, replies, group threads and attachments, and where the inbox stays.
Subscriby\Connector\Contracts\Ports\SupportRelay. Bound by support_relay.
The inbox is the core's: every message a member sends is ingested, stored, shown in the dashboard and answered from there. A connector with this port adds two things: it delivers the creator's replies to the member on the platform, and it offers relay modes, ways of carrying the conversation to the creator on the platform as well, named in the manifest's relay_modes.
Methods
| Method | Called when | Returns |
|---|---|---|
relayModes() | The kit; the support settings compare it with the manifest. | list<string> |
relay(installation, credentials, ConversationRef, Recipient, OutboundSupportMessage) | A creator or teammate answers a conversation whose member is reached on this connector. | DeliveryResult |
openThread(installation, credentials, SpaceRef, title) | The first message of a conversation arrives while the project relays into a group (forum_group). | RelayThread |
postToThread(installation, credentials, SpaceRef, threadId, Message) | Every later message of that conversation, in both directions, is mirrored into its thread. | DeliveryResult |
fetchAttachment(installation, credentials, SupportAttachment) | A creator opens a conversation that carries a file the member sent; the core asks for the bytes once and stores its own copy. | ?FetchedAttachment |
relay()
OutboundSupportMessage is the reply: body (canonical HTML), attachments (files the creator attached) and quotedExternalId, the platform id of the member's message being answered, so a platform that quotes can. ConversationRef names the thread (id, projectId); the Recipient is the member's identity. Return the platform's message id in the DeliveryResult so the core can show "delivered" and quote it later.
Group threads
When the project's relay mode is forum_group, the creator has linked a group: on Telegram by adding the bot to it, which the connector's inbound handler reports to the core through Core\Support::linkRelaySpace(). (LinkPurpose::SupportRelay exists for a platform that has to be asked, but the core does not request it yet.) The core keeps the thread id on the conversation: openThread() is asked once per conversation, postToThread() for every message afterwards, and a thread the platform no longer knows is answered TargetMissing so the core opens a fresh one. RelayThread carries the threadId or the classified failure.
Attachments
A member's file arrives as a SupportAttachment: its kind (Image, Video, Animation, Voice, Audio, File), a url when the platform serves files at one, or a platformFileId when it does not. The core keeps that reference until a creator opens the thread, then calls fetchAttachment() once and stores its own copy. Answer a FetchedAttachment (stream, fileName, mime) or null when the platform cannot hand the file over (a reference it no longer knows, a path this container cannot see); the core answers "not found" and stores nothing. Log the reason yourself.
What the core has done before calling you
The support_relay capability may be switched off per installation; the core then answers Configuration ("The connector does not relay support conversations.") without calling the port. Every call is timed and counted, and a DeliveryResult is read like a Messenger's.
Explaining the modes to the creator
The mode names mean nothing on their own. Fill the support_relay_options slot with a short explanation of what each mode means on your platform; its context is mode (the current choice), linked (whether a relay space is linked) and handle (the installation's handle for the sentence).
How Telegram does it
A reply with a file goes as the media call Telegram has for its kind, with the text as the caption; a reply that answers a particular message quotes it, and is still sent when the quoted message is gone. The two modes are a DM to the creator's own account and a topic per member in a forum group the project bot was added to. Attachments come from a Bot API in local mode, so the connector is given an absolute path and reads it from a mounted copy of that directory.
What the kit checks
relay.modes_match_manifest: the sorted list relayModes() returns equals the manifest's relay_modes.
Ingestion is yours, storage is the core's
A member's inbound support message reaches the core from your inbound handler, which decodes it into an InboundSupportMessage and files it through Core\Support::ingest(); a creator's answer written on your platform goes back through Core\Support::reply(). The core never reads the platform for that; your handler is the only way a member's words enter the inbox, and this port is the only way the core's words leave it.
How is this guide?
AccessController
Giving and taking away access to a place — grant, revoke, revokeReference, admit, membership, announce and reconcile, the idempotency each must keep, and every core path that calls them.
PortalLoginMethod
Signing a member into the portal through the platform — the button, the handshake the core mints, how the connector completes it from its inbound side, and what the member sees.