federation: use source instead of custom _misskey_content

[Johann150]

Summary

It would be more in line with the ActivityPub specification to use the source attribute defined by ActivityPub (see ActivityPub 2018 § 3.3) to convey the original MFM markup. The custom _misskey_content should be deprecated in favor of it. From the specification:

The source property is intended to convey some sort of source from which the content markup was derived, as a form of provenance, or to support future editing by clients. In general, clients do the conversion from source to content, not the other way around.

Example 8:

{
  "@context": ["https://www.w3.org/ns/activitystreams",
               {"@language": "en"}],
  "type": "Note",
  "id": "http://postparty.example/p/2415",
  "content": "<p>I <em>really</em> like strawberries!</p>",
  "source": {
    "content": "I *really* like strawberries!",
    "mediaType": "text/markdown"}
}

For MFM it could look something like this:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    // ...
  ],
  "type": "Note",
  "id": "http://misskey.example/notes/913n7143qa",
  "content": "<p>I <em>really</em> like strawberries!</p>",
  "source": {
    "content": "I *really* like strawberries!",
    "mediaType": "text/x.misskeymarkdown"
  },
  // ...
}

(The text/x.misskeymarkdown is just a suggestion that is compliant with RFC 6838 § 3.4.)

[Johann150]

The question is how to accomodate older versions of Misskey with this. I think for the time being we may want to send both for the time being. After some time has passed, the _misskey_content attribute could then be removed completely.

[Johann150]

you could/should probably use json-ld contexts to provide the migration path via aliases
@CosmicToast #8787 (comment)

In the case of Misskey and I think some other fediverse software ActivityPub is handled as JSON, not fully JSON-LD processed. So while I agree it would be good to have I don't think it is very important for our use case.

[CosmicToast]

probably still a solid thing to do given it's how the spec works, I think

[Johann150]

Thinking about it a bit more I'm not sure what exactly you mean with "migration path".

If you mean getting the deprecated _misskey_content property from source that will not be possible because it would require overwriting the core ActivityStreams context for the source property which is forbidden by the ActivityStreams specification. See Activity Streams 2.0 § 2.1:

Implementations MAY augment the provided @context with additional @context definitions but MUST NOT override or change the normative context.

If you mean getting the correct source property from the pre-existing _misskey_content property that is not necessary because newer activities will now have that property. Changing it in older versions of Misskey is not possible because Misskey embeds the relevant context in the activites and does not define it centrally.