What does ActivityStreams Conformance mean?

ActivityPub
1

I see a lot of times the conformance of applications being brought up in topics, e.g:

Indeed, what is “the entirety” and in that light what is Conformant?

It seems to me that ‘conformance’ (as applying to AS vocab) has a very broad range:

  • All properties are optional (including the id and type ).
  • Most properties are defined on the root Object type, applying to all sub-types.
  • Applications are free to define the semantics, e.g. choose to use Document for images.
  • And this applies to activities and social graphs too, e.g. my Create{Note} may have completely different meaning than yours.
  • Applications ignore objects that are not handled, or respond with an error.

And still be fully conformant, or not? Posts seem to criticize apps for non-conformance (looks to me), but is that justified?
Genuine question, because I don’t know if I understand the conformance part well enough.

1 Like
2

In this example, while it can be frustrating, it is not an non-conformant choice. The decision what type of object is most appropriate is app-specific.

Update: Whether that choice is a good thing for Interoperability is an entirely different matter. That’s where Capability Negotiation, Conformance Profiles and the current NodeInfo and FEDERATION.md are helpers to improve the situation.

3

Hm,
first off, it seems very strange to me.
If 30+ implementations use Image and 2 implementations use Document …

A Document is the most generic Object type - this is totally against all programming logic
“Be liberal in what you accept and strict in what you send”
Apart from that, I read the sentence
“Care should be taken to not unduly overlap with or duplicate the existing Object types.”
also as
be as specific as possible.

So, either "type": "Image" or
see the following Ex. 8 – that would then be "type": ["Document", "Image"] -
and it would even be compatible to all …

Capability Negotiation

Why should anyone at mastodon finally hear what we say? Years later?
I can write lots of words for a FEP but doubt, it would help.

Update
It is also a bad decision to let mediaType decide over ActivityPub type !
In the real world one ActivityPub "type":"image" can have multiple mediaType and this is super useful if you let the browser decide in the srcset, e.g. webp for modern or jpeg for old-school …
Even more critical with audio and video formats cause different browsers need different formats.

4

But you are making a case of what would be a best-practice to keep the highest level of interoperability between apps. That’s different than what Conformance means. The choices that Pleroma and Mastodon made wrt Document vs. Image are completely valid. Maybe not the most optimal for interoperbility, though.

That’s one of the biggest issues with the AS/AP specs as the Fediverse scales and will contain more and more different app types targeting different domains: The specs define format, but not semantics.

Semantics are hard, and are arguably why the Semantic Web failed, because there is no thing as universal semantics unless they are universally standardized.

This refers to vocabulary extensions which needs to be handled as in Example 8, but it does not say this also applies to objects from the same spec (may be good practice, idk). Quoting the full text:

Furthermore, while implementations are free to introduce new types of Objects beyond those defined by the Activity Vocabulary, interoperability issues can arise when applications rely too much on extension types that are not recognized by other implementations. Care should be taken to not unduly overlap with or duplicate the existing Object types.

Capability negotation

To me it seem for Capability Negotiation to be useful, it should unambiguously define the semantics of a remote endpoint you want to interoperate with.

What we have right now with NodeInfo is very basic for two reasons:

  • We only had to make it work for the Microblogging domain (the implicit ‘conformance profile’).
  • We only specified the absolute minimum, because even here completeness was deemed too complex.

To me it seems that something similar to ‘Conformance Profiles’ is needed in relation to Capability Negotiation. Here the profile is an agreement on what is minimally needed in terms of Objects, Properties format & semantics for e.g. a Microblogging app. The Profile can be documented as a FEP, and then metadata about the supported profile(s) can be used by applications.

That would be a relatively simple mechanism.

If you want to go a step further, things get complicated really quick. Maybe Shape Expressions Language will be useful?

The Shape Expressions (ShEx) language provides a structural schema for RDF data. This can be used to document APIs or datasets, aid in development of API-conformant messages, minimize defensive programming, guide user interfaces, or anything else that involves a machine-readable description of data organization and typing requirements.

About the choices Mastodon makes…

I would say they might listen, because of:

  1. Our new specifications make a whole lot of sense, and are beneficial to apply.
  2. Not doing so would risk to become a lonely fork of fedi, while all other apps go a different direction.

Point 1) means we should work on creating that, and 2) means we should continue to convince app developers on the benefits of spec alignment. The quality of 1) will be a convincing argument to do so.

5

Well, at the moment, yes because the quoted sentence in the spec. is not a MUST.
But in AS3 we could make “Use the most specific type” a MUST …
(or whatever it would be in correct english)

And then not all other 1000 implementors are hindered to write a generic validator without the need for ugly code like I just wrote

    if (APo.type.indexOf('Image') < 0 && (!APo.mediaType || APo.mediaType.toLowerCase().indexOf('image') !== 0)) {
		return ''
	}

In above APo.type is always an Array and a generic validator would just look if type is correct for the widget.

However, please note that the mastodon/pleroma examples are

invalid

The specification for mediaType clearly says :bug: :
When used on an Object, identifies the MIME media type of the value of the content property.

Unfortunately these poor examples try to describe the url property.
And as said, this does not make sense.
And the protocol authors are the clever people …

6

You are right. But technically, since there is no MUST, the meaning of mediaType in absence of content isn’t well-defined either.

7

It is an implicit MUST!

When used on an Object,

this is true for the given examples

identifies the MIME media type of the value of the content property.

means, it DOES identify the MIME media type of the value of the content property.

→

So, if no content then no mediaType !!!

Otherwise you would neglect the fact that every type can have multiple Link for multiple mediaType. This would not make sense.

side note:
There is an RFC for the use of MUST, SHOULD, MAY etc.
“Imperatives of the type defined in this memo must be used with care and sparingly.”
and if it does not make sense at all, they shouldn’t …