Go-Fed 2020

The biggest inhibition to go-fed getting more visibility the two years it has lived has been myself. My limited time as a “weekend warrior” coupled with my complicated approach to shoving the flexibility of ActivityPub’s RDF roots into code-generation-time yet strictly enforcing the ActivityStreams ontology at compile-time has meant that the past two years has really been about laying down a firm foundation.

In the meantime, the go-fed website has languished. Not only is the documentation severely out of date, but the site’s certificate has long expired. I can come up with great excuses like “my dog ate my renewal application” and “my spleen hurts”. But the truth is a lack of time. Hopefully, it’ll move up in my list of priorities sooner than later.

Ich lernte ein bisschen Deutsch. Ich muss mehr lernen, damit ich besser integrieren kann. Meine Frau und ich lernen B1 jetzt. Wir hören besser zu als wir schreiben. Wir verbringen viel Zeit mit Lernen. Wenn ich lerne, ich keine Zeit zum Programmieren habe.

Let’s go through the different repos of go-fed.

activity library

The core of the ActivityPub implementation. After the rewrite last year to the v1 API, I am pretty happy with where it has landed. Don’t get me wrong: it is still a very tough library to use. But such is the price for having compile-time verification that an implementation isn’t trying to do anything funny with the protocol. I don’t foresee any major work in the coming year for this library, except when it comes to implementing unit tests. That’s something I’ve been putting off, for the simple reason that there’s a lot to be written. It’s just a pile of uninteresting work that needs to get done. Unfortunately for that pile, I have a different stack of more interesting work at hand.

I’ll be adding a doc.go or pkg.go file to have package comments, because I’ve received a few emails that roughly say: “Please help, I downloaded your library with go get but it says ‘no Go files in github.com/go-fed/activity’ and this is urgent please help me!” to which I will say: there are 2 sub-libraries with helpful README.md files: go-fed/activity/pub and go-fed/activity/streams for ActivityPub and ActivityStreams respectively. Check those out first.

I’ll need to revisit all the issues in the repo and do a prune / cleanup.

httpsig library

The straightforward-to-use HTTP Signatures implementation. Like the activity library, I am happy with where this has landed. There’s some open suggestions others have called out, so I will need to take care of those.

The only major piece of work I see on the horizon is providing an implementation report for the group writing the standard. Unfortunately, the tool of theirs I have found requires some engineering work to get the implementation to interface with their tooling properly. It would be possible for such a tool to have a bug of its own, outside the actual HTTP Signatures library, so that’s a whole project that would need some tender love and care. At this time, I am not terribly keen on pursuing this. If someone else were to do it: great! I’ll cheer on.

I did see a bug was opened about SSHAgent. Rather than support SSHAgent specifically, I think instead I’d provide a way for the user of httpsig to generally hook into the HTTP Signatures flow in a SSHAgent-like way. Therefore if such a user wants to implement SSHAgent themselves, they can do so separately from the httpsig core functionality.

apcore library

If using the activity library is like being handed a hammer to face off an opponent wielding a flaming chainsaw that runs on the blood of their enemies while riding a motorcycle whose tires are tank treads all while having Dethklok’s Gears blasting at volume 11, then the apcore library is like putting a person into a soft padded pit full of cute puppies that routinely fetch everyone cotton candy and play with their friends the baby flying unicorns.

It is still incredibly incomplete, but is meant to be an out-of-box server framework for Fediverse applications that need to run small-to-medium communities. While its API is designed to be declarative and thinly called by an implementor’s main method, it is still a framework. This design ensures I am not building an application, just a library or framework, even if it is heavy handed to make sense in an ActivityPub world. The trick is making sure it can still retain the flexibility of the original go-fed library, and so far I think I have been succeeding.

I think part of the lack of appeal of the activity library is that it indeed can do anything. Whereas apcore will be far more out-of-the-box.

This is where I see most of the go-fed effort going in 2020.

site binary

This powers the go-fed website. It used to automatically pull down the activity repo and publish GoDoc at tags and HEAD versions. However, that got unwieldy even with thin pulls. That is also why it wasn’t integrated with certbot out of the box. Instead, I think in the future I’ll just go with an out-of-the-box static solution and trim down this repository to just be content.

I think this will be important for 2020 even if there’s little to do besides writing.

Other repos

The other repositories are for presentations, tests, or integration results. These will continue to be ignored until morale improves.

Concluding remarks

Other random thoughts I’ve had:

But, I won’t have time to work on these in 2020.


Created: Feb 04, 2020 17:47:00 EST
Last Updated: Feb 04, 2020 17:47:17 EST
By: Cory Slep

Fediverse Comments