In my quest to build an #ActivityPub based simple, no-frills bulletin board / forum system, I've gone ahead and pushed up my work-in-progress #golang ActivityPub single server framework: apcore. It has no README (yet) and still has a lot left TODO.
I hope to use it in the future to launch multiple small ActivityPub applications leveraging common serving, storing, and moderation features. But new #ActivityStreams vocabulary can be readily innovated upon.
As frameworks are communal, it is my hope that innovations and optimizations that others bring can then be leveraged by multiple projects. And helps give smaller software projects a larger voice in the development in the Fediverse. I haven't thought much about go-fed governance, and am very receptive to ideas.
Also, as it is built on go-fed/activity, adopters are able to support either, or both, the Server-to-Server (federation) protocol and the Client-to-Server protocol.
A licensing note: the go-fed/activity libraries have been and still are Open-Source licensed (BSD). Proprietary Fediverse projects, like write.as, are free to continue using as much or as little of these libraries to build server applications from scratch. It is complex due to the sheer amount of customization.
However, as go-fed/apcore is a server framework and therefore much more of a plug-and-play, hand-holdy, almost-an-application kind of situation, I've licensed it as FLOSS under the AGPL-3.0 license
...and in time-honored Fediverse tradition, since the code isn't finished yet, I should tag this whole thread with #soon.
@cj This is awesome, and sounds like it could be used to test/expand private communication cases mastodon doesn't really address.
@unlofl I'm glad you think so! I have no idea what'll come out of this, time will tell.
@cj One day I shall take my one and only super tiny Go Lang project (a tiny wiki) and add some go-fed and magic sauce and there will be magic. Or something. 😀
@kensanata I hope one day I can make that magic happen easily! It'll be some time though, I fear.
GoLang has this pattern called interfaces that's really handy for when an object has different representations, e.g. html, text, and json views of an object decoded from Markdown with Pandoc metadata. What do you know about the performance implications of how this is implemented or how I can look it up?
Yes, that overly specific examples is relevant to your project 😂
@yaaps Golang interfaces are compile-time duck typing and so there's no additional runtime overhead beyond a usual pointer.
This forces Golang to use composition instead of inheritance. Basically, interfaces are "do-ers" so HTML, Text, and JSON types could satisfy a "Renderer" interface that just has 1 method "Render", and as long as each of those types implements it (enforced by compiler) there's no additional overhead to passing the stuff around.
Thanks. That was the perfect resource for understanding the performance profile of interfaces as a language feature
It's what I expected. Interfaces are at a right angle to expectations of functional programming, but the compiler should do the right thing if you write in functional patterns:
Thinking of an earlier conversation with @kensanata about what might be available to build a better home instance (than Sputnik Opphuichi) for end to end ActivityPub. If I can avoid implementing OAuth server and hardening Sputnik for open registrations, I can start working on fun stuff much sooner
Definitely worth some time in the repo next week after I catch up on a few things
@phoe You're not wrong.
They use the go-fed/activity library (forked at a specific revision) for both the free and the proprietary codes:
It's been a while since I talked to Matt and I don't know if he'll keep using it or not.
@cj awesome, this is something I’ve been looking for!
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either! We adhere to an adapted version of the TootCat Code of Conduct and have documented a list of blocked instances. Ash is the admin and is supported by Fuzzface, Brian!, and Daniel Glus as moderators. Hosting costs are largely covered by our generous supporters on Patreon – thanks for all the help!