Mastodon 4.x compatibility

[evanp]

So, we discussed at our last meeting what kind of strategy to take for dealing with these user stories.

One path is to use the object types and properties built into the Activity Vocabulary specifically for geosocial work: Place as an object type, Arrive, Leave, and Travel as activity types, and location and maybe tag as properties.

This is how ActivityPub was designed to work.

The main problem with this strategy is that it's not well supported on the Fediverse today. The ActivityPub Social API for submitting activities is only supported on a few server platforms, and many platforms will even discard activities they don't recognize when they're received over the ActivityPub Federation Protocol.

Another path is to add geosocial features to the current generation of Fediverse software and data, like Mastodon 4.x, which don't natively support the geosocial types and properties. This could happen using in-band place markers like Plus Codes or What Three Words.

The problem with this strategy is that it's limited in its functionality. It also avoids the responsibility of this group to point the way forward on geosocial representation on the Social Web.

[mayel]

How about attaching a preview as fallback as in https://helge.codeberg.page/fep/fep/b2b8/#long-form-text-with-preview ?

[WisTex]

I think we need to consider going to same route email did with HTML and plain text email. Send both versions of the message if we want richer formatting than a Note.

In the case of a Video object, we send a Video version of the object with rich information that video platforms can use, and then we also send a Note object as a fallback for platforms that don't support the rich video format.

Since Note is a format that most, if not all, fediverse platforms currently accept, we can use that as a fallback.

Also, some platforms may actually consume both, using the Note for lists & feeds and using the Video object for the actual video page.

This way we are not limited to Note, and we also don't try to pack ten million things unrelated to Note into Notes.

[trwnh]

many platforms will even discard activities they don't recognize when they're received over the ActivityPub Federation Protocol

i don't see a way around this without getting those platforms to change their understanding of the protocol. if they discard the activities, then they discard the activities -- that's their prerogative. the solution if you want those activities to be visible to them is to get them to stop discarding the activities. the way to process these activities without discarding them is to consume them directly.

using mastodon as an example, they currently have a concept of "supported types" and "converted types", but this distinction is only applied to a Create and its object. what mastodon should be doing is expanding the idea of a "converted type" to include any activity, not just a Create.object. if the type is not understood, a consumer SHOULD be able to use name, summary, and content to represent the activity. other properties like id and/or url can also be helpful.

the counter-argument is that mastodon might not care generally about activities other than Create/Announce/Like/Delete/Update (and specifically they only care about the objects). if you send mastodon a bunch of Arrive activities, mastodon might consider those activities to not be relevant. maintaining a "CRUD with likes and shares" worldview is likely a willful limitation of mastodon's intended user experience. if you disagree with this worldview, you can advocate for mastodon to change/expand its worldview to consider activities as first-class objects, and/or you can forge ahead with non-mastodon software that supports activities as first-class objects.

and indeed, this counter-argument applies more generally even with the scenario flipped. a consuming software that only cares about geosocial activities in the vein of foursquare/swarm might instead consume only Arrive activities and completely ignore Create activities! there is no requirement for every software to support every use case. the real pain point is that these softwares are monolithic and don't split the activitypub logic to its own component/server, thus necessitating multiple accounts even in situations where someone only wants to use one account.

[mayel]

Yeah @trwnh totally nailed the point. If there's a high chance of platforms like Mastodon not wanting to change their approach and we still want them to show at least a preview of our other activities, what if instead of e.g. Arrive activity with a Note as a preview, or an activity with two types ['Create', 'Arrive'] with a Note object and a location (which could probably be another alternative if type-as-a-list was supported by more implementations), we flip the problem on its head sending a classic Create with a Note object but which also has alsoKnownAs or similar with the Arrive activity. So apps who support uncommon types could first check there and decide whether to use that and ignore the parent Create/Note if they support a given type...

[evanp]

what mastodon should be doing is expanding the idea of a "converted type" to include any activity, not just a Create.object. if the type is not understood, a consumer SHOULD be able to use name, summary, and content to represent the activity. other properties like id and/or url can also be helpful.

I've been thinking a bit about this -- I agree that this is the right behaviour on the part of servers, but they don't always do it.

One thing that would be interesting is to have third-party services that "Note-ify" or "Image-ify" or even "Video-ify" activities and objects. So, if you follow evan%40experimental.example@notifier.example, every time the actor evan@experimental.example distributes an activity like this:

{
   "@context": "https://www.w3.org/ns/activitystreams",
   "id": "https://experimental.example/geosocial/arrive/33",
   "type": "Arrive",
   "actor": "https://experimental.example/users/19931",
   "summary": "Evan arrived at The Empire State Building",
   "to": "as:Public",
   "location": {
      "id": "https://places.pub/way/34633854",
      "name": "Empire State Building",
      "type": "Place",
      "to": "as:Public"
    }
}

...then the notifier actor distributes an activity like this:

{
   "@context": "https://www.w3.org/ns/activitystreams",
   "id": "https://notifier.example/activity/experimental.example/geosocial/arrive/33",
   "actor": "https://notifier.example/actor/experimental.example/users/19931",
   "type": "Create",
   "to": "as:Public",
   "object": {
       "id": "https://notifier.example/note/experimental.example/geosocial/arrive/33",
       "type": "Note",
       "content": "<p>Evan arrived at The Empire State Building.</p>",
      "to": "as:Public"
   },
   "alsoKnownAs": "https://experimental.example/geosocial/arrive/33"
}

...which will get properly ingested by notes-only servers.