Content-Fallback for Unsupported Activity Types

ActivityPub
1

I wrote a piece on my blog earlier today, musing over whether or not there might be a way for platforms to define fallback activity types for rendering unsupporting activities. Currently, this is determined by the recipient, but leads to situations where the recipient platform has to either play whack-a-mole with a bunch of new activity types, or define standard behavior across the board (eg, the old “Note with an activity Link in it” approach).

I’m musing over the possibility as to whether a proposal for Sender platforms to provide a fallback activity might be a viable approach for improving interoperability, and whether this could be a valid proposal for a FEP? It’s something I’ve been thinking about for a while, and would love to see, but it would be valuable to get some input from people smarter than me.

1 Like
2

why wouldn’t this “fallback activity” be the actual activity? surely if it’s possible to represent something in a “compatible” way, there would be no need to do so in an “incompatible” way? in any case, an activity that isn’t “understood” may still be displayed based on the name/summary/content. you might say that extension activities SHOULD provide a summary so that this summary can be displayed in their stead.

1 Like
3

+1, but I think this should only apply to objects.
If activity is not understood, it would be better to ignore it, or accept but not display to a user to avoid confusion.

4

This only matters if the activity has intended side-effects. Otherwise, it’s perfectly valid to not discard the following:

{
  "actor": <john>,
  "type": "Florp",
  "object": <object>,
  "summary": "John florped a honkytonk"
}

In its purest form, this is just a Linked Data Notification. In ActivityPub terms, it’s a no-op on the local data store, but that doesn’t mean the norification is useless or meaningless.

2 Likes