Disclosure labels: distinguish optional vs. required external accounts (section 4.7)

[davidpesce]

Discussed in #2

^{Originally posted by SergioComeron July 25, 2026}
Hi! Tier 1 maintainer of mod_jitsi here, with a real-world labelling case that the current vocabulary can't quite express.

My plugin is free of charge in its entirety, and its core functionality (scheduling and running videoconferences) needs no account of any kind. A subset of optional features (attendance reports, recording view tracking, usage statistics) requires a free account on an external portal, mainly so I can see which features and Moodle versions are actually used.

Under the current definitions in section 4.7 of the RFC I declared fully-free + external-account, which I believe is the most honest combination available:

• fully-free alone would under-declare — its definition says "no paid components or external accounts", and some features do use one.
• external-account alone would over-declare — the plugin page renders it as "External account required", which reads as a blanket requirement for the plugin to function at all.

Note that paid-service already handles this nuance with its "(in full or in part)" qualifier, but external-account has no equivalent.

A few possible fixes, in roughly increasing order of effort:

1. Badge wording only: render the label as "External account (some features)" or similar when combined with fully-free, since that combination already implies the account can't be required for core functionality.
2. Qualifier in the definition: extend external-account with the same "(in full or in part)" language as paid-service, and let the site render the softer wording.
3. Vocabulary split: external-account (required to function) vs. external-account-optional (only some features). More precise, but grows the vocabulary and every consumer needs to learn two labels.

I'd lean towards option 1 or 2 — the information "an external account exists somewhere in this plugin" is what matters for privacy/procurement review, and the required/optional nuance seems more like presentation than taxonomy.

Happy to PR whichever direction you prefer. And thanks for CAMP — claiming was refreshingly painless.

[davidpesce]

Thanks @SergioComeron, you've identified a genuine gap. The current definitions make fully-free and external-account contradict each other, and neither label alone describes your plugin accurately.

Here is what we propose, open for feedback before anything changes. The starting observation: the vocabulary already handles this exact nuance on the paid axis as a split rather than a qualifier, with paid-service as the required case and freemium as the optional case. The account axis is missing its equivalent, so a version of your option 3:

• external-account sharpens to "requires a third-party account for core functionality, even if free." The badge stays "External account required," which becomes accurate under the sharper definition.
• New label external-account-optional: "some optional features use a third-party account; core functionality does not." Badge: "External account (optional features)."
• fully-free gets one scoping adjustment so your pair is coherent rather than contradictory: "complete core functionality with no paid components and no external account required." mod_jitsi would then declare fully-free + external-account-optional, which says exactly what is true.
• paid-service would drop "(in full or in part)": the partial case is freemium's territory by its own definition, and removing the qualifier makes the two axes parallel. Required is paid-service / external-account, optional is freemium / external-account-optional. Existing paid and freemium declarations would be audited before this ships so nobody's listing changes meaning silently.
• Housekeeping on our side either way: the site currently has two badge-wording tables that disagree, and one of them rendered your case as the blanket "External account required," which is what you noticed. They will collapse into one.

The reason we prefer a new label over inferring optionality from label combinations: required-versus-optional matters for privacy and procurement review, as you said, so it should be machine-readable on its own.

Thanks for a case report precise enough to design from.

[SergioComeron]

Thanks — the split convinces me, and for the reason you give rather than the one I argued: I was treating required-vs-optional as presentation, and you're right that if it matters for privacy and procurement review it should be machine-readable on its own, not inferred from a combination. fully-free + external-account-optional describes mod_jitsi exactly, and the scoping fix to fully-free makes the pair coherent.

One objection, to the fifth bullet only: dropping "(in full or in part)" from paid-service opens on the paid axis the same gap you are closing on the account axis — and mod_jitsi is the example again.

The two pairs are not parallel, because they do not measure the same thing. freemium is about who charges: the author paywalls part of their own plugin. paid-service is about a third party charging, whoever ends up paying. Those coincide in the required case, which is why the symmetry looks clean, but they come apart in the optional one.

mod_jitsi has no paywall of mine — it is free in its entirety and I sell nothing — yet several optional features bill the site directly to a third party: AI summaries and quiz generation run on Google Vertex AI, the auto-managed server type provisions GCP VMs, and 8x8 JaaS is one of the supported backends. The common case, a self-hosted Jitsi server, costs nothing external. Under the proposal that plugin is not paid-service (it no longer covers the partial case) and it is not freemium (nothing of mine is paywalled; there is no paid unlock). It falls out of the vocabulary — the same under-declare/over-declare bind that started this thread, moved one axis over.

Two ways out:

1. Keep "(in full or in part)" on paid-service.
2. Complete the symmetry: paid-service-optional — "some optional features require a paid third-party service; core functionality does not."

I would prefer (2) now that you have made optionality explicit on the account axis. It grows the vocabulary by one more label, but it leaves freemium meaning purely "the author monetizes this plugin", which for procurement is a genuinely different fact from "this optional feature will appear on your own cloud bill". Under (1) those two stay blurred together.

A footnote on migration: the audit you describe should cover existing external-account declarations too, not only paid-service and freemium. Under the sharper definition, any listing whose account is used only by optional features now over-declares — starting with mine, since plugins/mod/mod_jitsi.yml currently reads fully-free + external-account. I will send that correction as a PR as soon as the new label exists.

Happy to PR the RFC wording for whichever direction you land on, and thanks for taking the case seriously.

[davidpesce]

Still working on this. We'd like to get it right! We created a series of questions that may help evaluate plugins. Take a look here: https://claude.ai/code/artifact/cc2949b7-a197-42de-a50c-23e158c6b147

If you encounter a scenario that does not fit, screencap and share the resulting labels and questions. This will let us troubleshoot where changes are needed.

[SergioComeron]

Ran mod_jitsi through the walkthrough. Answers: Q1 yes, Q2 yes, Q3 yes, Q4 yes, Q5 yes; neither promotional label. Output:

labels:
  - self-contained
  - external-account-optional
  - paid-service-optional
  - companion-service-optional
  - first-party-service

The good news first: paid-service-optional and separating who-profits from what-it-costs do exactly what I was asking for, and the deployment axis is something I would not have thought to ask for and obviously needed — for a videoconferencing plugin the ops burden is the single most consequential thing an administrator has to know before installing. Three of those five lines are right.

Two are not, and both point at something structural rather than at wording.

1. self-contained is false, and the walkthrough produced it from truthful answers

The gloss shown to administrators reads "Works out of the box; nothing external is required for the core job." mod_jitsi ships with meet.jit.si as its default server — the installer inserts that row. So with nothing configured the core job does work: you get a videoconference, with no account, no purchase and no service to deploy. Each of Q1's three exclusions is literally satisfied. And yet every participant's audio, video and connection metadata goes to a third-party server operated by 8x8. For privacy and procurement review, which is what these labels exist for, self-contained is the most wrong thing that listing could say.

The gap is that the three axes are account, money and ops burden, and this dependency has none of the three: it is free, anonymous and zero-maintenance — and still a data processor. Note that the Account row's own subtitle is "where identity and data go", which is the right question; the label under it only fires when an account exists, and data leaves without one.

Two possible fixes, and I have no strong preference: either the account axis becomes a data axis, with something like external-service that does not depend on an account existing, or self-contained gets a guard question of its own — "out of the box, does the plugin send any data to a service outside the Moodle site?" A plugin whose shipped default points at someone else's server should not be able to reach that attestation.

2. first-party-service is one bit, and I have four dependencies that answer it differently

Dependency	Author's own?	Author profits?
Statistics portal (attendance, view tracking, usage)	yes	no — free, gives me feature and version usage data
Google Vertex AI (summaries, quiz generation)	no	no
Google Cloud (VMs, GCS storage)	no	no
8x8 JaaS	no	no

The label attached because of the first row and will be read against the other three. Anyone seeing first-party-service next to paid-service-optional will conclude the cloud bill lands with me. It does not: I sell nothing, and the one service that is mine is free and exists so that I can see which features and which Moodle versions actually get used.

Two separable fixes. Attach the modifier to the label it modifies rather than to the listing — external-account-optional: first-party next to paid-service-optional: third-party — and split ownership from profit. Q5 asks ownership on its main line ("is any outside service or paid product you just declared the author's own") and reframes it as benefit in the subtitle ("do the people behind the plugin benefit when sites use that dependency"); for my portal those two give opposite answers, and the gloss an administrator ends up reading is the profit one: "their commercial interest is disclosed."

3. The structural one: my dependency profile is a configuration choice, not a property of the plugin

A site running mod_jitsi picks a backend: the public instance (third party, free, no ops), a self-hosted Jitsi server (no third party, real ops burden), 8x8 JaaS (third party, account, paid above 25 monthly active users), or GCP auto-provisioned by the plugin (third party, account, paid). That is four different label sets for one listing.

I answered Q1 "yes" because of the shipped default. A production administrator would answer "no" — meet.jit.si caps embedded conferences at five minutes, so nobody teaches on it — and that answer moves the deployment dependency into the required column and removes self-contained altogether. Same plugin, same honest intent, two defensible declarations.

This is not only my problem: every videoconferencing, storage and AI plugin has a backend menu. It may be worth deciding explicitly whether a listing declares the union of what any configuration can require (over-declares for the self-hosted site), the shipped default (under-declares for everyone else), or whether labels need a per-configuration dimension. The union plus a "depends on configuration" marker seems least misleading to me, but that is a design call and not mine to make.

None of this is an argument for slowing down. The ten-label matrix is a clear improvement on what shipped, and I would rather declare mod_jitsi in that vocabulary with these two fixes than in the current one.

[davidpesce]

@SergioComeron This is great feedback!

Did some brainstorming with the team and we have a new wizard. For 80% of the plugins, a user simply answers the first question and generates their label. For the remaining 20%, they'll need to walk through a bit more. But it does give both the author and plugin consumers full disclosure about the plugin (we hope).

Take a look and let us know. I also asked the CAMP matrix room to go through the wizard with a specific plugin in mind (even if it isn't theirs). Hopefully we got it right, but if something else comes up, we can adjust.

https://claude.ai/code/artifact/2ec939f9-1802-48ba-b6fd-23b43cfcbc8c

[SergioComeron]

Ran mod_jitsi through the new wizard. Short version: all three problems from my last comment are gone, and the per-dependency schema is a better answer than the one I proposed.

Specifically. The rewritten first question closes the back door to self-contained — "in any configuration or through any optional feature" also settles the point about my dependency profile being a configuration choice, since it no longer matters which backend a site picks. The "who operates it" question captures what none of the three axes could: meet.jit.si is free, anonymous and needs no deployment, yet the video of every participant leaves the site's control. And declaring facts per service removes the flat first-party ambiguity entirely — the flag now sits on the one dependency that is mine and not on the ones that bill the site. interchangeable plus "Backend required: varies by configuration", with a fact promoted to a firm badge only when every alternative shares it, is more precise than the "union plus a marker" I suggested.

This is what mod_jitsi declares:

external-dependencies:
- service: Jitsi Meet server (meet.jit.si by default)
  relation: required
  interchangeable: true
  hosting: hosted
  account: none
  cost: none
- service: Self-hosted Jitsi Meet server
  relation: required
  interchangeable: true
  hosting: self-hosted
  cost: none
- service: 8x8 JaaS
  relation: required
  interchangeable: true
  hosting: hosted
  account: required
  cost: paid-tiers
- service: GCP-provisioned Jitsi server
  relation: required
  interchangeable: true
  hosting: self-hosted
  cost: paid
- service: mod_jitsi statistics portal
  relation: optional
  hosting: hosted
  account: required
  cost: none
  first-party: true
- service: Google Vertex AI
  relation: optional
  hosting: hosted
  account: required
  cost: paid
- service: Google Cloud Storage
  relation: optional
  hosting: hosted
  account: required
  cost: paid
- service: YouTube (live streaming)
  relation: optional
  hosting: hosted
  account: required
  cost: none
- service: Jibri recorder
  relation: optional
  hosting: self-hosted
  cost: none

That is an accurate description of the plugin, which is the first time any version of this vocabulary has managed it. Two things surfaced while filling it in.

1. Skipping the account question for self-hosted services loses a real fact. The GCP-provisioned backend is operated by the site — the VM runs in their own Google Cloud project, so self-hosted is right by your definition — but getting there needs a Google Cloud project, a service account and billing enabled. The wizard skips account for anything self-hosted, so my entry cannot say that. The assumption "self-hosted implies no account" holds for a companion you install on your own hardware and breaks for the bring-your-own-cloud pattern, which is increasingly how plugins provision infrastructure. Same would apply to any plugin that deploys into a site's AWS or Azure subscription.

2. interchangeable does not say what it is an alternative to. It is a bare boolean, so a plugin with two independent menus — say a videoconferencing backend and a storage backend — cannot express which alternative belongs to which function, and the "varies by configuration" badge would merge two unrelated menus into one.

It also invites a specific mistake. My first pass declared Google Cloud Storage and YouTube as interchangeable, because both end up listed as recordings in my UI. They are not alternatives at all: GCS holds what Jibri records, YouTube is where live streaming ends up, and no administrator ever chooses between them. I only caught it by rereading my own code. Asking "what function does this service provide?" before "is it the only way, or one of several?" would make that error impossible, and would give interchangeable the grouping key it currently lacks.

One observation on volume, not on correctness. mod_jitsi produced nine entries and roughly forty answers. The facts are right and I do not think the schema should be simplified to spare me clicks — but you are aiming for one question to settle 80% of plugins, and the tail is heavier than it looks: four of my nine entries differ from each other in one or two fields, since they are alternatives for the same function. Letting an author clone an entry and change what differs would cut most of that without touching the model.