Notes from Cory regarding the go-fed binary footprint

Bonjour,

In preparation for tomorrow’s videoconference I asked Cory about his thoughts to reduce the binary footprint of go-fed. Here is a copy of his reply:

I am not sure what you mean by footprint (amount of code, binary size, number of interfaces to implement). A few things from the top of my head depending what is meant:

  1. The go-fed/activity/pub is totally optional. It can be adopted wholly, early, but it is designed to “fall away” as an implementation codes more of its own ActivityPub implementation. (Pro: quickly bootstrap, Con: Glue code). That can be an option, or you can go the Own cast & WriteFreely approach and write the ActivityPub stuff entirely upfront (Pro: less go-fed stuff, Con: higher upfront cost)

  2. Binary size - almost entirely due to code generation. Would need to adjust the astool to appropriately prune its internal tree before generating code. However, this certainly means Gitea (and others) would have to maintain a fork for ActivityStreams as the go-fed repository just continued to host the “complete picture”. The astool code is not easy to understand.

  3. Number of interfaces to implement - again, it depends how “correct” an implementation wishes to be and whether it wants to adopt go-fed/activity/pub at a high level (ex: GoToSocial), low level, or not at all (ex: WriteFreely, Owncast). Go-fed – perhaps with a sense of brutal rigor – tried to make it as explicit as possible, showing how difficult it is to “isolate” ActivityPub from the core application. If Gitea is OK with making ActivityPub a deeply integral and tightly coupled part of the application, go-fed is less useful. As its core design goal is to “cleanly” (ha) separate ActivityPub protocol from the actual application. Hence the rise of numerous interfaces.

Hope this helps.

2 Likes