Bridging the Gap: How FDC3 Works Across Platforms

io.Bridge
,
1

An OSFF 2025 NY recording showing how io.Bridge brings FDC3 to life in fragmented environments, bridging web and desktop technologies.

This talk is a practical walkthrough of the “hybrid desktop” problem most of us live with: you’ve got long-lived native/thick-client apps (e.g., an OMS, Bloomberg, other JVM/C++ era tooling) alongside modern web apps (React charting, analytics, client management, etc.). You want them to behave like one workspace even though they were built by different teams, at different times, with different deployment models. The baseline interoperability pattern is FDC3: a standard way to pass small, well-defined pieces of context between applications so they can synchronize on “what the user is looking at” (e.g., an instrument like MSFT) without hardwiring point-to-point integrations.

Once your newer apps live in the browser, web-to-web context sharing becomes viable with the same FDC3 concepts (publish/broadcast context, respond to intents, etc.) with the help of “FDC3 for the Web”. If the OMS/Bloomberg side is out of the loop, a pure web approach is not enough. That’s where bridging comes in: moving context across the boundary between a browser environment and a desktop environment so both sides participate in the same interoperability fabric.

The bridging approach is io.Bridgesharing context between io.Connect Desktop and io.Connect Browser (both acting as “desktop agents” in their respective environments), and potentially bridging between a browser environment and native desktop apps as well. There are a few pragmatic use cases:

  • Progressive migrations: move one capability at a time from desktop to web while keeping the overall workflow connected.
  • Mixed environments inside one firm: different teams or projects using different agent instances (desktop vs browser) but needing a unified user experience.
  • Multiple devices: extending the bridge across hardware (e.g., desktop to tablet for client demos). This is explicitly called out as requiring supporting infrastructure (not just localhost), and latency becomes a function of the network/hardware/IT architecture rather than the interoperability API shape.