Follow

The go-fed library now has a website. It has a 1999 landing page, a tutorial held up by smoke and mirrors, and Go documentation autogenerated by gnomes.

The server hosting it is tiny so please don't hug it to death.

go-fed.org/

Still not convinced? How about a stupid slogan:

"Why wait 'til tomorrow? go-fed.today!"

ยท Web ยท 0 ยท 15 ยท 24

@cj If it's just a static website, maybe consider putting it on IPFS so other people can help host it? I'd certainly be willing to pin it on my node!

@swedneck Great suggestion! The tutorial and homepage are static HTML. Unfortunately the docs are dynamically generated. But, I'm think I can just have the server write a generate bunch of flat HTML files that would be a static version. Then it could be used to host on IPFS.

I'll have to look into it more, so it may take some time before I can get to it.

@cj I had a read at the tutorial, I found it very interesting.
I'm probably not going to use the library (because I dont have the skills), but it realy helped me underatand a bit more about AP.

Thank you for putting nice documentation (and library I'm sure) available to the world.

@cj Awesome!!! Already using the `streams` library in the @write_as implementation, and just saw the new `deliverer` package -- exactly what I needed at this exact moment! Going to be trying that out tomorrow.

@matt @write_as Whoa! I had just recently added write.as to my list of things to check out. I had no idea it was written in golang, let alone that you'd be using any of the go-fed stuff.

Please do not hesitate to reach out to me, file issues, etc in the future if any of the go-fed libs give you unexpected trouble, or you have improvement suggestions.

@cj Will do! I'll probably be using a hybrid of go-fed and some custom libraries I've already written for getting Write.as federating quickly, but for future AP projects like Read.as I'm planning to use go-fed entirely. Will keep you updated with how it's all going.

Just curious, are there any full example applications that implement it today?

@matt Unfortunately no. You, @tuxether and @peerpx have all expressed interest in the library at some point. So I am especially keen on all of your feedback.

It's on my todo list (literally: I am weird and carry a tiny notebook with a pen on me at all times) to get go-fed on the official implementation report. I expect there may be some S2S bugs uncovered then that will need fixing.

Would you be able to share the timeline for Read.as? (I'm prioritizing my free time; but am moving in mid-August)

@cj Very cool, I hope you can get it in the official report!

Read.as probably isn't coming until the end of the year unfortunately. I'm juggling several different projects, and it's a bit further down the list of priorities. But I'm going to put up the source code as soon as I get the basic application put together.

@matt Awesome! Thanks for giving me a rough idea of the timeframe. I feel slightly less bad for prioritizing a couple other life things before I have another sprint to work on the lib.

@cj Of course, don't feel bad about that! What you've done so far is great.

@cj Also not sure if you saw this -- a little Go library I built for publishing nodeinfo: github.com/writeas/go-nodeinfo

Maybe we could make it work with go-fed? (Though that might be more out of scope.) Either way thought you'd find it interesting.

@matt That does look cool! I was not aware of that library, thanks for sharing. What kind of ideas did you have in mind for having it work with go-fed/activity?

@cj I was thinking something like where pub.Application could also have a func that returns all the necessary NodeInfo (or just up-to-date stats, and the rest of the static metadata comes from somewhere else) so that applications could wrap it in an http.HandlerFunc.

But that was just my initial idea looking at the documentation -- I'm not sure if there's a better way, or if it being a part of go-fed makes sense.

@matt Ah ok, yeah I am not sure either. I haven't looked into the NodeInfo standard at all, so if go-fed/activity already has information that makes populating NodeInfo information simpler, it'd be compelling to support.

However, since I am unfamiliar with NodeInfo, I'm not sure if there's anything go-fed/activity could auto-include of value.

@cj Very true. I guess maybe I'm thinking it'd be nice to bring all these components together in one place (go-fed, nodeinfo, webfinger, etc.) so that starting to build a federated app is more straightforward. But that might be a more fitting job for sample projects and tutorials, rather than putting everything in go-fed.

@matt Hey I know you mentioned you're using `streams` in this message. I am looking at the next major version release of go-fed and am thinking of shifting a lot of usage over to `vocab`, for a variety of reasons. End result would be a lot of `:%s/streams/vocab/g` but I wanted to get your feedback as an early adopter.

@cj Cool, I'll comment there as I have more to say. But at first glance I don't imagine that change being too much of a problem

@stevelord Haha, I would if "yourself" or "self" were TLDs! Right now I just have go-fed.today redirecting to the .org TLD.

@cj jesus, that's a monster of a library. I hope mine will be simpler to use. ๐Ÿ˜ˆ

@mariusor Lol! It's conceptually simple, but yes very big in practice.

What language are you writing your library for?

@cj Go, of course! But I think it's a long way from being useful. :)

My starting idea was to keep the structs as close as possible to the activity streams vocabulary definitions and implement the weird "it's an object, no it's an URL, no it's something else" behaviour of the elements as a function of Marshaling/Unmarshaling from Json. Experience from using it in the past months makes me think might not be the best idea. :D

If you're curious, find it at: github.com/mariusor/activitypub.go

@cj Also I'm a go noob - which is probably obvious from the contorted ways I am using the language in the lib itself.

Sign in to participate in the conversation
Mastodon for Tech Folks

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 follow the Toot Cafรฉ 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!