Documentation needs to be created on the FDC3 Docusaurus website for the new Channels API changes merged via #94.

This involves:

• Creating a new Channel.md file under https://github.com/FDC3/FDC3/tree/master/docs/api, using https://github.com/FDC3/FDC3/blob/master/docs/api/DesktopAgent.md as an example
• Ensuring that all the methods and properties from https://github.com/FDC3/FDC3/blob/master/src/api/channel/channel.ts are properly documented in the markdown file in easily understandable language, with included usage samples and with level 3 markdown headings, so that they show up as clickable links in the right-hand navigation section
• Editing https://github.com/FDC3/FDC3/blob/master/website/sidebars.json to include the new markdown document
• Ensuring the API interface documentation is consistent with the specification at https://fdc3.finos.org/docs/next/api/api-spec#context-channels

Once merged, the website will be updated for the master branch, visible at https://fdc3.finos.org/docs/next/api/api-intro

Docusaurus authoring help: https://github.com/FDC3/FDC3/blob/master/website/README.md#adding-a-new-docs-page-to-an-existing-sidebar

Feature Request

TL;DR

• An app may join multiple channels at once
• A DesktopAgent may select exactly one Channel as its context source

(Sorry this is seemingly contrary to my comments on PR #158)

Description of Problem:

The current Channel API proposal allows for holding onto references of unjoined channels and creating custom app channels. Take for example the following code:

let redChannel = (await fdc3.getSystemChannels()).find(ch => ch.id === 'red');
let greenChannel = (await fdc3.getSystemChannels()).find(ch => ch.id === 'green');
let appChannel = await fdc3.getOrCreateChannel('appChannel');

fdc3.join(redChannel.id);

Based on the existing specification, having references to these channels is sufficient for most of their functionality: broadcast(...), getCurrentContext(...), and presumably addContextListener(...) all function regardless of whether or not the channels have been joined.

However, in the current spec, context persistence only occurs when there is one or more application which has joined the channel. By design, channels lose their state / context when the last member leaves (or when no members are present).

Consider:

// this channel has no members
appChannel.broadcast({type: 'fdc3.contact'});

// what should the context be here?
let appChannelContext = await appChannel.getCurrentContext();

Presumably, the context of a channel with no members remains undefined; although the API provides no means of discerning this.

Furthermore, it seems unnecessarily restrictive to limit an app to joining a single channel when it can hold references, query status, and receive events from multiple channels.

Potential Solutions:

Allow an app to explicitly join or leave a channel from the Channel object itself. This membership has no affect on the context source of the DesktopAgent:

// Only affects the membership list of the channel
// allows it to persist state:
Channel.join() : Promise<void>

// If the app is the last member of the channel,
// leaving it causes the context to be cleared:
Channel.leave() : Promise<void>

// Denotes if a channel has members
// and will thus persist context
Channel.hasMembers() : Promise<bool>

// Designates a specified channel provides the event source
// for the DesktopAgent. Joins the channel if it is not joined
// By default, leaves the currently joined channel
// Channel.contextListeners bubble to DesktopAgent.contextListeners
DesktopAgent.joinChannel(channelId: string, leaveCurrent: boolean = true);

https://github.com/FDC3/FDC3/blob/master/docs/reference-implementations.md to be updated to /real-world-use-cases.md

https://github.com/FDC3/FDC3/blob/master/docs/usage-examples.md to be updated to /apps-and-platforms.md

According to the latest changes, desktop agent's broadcast is defined like this:

broadcast(context: Context): void

while channel's broadcast is defined like this:

broadcast(context: Context): Promise<void>

I really dislike that the pattern for these two operations do not match, and think it is very unintuitive for consumers.

Personally, I feel that broadcast should be fire-and-forget, it is not interesting to know if there was an error of some kind - if the user is not perrmissioned for the channel, or it doesn't exist, nothing will happen. This is in line with how the operation worked in 1.0.

We could change the top-level broadcast to also be async, but this would be a breaking change.

Compare:

fdc3.broadcast(context)

and

await fdc3.broadcast(context)

I do not think it is intuitive for broadcast to be async, or even to have to remember to put an await in front of it. I think I will often forget to do this, leading to brittle code.

To finalise the JSON schema work for context schemas began with #120, a number of things need to be done:

• Identify which schemas should be officially published/standardised as part of the first pass. Cross-reference with Financial Objects. fdc3.instrument and fdc3.contact are the most important ones to start with.
• Remove everything apart from email property from fdc3.contact schema to simplify.
• Publish versioned schema definition files to the FDC3 website, to match the URLs in the schema files, e.g. https://fdc3.finos.org/schemas/1.0/instrument.schema
• Make sure the context data examples line up with the schema definitions
• Add documentation for each signed of schema to the context data website documentation. It could work similarly to e.g. the API reference documentation.

Filing for discussion and reference - I think this is the best place...

Based on an FDC3 use case - there might be a need for an FDC3 uri (eg fdc3://) so that any application on the desktop could send context to FDC3 without requiring plugins, etc.

The IntentMetadata returned by findIntent should be aligned with the intent type definition from https://github.com/FDC3/Intents.

https://finosfoundation.atlassian.net/wiki/spaces/FDC3/pages/1177976849/Use+Case+17+Fine-tuning+InterOp+with+Channels

Website changes

• Iconography (own images and/or attribution)
• Use case updates
• Transfer latest from use case repo
  • Remove people lists from use case overview
    • Remove all but accepted use cases (talk to JT, Saori, Kat, Johan, Riko this week!)
• Add links to working group wikis into Community section
• Move why FDC3 to about section
• Updates to Why FDC3, Intents Overview, and Context Overview (Nick)
• Add get involved CTA ([email protected]) to Community, footer
• Add Docusaurus versioning
• Add "Used by" section to front page

Repo changes

• tag version 1.0-beta + release notes

Other changes

• Make sure news works with versioning
• Retire old partial FDC3 websites
• Update working group repos to point to combined repo
• Transfer open issues/PRs from working group repos
• Archive working group repos
• Point fdc3.org to fdc3.finos.org (or remove)

Release Preparation

• Repo and website promote to version 1.0
• Write a 1.0 blog post pointing to press release
• Change FINOS badge in README from "Incubating" to "Released" (see https://finosfoundation.atlassian.net/wiki/spaces/FINOS/pages/75530371/Released)
• Tag code as v1.0 and add release notes

The use case link is always broken.

While in document sections, all footer document links are broken, as they seem to contain a "language" part, e.g. https://fdc3.finos.org/docs/1.0/en/fdc3-intro instead of https://fdc3.finos.org/docs/1.0/fdc3-intro

As per title, on the page https://fdc3.finos.org/docs/1.0/why-fdc3 all instances of the link https://fdc3.finos.org/docs/1.0/apps-and-platforms and the https://fdc3.finos.org/docs/1.0/real-world-use-cases return 404

Let me know how I can help. Happy to send a PR to remove the links but I assume you might have a smarter solution :)

At the bottom of https://fdc3.finos.org/docs/1.0/api/api-spec there's two links to "src" and "docs" and they give a 404.

Wonder if it's a leftover from a previous docs implementation and should just be removed.

The AppMetadata and IntentMetadata returned by findIntent and findIntentsByContext should be aligned with the App Directory Specification and Intents Specification, respectively.

Migrate FDC3 repos from FDC3 Github Org (https://github.com/FDC3/) to FINOS Github Org (https://github.com/finos/).

Preparation task; collect (below)...

• FDC3 members/owners and external collaborators
• FDC3 team definition
• FDC3 Org settings, report differences with finos org
• FDC3 github apps configuration
• FDC3/fdc3 repo permissions

Migration task list

• Archive https://github.com/fdc3/appd-launcher-poc
• Archive https://github.com/FDC3/FDC3-Archive
• Copy https://github.com/orgs/FDC3/teams into https://github.com/orgs/finos/teams
• Plan code transfer and communicate to PMC (Thursday 5 December, 10am CEST)
• Transfer https://github.com/fdc3/fdc3 to https://github.com/finos/fdc3
• Assign Maintain repo role to team https://github.com/orgs/finos/teams/fdc3-pmc/members
• Migrate https://github.com/orgs/FDC3/projects/1 into https://github.com/orgs/finos/projects
• Enable http://travis-ci.org/finos/fdc3 and run first build
• Ensure fdc3.finos.org works
• Test Git redirects
• Notify fdc3 PMC

FCD3 Teams

PMC

brooklynrob
donbasuno
ftbb Maintainer
nkolba Maintainer
rikoe Maintainer
tkolecke

Use Case

jonathanteperJPMC Maintainer
rikoe Maintainer
nkolba Maintainer
donbasuno Maintainer

Context & Intents

markChartIQ
rikoe Maintainer
nkolba Maintainer

App Directory

rikoe Maintainer
nkolba Maintainer

API

chedzoir
ColinEberhardt
donbasuno
nkolba Maintainer
rikoe Maintainer

FDC3 Org settings

No differences found in GitHub org setup

FDC3 GitHub apps

• Polls
• Zapier

@rikoe , is there any configuration that needs to be updated for these 2 apps?

FDC3/fdc3 repo permissions

• FDC3 PMC (Team) -> Maintain
• RichLinnell -> Write (should be part of fdc3 project member)
• nkolba -> Admin (should be part of PMC)

A PR merged to master recently with new changes to the App Directory spec was accidentally applied retroactively to the 1.0 specification for App Directory (https://fdc3.finos.org/appd-spec).

The reason for this is as follows:

• The markdown documents live in the docs folder in GitHub, e.g. https://github.com/FDC3/FDC3/blob/master/docs/appd-spec.md

• When they are version-stamped they go into the website/versioned_docs folder: https://github.com/FDC3/FDC3/blob/master/website/versioned_docs/version-1.0/appd-spec.md

• The OpenAPI doc for app-directory is auto-generated at build time from https://github.com/FDC3/FDC3/blob/master/src/app-directory/specification/appd.yaml and then published to https://github.com/FDC3/FDC3/blob/master/website/pages/appd-spec.html (see here)

I think to resolve this problem we need to generate a separate version-specific (1.0) OpenAPI spec document (similar to the markdown docs), or alternatively use a different process/branching strategy.

Create a more detailed contribution guide.
e.g. see https://github.com/facebook/Docusaurus/blob/master/CONTRIBUTING.md)

Components to Developing and Executing Survey

• Draft Survey
• Select candidate survey tool
• Stage Survey in candidate tool (@aitana16)
• Collect feedback
• Finalize survey
• Identify people/orgs to distribute survey too
• Create distribution / survey awareness plan
• Distribute Survey
• Close Survey
• Process Results
• Summarize Results
• Review Results within FDC3 Survey
• Create summary / talking points for external socialization of survey results.

@grizzwolf is the svg in the root folder a duplicate of the one in website/static/img? I don't think we should have images in the root folder...

e.g. see https://github.com/facebook/Docusaurus/blob/master/CHANGELOG.md

Currently all of the objects that have ids are represented something like this:

{
  id: {
    [key: string]: string
  }
}

This may represent a challenge when trying to integrate these objects into existing infrastructure as id is a very common field and almost always represents a string value. From the perspective of this effort the field that the ids live under has no impact on the spec itself, but there likely would be a cost to consumers of the spec attempting to integrate it into existing workflows as id is an incredibly common field and likely already exists in those workflows as something else.

I propose that either:

1. id is renamed to another field, maybe 'ids'
   • This would be more semantically correct as it implies multiple ids rather than a single id
2. the keys and values from id could be moved onto the base object
   • I frequently work with financial objects as a part of my role at FactSet and have generally found that nesting identifiers under another value only serves to make the object more difficult to work with. The spec already specifies what ids should be specified by a given type, so there should be no confusion about which fields are identifiers.

The README.md in src/app-directory is out of date, and reflects information from before the FDC3 repositories were consolidated into one.

It needs to be updated.

raiseIntent as defined as follows:

raiseIntent(intent: string, context: Context, target?: string): Promise<IntentResolution>;

AppMetadata as returned by findIntentsByContext as defined as follows:

interface AppMetadata {
  name: string;
}

The intent (har-har) is that you can use the app identifier returned by the discovery to target a specific app for raising an intent. But if AppMetadata returns a "name", this cannot be done, instead the unique app identifier should be use for the target parameter of raiseIntent, but it is not returned.

The FINOS project blueprint at https://github.com/finos/project-blueprint should be applied to the FDC3 repository or repositories.

The README.md should adhere to the blueprint, and include:

• “description of the software, including a feature overview”
• “installation & configuration instructions”
• “description of how to use the software”
• “links to other systems (further documentation, continuous integration & validation tools, artifact repository, change log / history, etc.)”
• “Foundation status badge (“Released” when all criteria are met and PMC approves)”
• “Roadmap”
• “copyright & license information”

See also:

• https://finosfoundation.atlassian.net/wiki/spaces/FINOS/pages/75530376/Activation
• https://finosfoundation.atlassian.net/wiki/spaces/FDC3/pages/711950361/FDC3+1.0+Release+Public+Launch+Documentation+Sub-Plan

Prior Art

Would be good to have a section on prior art in this space on the homepage.

JSON-LD seem to define context and actions, for example:
https://schema.org/docs/financial.html

ECB using RDF: https://sdw.ecb.europa.eu/datastructure.do?conceptMnemonic=INSTRUMENT_FM&datasetinstanceid=280

Thomson-Reuters using both Turtle-RDF and JSON-LD: http://www.opencalais.com/ (E.g. https://permid.org/1-4296555135 )

Bloomberg Data License seem to support JSON-LD and RDF also.

I'm sure you've spent a lot more time looking into what's out there. It would be great to guide why FDC3 over some competing tech and how you plan to fit in with existing interop standards.

We should formalise the way FDC3 APIs are accessed, and make it independent of vendor or platform.

Currently the FDC3 1.0 specification only specifies that a "desktop agent" will implement the APIs in the specification, and doesn't define how they are accessed, leading to potential variability, and the need for an app to access fdc3 in different ways when running in different platforms, e.g. by using an if statement (almost like browser detection in the old days).

The suggestion is that each desktop agent provides a global window.fdc3 object where the FDC3 API is surfaced. This will allow apps to work interchangeably regardless of which FDC3 desktop agent it is running on, without any other dependencies.

This does not preclude:

• Vendors from adding extra FDC3 functionality to their implementation (just that the minimum API surface from the specification should be there)
• Surfacing the FDC3 APIs in a complimentary way, e.g. modules/imports

Fix the green colouring being used for the section headers when the website is contrained for space and applies responsive design.

This is probably a CSS issue.

The example to open that we have here doesn't match the API that we have defined here

Update headers of source files with license header comment (pasted below) per guidance on FINOS Wiki Contribution Compliance Requirements page. Specifically:

1. Update all source files with header language pasted below
2. Add any/all contributor specific copyright notices to NOTICE file

SPDX-License-Identifier: Apache-2.0
Copyright [yyyy] FINOS [Project Name] contributors - see NOTICE file
 
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
 
    http://www.apache.org/licenses/LICENSE-2.0
 
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

Add Google Analytics to Microsite (fdc3.finos.org) so we can track visits, sessions, traffic, referrers, etc.

Tasks:

• About page (Information about the FDC3 and its mission)
• Community page (Information and links to FINOS)
• News/blogs area (remove existing sample content, add real content, e.g. the news link on https://fdc3.org)
• Apply website versioning (first version should be either 0.9 or 1.0-beta)
  • See https://docusaurus.io/docs/en/versioning.
  • Should link back to a version tag in GitHub with release notes.
  • See how Docusaurus have done it: https://docusaurus.io/en/versions.
• Repository versioning guidelines (i.e. tags and release notes)
• Documentation improvements & extra content (TBD)
• An extra page under the docs for each area with the working group info from the wiki
• Users/members section with logos from https://www.finos.org/fdc3
• FINOS banner on landing page (from current fdc3.finos.org): "Proud member of the Fintech Opensource Foundation", with logo
• Use case description on landing page

Assets:

• FDC3 Favicon
• FDC3 logo on main page (above "Open standards for the financial desktop")
• Icons for four main areas on landing page, or include attribution for existing icons are from NounProject (e.g see how https://redux.js.org/ does icon attribution)
• Small FDC3 icon in blue banner across the top (currently FINOS logo)
• Large FDC3 icon in footer (currently FINOS logo)
• Schema images:
  • https://rikoe.github.io/FDC3/docs/api/api-spec - 3 schemas
  • https://rikoe.github.io/FDC3/docs/appd-discovery - 3 schemas
  • https://rikoe.github.io/FDC3/docs/appd-use - 3 schemas
  • https://rikoe.github.io/FDC3/docs/use-cases/use-cases-intro - 1 schema

Feature Request

Description of Problem:

FDC3 v1.1 is introducing the idea of Channels. Various Channel styles are supported but a common one is to allow users to assign application windows to a channel identified by a Colour. The Channel API allows an application to set the Context for a Channel and to get the Current Context for a Channel. The Context data type is not defined, but I believe it is expected to be an FDC3 Context expressed as JSon, but this is not specifiied in the API.

When there are multiple independent applications connected to the same channel, and the applications have different contexts do we need to specify how the different contexts are specified? And is each update an overwrite of the previous Context or should we try and merge Contexts?

For example say we have a number of independent applications that can 'set the Context' on a channel, and then various 'listeners' that try and display data related to the 'current context'.

Say one 'setter' is a CRM and it will set context using the Contact Schema. A second 'setter' is a Watchlist app and it sets context using the Instrument Schema.

We have a number of listeners, say a chart and a news app that can synchronise on an 'Instrument Context' and a 'Call History' app that shows recent communication with a Contact.

If the user clicks on an Instrument in the Watch list, the Chart and News apps should synchronise on the Instrument and the Call History window is unchanged.

The issue is what should happen when the user then selects a Contact in the CRM (and the CRM sets the Channel context to be a Contact).

Is the 'current Instrument' context deleted ? Or should the Channel Context be able to hold both a Contact and an Instrument, which implies that when an application sets a Channel context using the broadcast method, this is an update. This also implies that getCurrentContext on a channel needs to return a 'list of contexts'

If it is decided that a Channel context can hold both an Instrument and a Contact then we also need to discuss how a composite context like Portfolio which could hold both Instrument and Contact should be handled.

Potential Solutions:

The Context for a Channel should be a dictionary of Context types, so that it can hold a single instance of Instrument, Contact etc.

When an application uses 'composite' context like Portfolio it should set the Context for Portfolio, Instrument and Contact.

Feature Request

First, How do you want to receive these new intent ideas based on the UseCase working group's efforts? I thought I'd give a stab at an Issue, but we're happy to work however you'd like.

Description of Problem:

Use Case 9: https://github.com/FDC3/FDC3/blob/master/docs/use-cases/009-call-transcription-to-crm.md needs new intent and context for storing audio transcripts into a CRM.

Potential Solutions:

verb ideas: store/save/log?
noun ideas: AudioTranscript, Dictation

e.g. "storeAudioTranscription", "logDictation"

The context would need a payload of text to store, and which Customer in the CRM to store them under.

@nkolba

As we finalize JSON Schemas for the various Context Types, does it also make sense to build or integrate with some form of validator?

This would allow a user to easily verify that the context objects produced are correct

Maybe something like https://www.jsonschemavalidator.net/? It looks like be could just submit our schemas here - http://schemastore.org/json/

Thanks,

Johan

Support Question

Per site documentation:

If the raising of the intent resolves (or rejects), a standard object will be passed into the resolver function with the following format...

and elsewhere:

IntentResolution provides a standard format for data returned upon resolving an intent.

However, the call signature for intent handlers is as follows:

addIntentListener(intent: string, handler: (context: Context) => void): Listener;

As written, the callback does not return a value (it is void). Even if we changed this callback signature to return a data?: object property to provide a value to the resulting IntentResolution object, it is not clear from this API what would happen if a given application has added multiple handlers for the same intent.

Work in progress here: https://docs.google.com/document/d/1zrPkg4f_6yyySR01AuWKLJ9EFQ0n61ntzeRWFzobzsg/

• UC1 needs clean up around Workflow 4
• Must add UC15
• Remove dates from UC file names

I see a 1.0 beta release, https://github.com/FDC3/FDC3/releases/tag/v1.0-beta, but no v1.0.0 yet.

It looks like there have been 52 commits since the v1.0-beta tag.

Is there a v1.0.0 final release tag pending before the press release?

And will that release including none, some, or all of the commits to master since the 1.0-beta tag? (See too "Tag code as v1.0 and add release notes" task in https://github.com/FDC3/FDC3/issues/32)

Also ,I noticed the "Release Notes" link on https://fdc3.finos.org/versions is broken as it looks like it depends on there be a "v1.0" tag in github (Note, technically the release tag should be v1.0.0 -- one more ".0" to baseline minor releases)

(For a bit more context, see the foundation guidance re versioning at https://finosfoundation.atlassian.net/wiki/spaces/FINOS/pages/75530371/Released)

"documentation on this site" link is broken on help page

The IntentResolution type returned by raiseIntent is defined as follows:

interface IntentResolution {
  source: string;
  data?: object;
  version: string;
}

but the addIntentListener callback is defined as follows:

addIntentListener(intent: string, handler: (context: Context) => void): Listener;

which includes no way to return data back to the caller. It is therefore impossible to populate the data property with the 1.0 API, causing an API inconsistency.

There are three options:

1. Document and leave the inconsistency as is.
2. Remove the data property from the IntentResolution interface until it can be provided.
3. Amend the addIntentListener interface to include a way to pass data back to the caller.

Add the FDC3 roadmap document to the repository, and README, and link to it from the website.

API typescript should only define interfaces - not classes. This style should be enforced in standards reviews (and retroactively) and documented in the API docs and contribution guide.

There a couple of alterations that I'd suggest making to the API following my attempts at implementing it within our setup and how we expect it will actually get used

1. Can the default channel be be hidden behind a getter that returns a promise. That would make it's use consistent with the getOrCreate and getSystemChannels.

2. Could we modify the addBroadcastListener to take an optional array of context types. Then the interop broker would only notify the listener in the event of one of those specified types being transmitted.
   This gives the following advantages

• As it's possible to put anything on a channel, receiving applications will all have to put in their place their own filtering mechanisms to only receive the items that they
• Allows applications to put different context types onto a channel that can be picked up by different consuming applications. For example, two different instruments can be transmitted by app and treated in different ways by a number of different receiving apps - some may want both, some one, some the other.
  There is a downside here in that the channel will need to keep a history of the last received item by type, instead of just the last item - but that would just be a case of holding them within a map

3. Following on from 2, we would then need to add the same context type to the getCurrentContext method

4. In context of a requirement that we have with regards to window based channel selectors, and following on from https://github.com/FDC3/FDC3/issues/118 I would propose the following approach to managing window selectors

On the channels module in https://github.com/FDC3/FDC3/blob/master/src/api/channel/channel.ts
add a function something along the lines of

public addWindowChannelListener(listener: (event: {channel: Channel; context: Context}) => void, types: string[]): DesktopAgent.Listener;

Then the application does not need to know about or worry about the action of selecting a channel. The swapping between channels can be handled within the broker/router code.

If the user sets the channel to "off" then the application just doesn't receive anything
A DesktopAgent.Listener is returned should the application decide that it wishes explicitly stop receiving anything regardless.

To reduce the number of small concrete working group repositories (including this one), and the inconsistencies between them, the proposal is that the content (source code, examples, etc.) and documentation (markdown files) all be moved together into this single FDC3 repository.

This will help to:

• Create a single location in GitHub where people can go for information about FDC3
• Provide wider context for content and documentation from particular working areas.
• Allow issues and pull requests with cross-cutting concerns (e.g. affects both Intents and Context Data) to be evaluated by the whole FDC3 community.
• Website source is co-located with documentation and content.
• Can more easily use a documentation tool like Docusaurus.io without complex scripts to combine documentation and content from multiple GitHub locations.
• Simplify versioning for FDC3 as a whole.

Reference implementations, POCs and other related FDC3 repositories will of course still continue to exist separately.

Previous working group repositories should ideally be archived, but will continue to exist, and should be amended to point to the combined repository.

See also:

• https://finosfoundation.atlassian.net/wiki/spaces/FDC3/pages/711950361/FDC3+1.0+Release+Public+Launch+Documentation+Sub-Plan

OKRs and milestones, for the year, tentatively with a quarterly breakdown.

Should be added back to the FDC3 and FINOS Project Roadmaps (see: finos/community#19)

Feature Request

Description of Problem:

We have a use case that we currently support with our internal Channels where a user can turn off context sharing via the UI. We have exposed that as OFF channel in our channel selector.

In the FDC3 land, we have our apps which use the top level FDC3 API (broadcast and addContextListener) to send and receive context. They are unaware of Channels API and would work if they wrapped in a TitleBar that has Channels support vs a TitleBar that doesn't have channels support.
The TitleBar is what interacts with the Channels api and exposes a UI (dropdown select) to pick channel and that sets the channel for the app. The TitleBar acts as the router for the traffic.

Currently the way to have the off channel or turning off the context sharing based on some UI in the TitleBar (i.e. an OFF option in the dropdown) is by making the app aware of the TitleBar and removing the context listener when that OFF option is selected. This prevents our initial goal of app being unaware of Channels.

Potential Solutions:

There are few solutions.

• The TitleBar could create a AppChannel with an unique id per window and use it as the "OFF" channel for that window. As it is an unique id that no other window is aware of, no one can broadcast or listen to context shared by that window. - No API changes required. This is supported with current API.
• Similar to default channel, create a new System-level off channel.
• Add a myChannel.turnOff() API