Document issues w/ ActivityPub.

[NfNitLoop]

One of the first people I shared FeoBlog with asked "Does it support ActivityPub?" and I had to say no.

I should create a FAQ or somewhere to document these kinds of things, and this question in particular.

The Short Version

Until then, here's why FeoBlog doesn't support ActivityPub:

1. ActivityPub is federated, not distributed. Your userID is tied to a particular server (DNS hostname). That does not work with the data structures and security measures that FeoBlog was built upon.
2. The ActivityPub standard doesn't have a way to verify the contents of a posts, so accepting ActivityPub data would mean that FeoBlog clients wouldn't be able to verify all of their data.
3. ActivityPub relies on the concept of posting messages to users' "inboxes". But in FeoBlog, a user may exist on multiple servers, so there may be no known (and online) "inbox" for ActivityPub to post to.

See https://www.w3.org/TR/activitypub/#security-considerations for some of the unanswered security concerns.

In particular, I don't see there how servers or clients can validate that data they received is actually from the supposedly originating user.

Meanwhile, FeoBlog only accepts signed data. As a result, its data model doesn't need an "inbox". Being passed data for a user operates the same whether it's from that user, or from some other service on their behalf.

[NfNitLoop]

As a compromise, we could in theory implement an ActivityPub view of the data.

• Would popular ActivityPub clients be able to fetch that data for themselves, or would they have to receive push events?
• Even if they could, they probably wouldn't update unless they received push events? And that's not necessarily a thing I want to implement in the server yet.

[NfNitLoop]

Now, while I'm unlikely to build ActivityPub publishing into the core of FeoBlog, it should be possible to write an ActivityPub bridge. On one side, it serves/accepts ActivityPub events, and on the other it talks to FeoBlog.

1. Exposing content from FeoBlog wouldn't be a big deal. It would periodically poll the FB backend, find new Items, and emit AP events to interested servers.

2. Accepting content from AP would be more complicated -- you'd need to decide which servers you trust. And then "sign" content from them and insert that into FB. There are example twitter/mastodon/RSS clients that do this linked from the main README if you want to give it a go. 😊

[NfNitLoop]

Was looking at ActivityPub specs and Mastodon docs today just out of curiosity. I kept running into things that just seemed to be unanswered by the spec, and seem to just be Mastodon convention. Going down some google holes and I came across this 🔥 thread from the developers of Diaspora: https://github.com/diaspora/diaspora/issues/7422

The basic gist of that thread is that the "spec" leaves too much unspecified, making it difficult/impossible to build an interoperable system. One example -- there seems to be no specification for how to know/verify that something posted to an ActivityPub inbox actually originated from the user it claims to be from. (And the one that Mastodon implements lets any server impersonate any of the users on that server.)

Another missing bit -- if we have user@host, how do we look up their Actor record on a server? ActivityPub has no standard URL schema. Mastodon doesn't require one either. Instead, Mastodon requires that you also implement WebFinger to look that up. So implementing ActivityPub alone wouldn't be enough to interoperate with Mastodon.