Capabilities questions

[jmking-iftas]

1. "All provider specifications MUST be based on this one and MUST NOT change any of the requirements stated above." - does this mean "below"

and

2. "Every provider specification MUST define at least one capability. It MAY define more than one capability, but only if the capabilites are strongly related."

Can you elaborate on "strongly related"? are csam_detection and tvec_detection strongly related? What if I offer hate_classifier and baked_beans_identifier, do I have to set up two separate FASPs?

To add clarity, our intent is to offer classifiers for unlawful content, awful but lawful content, spam text classifier, domain labels, unsafe URLs, spam account detection, more to come. Are these all "strongly related"?

and

3. "Identifiers MUST be unique, which means they must not be defined in any other provider specification."

I don't know how to parse this sentence. If I offer spam_detection, I need to offer spam_detection_1046758 or something? Or will this spec define all possible identifiers that can be used in this spec? If so, do identifiers describe outcomes e.g. spam_classifier; spam_reporter; spam_deleter... or is it more "spam", and you sign in to the FASP to opt into actions/outcomes.

Second part of the same question, let's say we move the CSAM detector to FASP. At some point that process will allow an instance to opt into additional classifiers that aren't CSAM, so maybe sexually exploitative, or NCII, and we imagine the instance signing in to our app to opt in to additional classifiers. In our current model, we are an auxiliary provider with many options for many harms. Is the preference that we expose all possible options as independent identifiers? So csam, ncii, se, cg_csam etc etc, or do we subgroup them csam includes sg_csam and cg_csam, but ncii is separate

to tease this out a bit more, our model is

opt in to support for harm(s) eg csea, spam
opt in to specificity for each harm eg cse, csam, cg_csam, csam_se... or spam_content, spam_actor
opt in to action for content (not actor, not behaviour) we may allow opt in to have us delete content from a distance (specifically if matches on unlawful, delete remotely and prevent moderator trauma/exposure)

this then gets us options and granularity like "if csam, delete; if sg_csam, flag" or "if spam_probability >$threshold delete, else flag"

how much of this do you envision being exposed through FASP specs vs in-app at the FASP UX

[renchap]

I think that here we will have a "content_tagging" capability, or "content_filtering" (or both), but no capabilities based on the specific content that will be filtered. Capabilities are a technical thing, directly tied to some specific code paths to implement the feature.

I can imagine configuring an IFTAS provider on my instance, then in the provider's panel (not in Mastodon), be able to pick which categories I want the provider to filter (CSAM, Hate, spam…) which will enable those features in the provider. But from my instance perspective, it will be the same: ask an external source to know if some content needs to be flagged/tagged/removed/…

[jmking-iftas]

Understood, makes sense. To extend this a bit, we separate labels into one of three categories, Actor, Behaviour, Content, e.g. a Sock Puppet (Actor) might attempt Sextortion (Behaviour) using Spam (Content). Is there any use in having those extending the capability i.e. actor_labelling, actor_filtering, behaviour_labelling, behaviour_filtering, content_labelling, content_filtering?

I don't think there is, but you propose content_ which infers there should be at least actor_ (so as to act on accounts instead of content).

WRT "content_tagging" capability, or "content_filtering" (or both) - this too might be at the FASP level, as the instance may want "spam" labelled (perhaps flagged for on-instance human review) but "csam" filtered.

An example of how these might be surfaced is https://bsky.app/profile/labeller.iftas.org which has an example subset of the labels, here the "FASP" is a "labeller" and although the consumer here is end users, not instances, there are some analogous concepts.

BTW, I'm using "labelling" here as I think "tagging" implies adding descriptive tags or hashtags to content, which seems like a possible service someone might provide, but is not representative of a more formal labelling activity. "Tag" usually implies something subjective, "label" tends to be more objective/definitive. If "tagging" is to be authoritative, I'll switch back.

[oneiros]

1. "All provider specifications MUST be based on this one and MUST NOT change any of the requirements stated above." - does this mean "below"

The document originally was a single file. We split this into smaller files to make it easier to handle and then moved around some things. I think you are correct that "above" does no longer make sense here. Maybe we should replace it with "stated here" or "in this document".

2. "Every provider specification MUST define at least one capability. It MAY define more than one capability, but only if the capabilites are strongly related."

Can you elaborate on "strongly related"?

For "Fediscovery" we plan to tackle "trends", "account search", "account recommendation" and possibly at a later point "status search". These all fall under the umbrella of "search and discovery", but we decided those are separate capabilities and will each get their own specification. A provider can then implement one or two or even all of them. But even if it only implements one of them, that provider would still be useful.

So we will go with one capability per specification and I would like to encourage everyone that wants to contribute specifications to think along similar lines. But at this point we do not want to rule out specs definining more than one capability just because that makes sense in our single example.

are csam_detection and tvec_detection strongly related? What if I offer hate_classifier and baked_beans_identifier, do I have to set up two separate FASPs?

To add clarity, our intent is to offer classifiers for unlawful content, awful but lawful content, spam text classifier, domain labels, unsafe URLs, spam account detection, more to come. Are these all "strongly related"?

I think Renaud already answered that.

To elaborate a bit further: These specifications only define the APIs with which FASPs and instances communicate. It might be helpful to think what kind of API one needs for a specific use case and if other use cases might benefit from that same API. So instead of separate capabilities to scan content for X, Y and Z, a single "classification" or "labelling" capability might enable even more use cases.

At the same time we are currently still experimenting with the concept and do not have any production-ready implementations. So I think it is totally fine to try out different ideas and see which ones work best.

3. "Identifiers MUST be unique, which means they must not be defined in any other provider specification."

I don't know how to parse this sentence.

I wrote this with the expectation that (at least initially) all specifications will find a home here in this repo. So it should be easy to see which capabilities are defined and which identifiers are already taken. This might not scale very well and that is why #9 exists.

If I offer spam_detection, I need to offer spam_detection_1046758 or something?

No spam_detection would be fine, as would the more broad terms classification or labelling (content_labelling?) discussed above. The important part is that we will not have two separate specifications in this repository both defining a capability called account_search.

[jmking-iftas]

So instead of separate capabilities to scan content for X, Y and Z, a single "classification" or "labelling" capability might enable even more use cases.

Understood, and agreed.