go-ap: codified conceptualisation

[ppwfx]

I personally like to conceptualise by writing code. That's why quickly built a low level library in golang. It allows you compose, decode and encode ActivityPub objects.

Next Im going to build a lite microservice, implementing the basic ActivityPub endpoints.
That allows to tinker around with the communication layer and to extend it with the git specific types.

https://github.com/21stio/go-ap

[Foxboron]

We should maybe refrain from opening new issues as we have the mailinglist established now.

[ppwfx]

How would one, who isn't in the mailing list, become aware of this tho?

[Foxboron]

How would someone who is on the mailing list, but not on github, become aware of this? We can't have two discussion platforms. The example implementations isn't interesting until we have started to agree upon some parts of the specification, and people have written golang implementations of activitypub before (https://github.com/go-fed/activity).

[ppwfx]

I'll send it to the mailinglist once I figured out how to do it.

Reference implementations are a good way to find mistakes in specifications early.
A specification can be defined in the waterfall way or in an iterative one, I personally prefer the latter one.

And I'm very aware of https://github.com/go-fed/activity. The goal of the projects are very different tho obviously. go-fed/activity aims to implement fully compliant communication layer. Whereas 21stio/go-ap is a low level library that's only about composing, decoding and encoding ActivityPub objects.

[cjslep]

The vocab and streams subpackages specifically deal with encoding and decoding ActivityPub objects only. :)

[Foxboron]

Well, I realized the rewording on the README now and in retrospective the comment above from me might sound harsh. Sorry about that. It really was not meant to discourage your project.