Updates to the SFO Museum ActivityPub services

Earlier this year, in the blog post Holding Hands with the “Fediverse” – ActivityPub at SFO Museum, we announced the creation of ActivityPub accounts for all the objects in the SFO Museum Aviation Collection, in addition to over 6,000 accounts for individual aircraft (identified by their tail numbers) that have flown in and out of SFO and a number of other event-based accounts.

Since then we’ve largely left the system to “bake”, broadcasting scheduled messages to all the people who have subscribed to these accounts. We deliberately chose to start with publish-only accounts as a way to keep things simple and prove that everything could work in a low-cost serverless environment without the need for a lot of babysitting.

Today we are announcing a series of small, incremental additions to our ActivityPub-related services.

• Objects from the SFO Museum Aviation Collection (with ActivityPub accounts) have all been assigned aliases mapped to their accession numbers.

That means you can look up this rice wrapper from Japan Airlines by searching for @2020.074.0750@collection.sfomuseum.org (rather than @1746270885@collection.sfomuseum.org).

This should make it easier to follow objects (from the Aviation Collection) that you see on display in the terminals since every object’s wall label will include its internal accession number.

• Messages sent from aircraft (tail number) accounts will now call out, and send a copy of that message to, the airport and object related-accounts mentioned in the post and then those accounts will, in turn, “boost” the original post.

Since every post sent by an aircraft account involves the @SFOairport@collection.sfomuseum.org account subscribing to it (@SFOairport) is an easy way to receive copies of all the aircraft posts and the objects they spotlight without subscribing to every airplane with an ActivityPub account. We’ve also created a new set of ActivityPub accounts:

• Every gate in the SFO terminal complex now has its own ActivityPub account.

Like all the other accounts the primary identifier for each gate is their unique Who’s On First-style ID but since those IDs can be hard to remember, and harder still to guess, each gate also has an alias in the form of @gate + GATE NUMBER + @collection.sfomuseum.org.

For example the @1914601235@collection.sfomuseum.org, the ActivityPub account for Gate B27, is aliased to @gateB27@collection.sfomuseum.org.

Gate accounts don’t publish anything at regular intervals (yet) but if you send them a private message with the text “nearby” they will reply with the list of galleries, exhibitions and public art that are within walking distance of that gate’s waiting area. The nearby functionality is derived from the SFO Museum Wayfinding system so each item listed also contains a link showing how to get there from the gate you’re “talking” to.

The ability for SFO Museum ActivityPub accounts to both signal and promote one another provides a mechanism where people can subscribe to a single (SFO Museum) account can keep up with everything that all the other (SFO Museum) accounts are talking about. The introduction of a message processing queue, currently just to handle nearby requests, opens up a whole world of possible interactions between people inside (and outside) the terminals and everything SFO Museum has to offer. These small incremental changes and small and incremental in keeping with our goal “to keep things simple and prove that everything can work in a low-cost serverless environment without the need for a lot of babysitting”.

The rest of this blog post gets in to some of the technical details, and changes, that have made this work possible. If that’s not interesting to you this is a good place to stop reading and we invite you to enjoy all the new things the SFO Museum ActivityPub accounts can do.

As mentioned in the original ActivityPub blog post all of the code we are using to host the SFO Museum ActivityPub accounts is published as an open source package written in Go This code base is still in its infancy so we have yet to make any promises about stability or backwards compatibility and the changes described in this blog post have resulted in a major refactoring of substantial parts of that code.

The first version of the code was written in haste to figure out how to use ActivityPub to perform the most basic of “social media” tasks: Following and unfollowing other accounts and publishing and then delivering messages from one account to all their followers. As a result substantial amounts the code were designed around the specifics of “posting” messages which is only one of many different kinds of “activities” that, as the name suggests, ActivityPub is designed to support.

This became clear when we wanted to automate the process of one SFO Museum account “boosting” another SFO Museum account and so the first major change to the code base has been to update all the infrastructure that schedules and delivers messages from one server to another, itself a substantial part of running an ActivityPub-based service, to handle generic activities rather than specific “posts”. These changes reflect both a better appreciation of how things fit together and an ongoing critique of the complexities of implementing ActivityPub services from scratch.

Once you are able to wrap your head around some of the basics, like the fact that ActivityPub messages are essentially “envelopes” that deliver arbitrary “objects” with hints about what those objects are and how to process them (not unlike HTTP verbs), then everything starts to make more sense but the barriers to that understanding are still prohibitive. Hopefully the sfomuseum/go-activitypub package has now been updated to reflect that understanding and make performing and processing new and novel ActivityPub activities easier and faster.

The other major addition to the code base is the introduction of a “message processing” queue for messages (or ActivityPub “notes”) that are delivered to an account (hosted by a go-activitypub server). This queue allows for additional tasks related to a message to be performed outside of the initial server request and using code specific to the situation or goal. The message processing queue is how we implemented the “nearby” functionality described above and the go-activitypub package includes an example program demonstrating how message processing works and can be customized.

The goal for the sfomuseum/go-activitypub package is to have something that works for SFO Museum, first, but which can be used by others with a little bit of effort. Right now the code requires quite a lot of effort to use mostly because of the lack of comprehensive documentation (despite all the improvements made in this recent release). Now that the refactoring work necessary to implement all the changes described in this blog post has been completed we will let things “bake” again for a while and use that time to work on the documentation.