mike on Nostr: Implement ActivityPub and http-signatures (draft-cavage earlier than the final hs2019 ...

Implement ActivityPub and http-signatures (draft-cavage earlier than the final hs2019 draft, like maybe draft 10 or 11). Then you should be able to federate with generic ActivityPub services. Note: Mastodon is not considered to be a generic ActivityPub service. I'll cover those requirements a bit further down.

If http-signatures fail, some projects decide for you which headers need to be signed but there is no way to discover their signing requirements currently. Just sign everything you can. date, (request-target), host, and digest are the ones that some projects insist on. When in doubt, fetch an actor record or something and see what headers they sign for their own content and that should give you an idea what you'll need to include in yours.

Use rsa-pem public keys - I forget which PKCS# that was. 8? Elliptic curves and other more modern public key technologies don't federate well at the moment.

Then you just need to implement a few pages of Mastodon quirks and webfinger if you want to federate with that project.  This involves things like re-factoring your HTML so it looks decent when downgrading to plaintext, stripping out photos from HTML and adding them back in as attachments, making sure your comments mention the inReplyTo author so that Mastodon folks will get notifications, and making sure your mentions use the webfinger and not the displayName when conversing with that project. Or translate to/from your preferred mention display format like we do. Don't use 'Article'. Eugen poisoned it in an earlier attempt to exterminate HTML. And if you normally provide a 'summary' - you can't, as that's a CW in Mastodon. Mastodon mentions also include the initial '@' character in the link text. Some projects put it outside the link text. Best option: accept either/both because we'll never agree on it.

I think that's the important stuff.

Two things that trip up 90% of newcomers:

    Most ActivityStreams things can be a url, an object, or an array of objects. Just recognise all of them from the start so we don't have to file bugs. If your software can't use arrays internally, use the first entry and ignore the rest. Not ideal, but you will see posts with multiple actors and actor records with multiple urls and you don't want these breaking your server.
    
    Read the part in the ActivityPub spec about the Accept header. Then read it again. Don't send me an accept header of 'application/json' and expect me to send you an ActivityPub document. Maybe I will, maybe I won't.

And if you have any desire to federate with Facebook-like projects or those with a focus on privacy/permissions, send replies to the address or addresses in the replyTo field and to nobody else. If there's no replyTo, you can send it to whoever you want. Most of the time things will work just fine if you ignore this, and it isn't standard, but if you really want to federate with most of the fediverse -  you'll do it.