42
not much beyond "look at what other apps you're trying to interoperate with output and try to reverse engineer your way through". reading through the sources of other apps may be a good idea.
some links that may get you started, picked from https://socialhub.activitypub.rocks/t/guide-for-new-activitypub-implementers/479 :
- https://flak.tedunangst.com/post/ActivityPub-as-it-has-been-understood
- https://www.w3.org/community/reports/socialcg/CG-FINAL-apwf-20240608/
- https://swicg.github.io/activitypub-http-signature/
- https://seb.jambor.dev/posts/understanding-activitypub/
- https://tinysubversions.com/notes/reading-activitypub/
and depending on which ecosystem you're targeting:
- https://docs.joinmastodon.org/spec/activitypub/
- https://join-lemmy.org/docs/contributors/05-federation.html
counter intuitively, avoid reading the specs if you're looking to federate with existing software. the official specs are... extremely lacking beyond giving you the bullets to shoot yourself in the foot with (half of what little it defines goes unused in the real world, important things like "how do i know this activity is sent by the person it claims to be" is completely undefined (hint: everyone has more or less settled on http signatures).
once you get something federating, you can then look in the specs in an attempt to learn the concepts in depth, but writing code following the specs will result in code that simply won't federate.