|
|
|
|
|
by orblivion
1300 days ago
|
|
Thanks, I appreciate that you're interested in this feedback. I didn't know how much I should be bombarding the github issues. I posted the github issue in fedbox about making cs2.md easier to find. (to that end - if there's a hidden wiki, make it not hidden!) Nothing in particular is giving me trouble. It's just that reading through fedbox (which I think is billed as a "simple" example) there's a lot going on and I don't know what exactly I'm looking at or where to start looking (though over time, especially after finding cs2.md, I'm starting to). The first hook for me was the definition of the "Service" actor, and I said "ah hah. so if I do this, but make it a Person, and fill in these attributes, it'll help me generate a json response of a Person actor" Then after spending time looking at errors with json.Marshal I realized that I need to be using jsonld.Marshal instead. That detail was never put in front of me. Then I had to dig through various repos to find how to add the "@context" fields. Right now I'm figuring out what exactly the Inbox and Outbox things do for me (maybe just generate a path?) And so on. I don't imagine this is how you want us to figure out how to use go-ap. Similar to the go-fed developer, it seems like you may not realize how much understanding you're taking for granted. I think someone like me could benefit from a real stripped down example, no currying (pretty cool, never seen it before in Go, but a bit confusing), no layers of indirection, normal Go http handlers, the simplest database option. Let me do fancy abstractions in my own app once I learn how the libraries work. And/or a README that gives the lay of the land. |
|
FedBOX was meant to be a "simple" example, but that was some years ago, and as these things go, I piled on work on it and now supports multiple storage backends, has its own oauth2 end points and storage, etc. I'm actively working on extracting from it the pieces that can be independent, to leave just the glue that combines the different parts of the library into a coherent and hopefully "simple" application.
Regarding your feedback, I'll act on making the wiki more visible and maybe make time to add some clarification why we need the separate jsonld package all together (which I thought it's implied because the ActivityPub specification states it in its first paragraphs). I guess I can clarify in the docs who the projects target: a go developer that wants to work in the fediverse space, has read a little from the specification but decided that code would be more understandable - which is I guess the point where I was at when I started them. :D