[Epic] Bridges — vendor suites (DingTalk, WeCom, Feishu) behind the standard protocols the platform speaks: the platform's generic interfaces (webhook channel, inbound webhook, OIDC, SCIM) and the objectstack-ai/bridges repository #27314

repo:cloud#2 · os-zhuang · session_0123kRqqdpAJWYMgsgdAJX4G (filed on the maintainer's direction, handed off from the #27108 cloud-assessment thread)

Filing gate: ③ maintainer-directed, and ④ the cross-repo parent of its children. The maintainer, in the cloud project thread on 2026-10-28 (verbatim, not translated): 「钉钉这种不支持标准API的，有没有可能我们封装一层中转的微服务，按照标准协议」 (16:03Z) · 「用户映射、身份认证，这个属于单独的需求，能否也可以是另外一套中转服务」 (16:05Z) · 「我说的只是把钉钉作为例子，还会有企业微信，飞书等，你认为是中转服务的方式好，还是开发具体插件的方式好。」 (16:10Z, answered: bridges) · 「我创建了 bridges 仓库，你可以初始化，然后刚才讨论的问题立专题卡」 (16:15Z) · 「这个应该是单独的专题卡吧」 (16:16Z). And on the #27108 decision card 「插件专题 #27108 在中转方案之后怎么处理？」 the maintainer chose 「M1 做完，其余冻结」 (16:18Z). ⛔ Not a claim. ⛔ No domain:*: children span objectstack (server), cloud and objectstack-ai/bridges; triage sets each child's lane.

Dedupe: bridge relay DingTalk WeCom Feishu webhook messaging channel OIDC SCIM on objectstack → 0 hits (open or closed). Related, not duplicates: #27108 (code plugins), #27287 (SDK contract, frozen by this ruling), #27293 (zero-code connectors — this epic's action side reuses it).

维护者速读

钉钉、企业微信、飞书这类不讲标准协议的套件，不再做成代码插件，而是走独立的「中转服务」（bridge）：平台只讲标准协议，bridge 负责把标准协议翻译成厂商私有 API。平台补齐几个通用接口一次（出站 webhook 消息通道、入站 webhook、OIDC 登录、SCIM 通讯录），以后每接一家只是多一个 bridge，平台不改。bridge 放在新仓 objectstack-ai/bridges（公开、Apache-2.0，已初始化 80b4abd），每家一个包、各自发版；同一份代码既跑我们托管的多租户实例，也出 Docker 镜像给私有部署客户内网自部署。连带裁决：#27108 只做完 M1，M2–M5 与 SDK 冻结；托管 Cloud 不加载代码插件。

Decisions this epic carries

How a bridge meets the platform

Children (each filed by the owning lane, Part of this epic)

• B1 — notification channel over the existing HTTP outbox (objectstack, server, S). The delivery machinery exists: plugin-webhooks (sys_webhook, HMAC X-Objectstack-Signature, durable outbox, retries, cluster dispatcher; packages/services/service-messaging/src/http-outbox.ts) already POSTs record events. What is missing is a per-recipient messaging channel: registerChannelProvider is called for email and sms only (messaging-service-plugin.ts:458, :477), so a notification addressed to a person (recipient, preferences, template) cannot reach a URL. B1 = a webhook channel provider that enqueues into the same outbox, carrying the recipient's externalId, the rendered content and the deep link.
• B2 — inbound callbacks: no card, already exists. A flow's api start node arms a signed inbound hook (packages/spec/src/automation/api-trigger-secret-ref.zod.ts, flow.zod.ts:1117), and a wait node resumes on an incoming webhook (node-executor.zod.ts:31). The bridge verifies and decrypts the vendor callback, then posts to that hook.
• B3 — "Sign in with " on the Cloud identity center (cloud, S). The mechanism exists on both sides: environments take an external OIDC/SAML IdP through @better-auth/sso (bring-your-own IdP; Business+ on hosted), and the Cloud identity center already federates social logins — but as a fixed list of Google / GitHub / Microsoft from environment variables (packages/service-cloud/src/control-plane-preset.ts:444-450). B3 = one generic OIDC upstream entry (better-auth genericOAuth) per bridge, so every hosted environment gets the button. Self-hosted: documentation only.
• B4 — SCIM for bridges: two gaps only (cloud + objectstack). SCIM itself is built: cloud ADR-0071 put @better-auth/scim (SCIM 2.0 /Users, active:false → ban + session revoke) in each environment, and the hosted kernel mounts it by plan (planAllowsScim, packages/objectos-runtime/src/artifact-kernel-factory.ts:103, :315-355; EE turns it on with the FEATURE_SCIM licence, apps/objectos-ee/objectstack.config.ts:763-769). A bridge is an external directory client, the same role as Okta, so ADR-0071 D2's "no cloud-as-SCIM-client" does not apply. What remains: (a) Users only, no /Groups (ADR-0071 D4): DingTalk departments → sys_business_unit and department → role are not covered — ADR-0071's out-of-scope line even names 钉钉 / 企业微信 / 飞书 org-structure sync; (b) tier: SCIM is Enterprise-only (cloud docs/design/pricing.md:127) — a maintainer decision (below) before a bridge relies on it for Team customers.
• B5 — bridge-kit + bridge-dingtalk (bridges). Kit: OIDC provider shell, SCIM client, webhook relay, vendor callback crypto (the token cache landed in 80b4abd). DingTalk: actions (connector app's OpenAPI description), notifications (B1), sign-in (B3), directory (B4). Ships as our hosted instance and a Docker image. Acceptance carried over from ADR-0025 SDK contract — the three public seams external plugins build on (messaging channel provider, identity-object writes, PluginContext subset), a conformance testkit, the peer-dependency build check, and the objectstack-ai/plugins repository #27287: an approval notification reaches a mapped DingTalk user with a deep link back to the record — plus sign-in with DingTalk and a directory sync.
• B6 — compatibility (bridges + objectstack). A nightly contract test of each bridge against the platform's next build, and a conformance kit for the standard interfaces in objectstack.
• WeCom and Feishu bridges are filed after DingTalk proves the kit.

Open maintainer decisions (decision cards when the child is dispatched)

1. Who registers the vendor app: one ISV third-party app on the DingTalk open platform shared by all customers (better onboarding; needs ISV qualification and listing) vs each customer's own internal app with its key entered in the environment (works today).
2. Tier: is "Sign in with DingTalk" a social login (every tier, like Google/Microsoft), and is directory sync over SCIM Enterprise-only as SCIM is today — which would leave Team customers in China without it?

Rules every child inherits

• ⛔ The platform never runs vendor code for this epic; a need that only in-process code can meet is a [Epic] ADR-0025 plugin package distribution — the next development phase: M0 record v2, M1 local T0 install loop (first-party, self-signed), M2 cloud fetch + per-plugin permission enforcement, M3 third-party sandbox tier #27108 question, not a bridge.
• ⛔ Bridges are stateless toward customers: credentials arrive per request from the environment's own credential store and are never stored or logged; only derived tokens are cached (bridges AGENTS.md).
• ⛔ Bridges import no @objectstack/* internals; a missing standard interface is a platform card under this epic.

Done-when

• B1 and B3 landed (and B4 for the gaps it carries), in the cloud pin.
• bridge-dingtalk released, hosted for ObjectOS Cloud and available as a Docker image; on a hosted environment a user signs in with DingTalk, the directory syncs, and an approval notification reaches the approver's DingTalk with a deep link.
• The nightly contract test runs green against platform next.

Related

#27108 (code plugins; ruling recorded there) · #27287 (frozen) · #27293 (connector apps; cloud#3353 E4 shelf lists each bridge's connector app) · #27230 (credential S1) · ADR-0024 (identity) · objectstack-ai/bridges docs/architecture.md.