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.
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
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
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.
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.
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.
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.
The other repositories are for presentations, tests, or integration results. These will continue to be ignored until morale improves.
Other random thoughts I’ve had:
apcoreapplication that could be built would be a programmatic integration test suite, much like test.activitypub.rocks, but even more automated
- Adding a transport in
activitythat uses SSB (scuttlebutt)
FEDERATING.mdor whatever it is called, I haven’t kept up to date with this trendy document amongst Fediverse developers
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