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:
- Our new specifications make a whole lot of sense, and are beneficial to apply.
- 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.