How does one read a protocol specification and write an implementation from scratch?
I'd love to see a Ruby #ActivityPub gem, but I have a very limited understanding of how to build one myself.
Yeah, that's not a bad thought. I've definitely studied the rstatus implementation of OStatus before, and it gave me some good ideas of how an OStatus system goes together.
I guess part of this depends on just knowing where to start?
Like, creating a gem, mounting it in a Rails app, and then getting that app to leverage the gem for federation calls doesn't seem like a crazy hard amount of work.
The real question involves which parts to build out first. I guess the inbox / outbox? Predefined ActivityStreams objects? Creating a status and rendering it in a stream?
The other tricky bit involves adapting it to an existing system, like, uh, Diaspora.
@deadsuperhero hmm, step one is making a plan and working out the rough flow on 'paper' :)
@webmind Yeah, I think this makes the most sense. If I can untangle the abstractions and understand how the objects are supposed to connect to each other, I guess that's a step in the right direction. :)
It seems like the bulk of communication happens through a user's inbox/outbox? If so, that's probably a big clue about how things should be put together.
First: Implementing AS export/import
Second: The whole contact negotiation to establish a connection
Third: The inbox (because at this point you can start sending posts from other networks)
Forth: The outbox
@deadsuperhero not easy to explain I'm afraid. Reading a specification can depend on how it's written. But the specification is there to help you. See the difference between message A and message B. It's language if you like. Writing a parser is a lot about filtering out the information in a stream. Picking out the values you are after and classifying them. Once you have that, you can connect actions to those. Thats the theory, but do read some existing implementations for help :)
Good luck!
@cwebber What part of the protocol did you start with when you built out pubstrate? Trying to wrap my head around a sane starting point.
@deadsuperhero in addition to the very good suggestions provided here, there's also a test suite which may be of some help? https://test.activitypub.rocks
I know one of the authors is on mastodon and I'd find out his name if there was better searching on mastodon... :(
@deadsuperhero My plan with #hanatachi is to reach a minimal implementation, I mean, just:
* To follow other users
* To publish content
* To make the delivery
Once I get all them working on a Rails app, mi plan is to try to get all the #activitypub related code and put it into a gem.
Now I'm on working on the follow first item https://github.com/ortegacmanuel/hanatachi It already fetches remote users, now I'm working on the follow request to that user just fetched.
I also added webfinger because I like it 😀
@ortegacmanuel Sounds like there may be a duplication of effort from my side. I've been studying your project and a few others as I try to build a gem first, and then attempt to mount it in an app afterwards. 😛
@deadsuperhero Ok! yes! maybe it is not a good idea in your case 😋
One question, have you think about the persistence layer, should an #activitypub gem take care about persistence layer?
And asking to your question about what to implement first..I would answer that the first functionality to implement should be the actor id endpoint
get /activitypub/:username should return an actor ActivityStreams object
@ortegacmanuel Good tip on the actor id endpoint.
As far as persistence layer is concerned, I'm honestly not sure. What's the benefit of providing that in a gem directly, as opposed to handling that in the application using the gem?
@deadsuperhero I've thought a lot about it and now I'm in favour of handling all the persistence logic in the application, the benefit is that the application know better how the persistence is structured and this is difficult to handle from the gem because the this is unpredictable..every application could structure the persistence differently
Maybe in the gem, we could just handle the persistence of the activity model..just thinking!!
@deadsuperhero The logic could be as this: I, the gem, add a endpoint inbox for the actors, get the activity json from other nodes, make some validations and pass an activity instance to the application, them, the application persistes the activity
@ortegacmanuel @deadsuperhero I’m working on this exact case in Python/Flask and decided that the application should return AP objects.
