I’m working on a little side project, an ActivityPub federated application for logging movies you’ve watched and adding reviews. If you’re familiar with letterboxd.com, pretty much that but ActivityPub.
I’m trying to decide how to represent a movie review in ActivityStreams, in a way that’s at least somewhat comprehendible by other applications.
When I first skimmed the vocab, I would have first reached for a WATCH activity of a VIDEO object, but it seems like to get along with Mastodon and anyone else, the primary representation should be a CREATE activity of a NOTE object. The NOTE could presumably have an attachment pointing to a linked data representation of the film.
Then I took a look at Bookwyrm. It uses a custom activity vocabulary, with an object types REVIEW and BOOK. When it delivers activities to non-Bookwyrm federated servers, it converts them to an ARTICLE/NOTE as appropriate.
Do people think it makes more sense to build up a custom vocabulary and translate to a common denominator when federating to other applications, or to just use a common vocab with some additional properties that my server speaks?
Do you have strong opinions or ideas about how a movie review should be represented on the fediverse?
Any guidance is appreciated. There’s obviously the spec and then there’s the whole world
I would strongly recommend using a Watch activity of a Video object, and then allowing Mastodon and other servers to translate as appropriate. Mastodon already has a lot of logic for translating non-Create / non-Note activity types, adding another small chunk for Watch would be pretty trivial i think
Err, goodness, I misspoke. WATCH isn’t in the ActivityStream2 vocabulary. There’s only “View”, which seems quite a bit more inappropriate.
If I went with the Bookwyrm approach, is there a best practice for identifying what extended object types a server does support? Do applications ever announce their extended vocabulary support in say Nodeinfo?
In a pure ActivityPub world, the question doesn’t really make sense. “Servers” are not the entities responsible for supporting / not supporting a given activity format. Instead, servers are supposed to pass extensions types directly without transformation to any clients the user may happen to be using. Therefore, a user may use one client that supports a given extension type and one client that doesn’t, based on what tasks they’re trying to accomplish. It’s up to the client(s) that don’t support an extension to provide some sort of fallback behavior for unsupported types to allow the user to know.
That’s why my strong suggestion is that you just federate out your Activity type as is, and allow other servers to add support for it.
However, that said, after thinking about it a little more, I think for a letterboxd-like platform, it would probably make more sense to make a Review object instead of a Review activity, because Reviews on letterboxed a much closer to articles with a special set of fields.
So a compatible activity you can send to other servers might look something like this:
Since this document specifies that the Review can also be interpreted as an Article, it should be compatible with most federated systems that have support for Articles
This is based on the ActivityStreams guidance around extensions: Activity Streams 2.0, especially Example 8:
If review is a short text, Note is the best choice. If review is a long text, or has rich formatting, I recommend Article. If you want interoperability with most Fediverse platforms, don’t use custom types or arrays of types.
Linking review to a movie is less straightforward. I would probably use context, or even inReplyTo.
They are not fundamental, most Fediverse platforms don’t support type arrays and are federating just fine.
Furthermore, multiple types just don’t make any sense. Is it Type1 OR Type2, or is it Type1 AND Type2? How one supposed to parse such object? Nobody knows. Implementers decided that type arrays is an anti-pattern and refused to support it. Now specs need to be changed accordingly.
Mastodon handles them just fine. If you prefer to shoot yourself in the foot with respect to extensions, you’re welcome to do so, but you’ll understand why people don’t want to federate with your application.
It’s AND—the object is both types, so you can treat it as either an Article OR a Review. You can think of it like implementing multiple interfaces in Java. If a 30 year old programming language supports it, it’s probably not as exotic of a concept as you think
An Activity is an Object, but I know what you mean. However, this topic has mentioned both custom Activity and non-Activity Object types, so the Mastodon limitation is relevant.
Multiple activity types is another issue – it’s undefined behavior due to each type carrying side effects and the possibility for some of those side effects to fail. For the same reason, multiple object nodes are similarly undefined behavior in several cases. But it’s not impossible to imagine that someone will find a use case for these eventually (assuming they have an answer for how to handle partial failures).
Ah yes, inReplyTo or even context do seem more reasonable here. I appreciate that suggestion.
Yes, I was thinking about relying on review from schema.org.
I think I agree that using C/U/D activities on a custom object type (that maybe also purports to be a Note for mastodon servers) seems like a meaningful path forward.
