# ActivityPub support for Yarn.social / Twtxt ## Notes - ActivityPub is hard™ - Some instances like GTS (GotoSocial) instances **require** HTTP Signatures on every request, other instances like [mastodon.social](https://mastodon.social) don't. - The `keyID` in a HTTP Signature is _actually_ a URI reference to an A2S Actor object that servers will fetch to verify the HTTP Sig matches the key found there - > [05:04:49] <+[snarfed]> ah, your keyId points to a plain text key. I think AP implementations generally expect to fetch an AS2 actor at that URL, and then extract publicKey.publicKeyPem (and check that publicKey.id matches) - The Public Key has to be marshaled as PKCS1 and encoded as a PEM block. - It is **important** that every request to an ActiviyPub endpoint and an Actor's inbox **must** have a `Content-Type` of `application/activity+json` or some servers like GTS (_GotoSocial_) will flat-out reject the requests. - An `Icno: "..."` doesn't work for setting a Person's (Avtor) Avatar, you have to construct a full `Icon` object like: ```json "icon:" { "type": "Image", "mediaType: "image/png", "url": "...", } ``` - At least GTS ([]GotoSocial](https://gotosocial.org/)) instances seem to cache lookups, so if you're developing an ActivityPub server or integration and get things wrong, it makes it hard to test as GTS seems to have no controls around deleting the cache :/ - Actor inboxes are _apparently_ expected to be unique on the server. At least GTS expect this and enforces this as the database model. - Some servers like (GTS) incorrectly assume `.Followers` and .`Following` are required, but they are strictly not. Yarn.social / Twtxt does not expose publicly "Following" lists for example.