I’ve been wanting to write my thoughts on these topics more publicly, but for now I’ll take a quick pass over the post at: https://schub.io/blog/2018/02/01/activitypub-one-protocol-to-rule-them-all.html
I apologize for the length but this has been on my mind for a long time and is similar to what I would say if anyone prompted me on these topics.
With the amount of different actors, activities, objects, and the high amount of customizability defined within ActivityStreams, it should be possible to represent any kind of interaction possible. However, in my opinion, this creates more issues than it is trying to solve: the high number of possibilities makes it very hard to write server implementations and user interfaces able to handle this.
This criticism is legitimate, but it is also the benefit of allowing a very low barrier to entry to adding different “flavors” of Fediverses (microblogging, economic, education, code forges) and then letting anyone come in to build a vanilla app (ex: microblogging) or something powerfully creative (economic coop management around a coding forge). If I tried to build the latter on Diaspora*, it would be impossible. It’s built with only the social use case interactions in mind (from my limited understanding of the protocol).
So it is a tradeoff, and a powerful one in my opinion.
The other area I think that could use improvement is identity management across instances (which are different apps), but I won’t elaborate further.
[On discussing flexible clients] In reality, however, I expect a lot of ActivityPub implementations to use some kind of customized payloads, so clients might not be interchangeable at all.
I think this is a manifestation of a possible root criticism that Dennis has: there is the expectation that all ActivityPub clients should be able to always have the capability to see all data on the Fediverse.
This constraint should be explicitly be lifted when thinking of ActivityPub. There will be MoodleNet data on ActivityPub. How will microblogs like Mastodon and Pleroma show it? They may just quite simply ignore it! That’s fine, other clients will be developed that can handle it, and maybe those will want to ignore the microblogging part of the Fediverse. There is no problem here, unless you go in with the mindset of “all clients must be a Swiss army knife and do everything”. It’s fine if some clients want to tackle this problem, but the ecosystem is richer if apps can specialize and each have their “view” of the “flavors?” (now my metaphor stinks).
I am of the opinion that seeing the good in ActivityPub requires breaking a lot of traditional philosophies around what an API is, not getting married to the idea of REST, and rethinking a lot of paradigms that don’t necessarily map to the HTML (er, now JS+HTML) web. As this is a web of linked structured data, not just linked hypertext documents with scripting side effects.
Based on ActivityPub, you can build applications that share concepts with Facebook, as well as applications more like Twitter. One could assume that all compatible clients work just fine with all ActivityPub implementers, allowing the user to choose their preferred style of network. However, I think ActivityPub offers too many ambiguous ways to implement certain aspects, so I doubt this would work.
It’s too early to tell if it would work. I’m an optimist, he is a pessimist.
It is a fair point that ActivityPub does not solve the problem of discoverability. However, this entire section laments using an IRI for an actor, instead of something like an email address. That’s fine, but in practice users of Mastodon and Pleroma have had no problem using webfinger to tackle the discoverability issue. It’s safe to say ActivityPub alone is insufficient to solving the discoverability problem, but it’s slightly mitigated.
There is no such thing as a profile , really. But there is something called “actor”.
This is a manifestation of an other major philosophical difference I think Dennis is limiting himself to. Diaspora* (from what I can tell) is only social-interaction-as-messages-focused. So naturally the way to think about a protocol is only through that lens. My criticism of Diaspora* is that it shoves too much “application” into a transport protocol, and I think concepts and terminology like profile shows.
When shifting the mindset to be neutral as to whether a social interaction has an informational, educational, economic, or other nature then you don’t want to be tied to the philosophical concepts within those domains. ActivityPub actors aren’t called “balance sheets” (from an economic perspective) because while they could be called that… why limit itself? Similarly for “profile” and the communication perspective.
Ultimately, you will end up with a lot of different custom fields for different use cases, and everyone is kind of cooking their own soup anyway. But because exchanging objects still works just fine, some missing fields can cause a lot of confusion. [Gives Diaspora example]
I agree about the potential for confusion. I don’t believe custom fields are playing out the way he outlines in a very-doomsday-extreme example. As thus far Fediverse devs have been pretty good at judiciously using custom fields without breaking their compatibility, and insulating their app against unknown fields from having any effects. The latter is almost tautological, though.
I am not impressed by the Diaspora example I omitted because it is extremely negative to such a degree that it does not match my understanding of how AP works.
Users follow each other. Here, this has several implications. When Bob is following Alice, Alice will send all public activities (or all activities sent to all followers) to Bob, but Bob has no obligation to return something. While this model works fine for applications like Twitter, I do not think it is a good generic solution.
With no evidence of why this isn’t a good generic solution, I can’t address this criticism. He is careful to omit the fact that Alice is under no obligation to Reject Bob’s Follow request, denying him membership to her followers collection. So that point is moot. Furthermore, I’m not sure why Dennis thinks Bob has an obligation to return something. So I can’t address that either.
In my opinion, the “specifying to whom I push content to” model is more fitting than the “specifying who should push me content” model, at least for distributed social networking. In any case, adopting ActivityPub in diaspora* would cause a complete rework of that logic, as well as potentially confusing all users.
I think Dennis missed the fact that Follows can be Accepted and Rejected in ActivityPub, which allows curating the followers list and not letting every random person join the follwers collection. I think the root criticism is really that Dennis wants a ReverseFollow, where Person A asks Person B if B wants to be in A’s followers. That doesn’t seem too complex of an extension to work towards.
I am not sure if a server can hold more collections. [Criticism assuming “no”]
But the answer is “yes”, especially if it’s all internal to your own application like organizing lists (“aspects”).
Talking about missing things I am surprised about: there is no support for private communication.
I’m not surprised this came up. It’s not explicitly in the AP spec, but it is very well hidden. The spec allows for filtering a user’s outbox based on the authorization of the requestor. So sending a message marked “private” internal to the application shouldn’t show up for anyone fetching the outbox except the owning actor. The “to” field can just be a single other actor. And that actor’s inbox should only be fetchable by that actor (the spec is a little more lenient here). There is no mass-distribution nor unwanted-publicizing of every Activity sent. The ActivityPub spec is very gracious in allowing applications to determine what data to filter out for unauthenticated fetches.
If all networks were to agree on simply using
Note for post-like activities, contents would still not be exchangeable without problems.
This is a legitimate criticism, and one I don’t have a good answer for.
ActivityStreams extensibility is another cause of concern. While it is nice to have a protocol that you can use for everything, having a specification that allows to send what basically is arbitrary JSON, is a huge danger for the compatibility between implementations.
It should be no surprise I disagree. In practice, spammers can effectively spew arbitrary JSON and get their instances blacklisted so all messages are rejected for broken federation. What is more insidious of a criticism is: “what if two major apps that view the same JSON very differently?” This forces folks that want widespread adoption of their extension (“flavor”) to develop it as if it were a separate standard put together by their community, and be a good citizen with the other existing extensions out there.
The answer is probably a good community system where these different ActivityStreams extensions come together and make sure they don’t interpret properties from the same namespace in very different ways. Again, so far this is untested, I am an optimist, he is a pessimist.
That is, however, not the case with ActivityPub. In the example (and, in fact, everywhere else), it is clear that Bob has to address individual recipients in his interaction. We have seen this implementation before and it is built to fail . Just imagine this very simple case: Alice posts an activity to Bob, but has Charlie on
bcc . Bob posts a response. Bob sends his response back to Alice.
to field of that response does not include a collection owned by Alice’s host, the ActivityPub specification clearly says Alice’s server must not forward this interaction. Because of that, Charlie will never receive Bob’s response. However, when Alice then responds to Bob’s comment, Charlie will get Alice’s response, since Alice’s server knows that Charlie is on
I have a problem with this specific example. For two reasons:
- Only if the application implementing ActivityPub had a “sicky bcc” feature where the bcc lasted an entire thread’s worth of conversation would this actually occur. I think most applications would correctly draft the inReplyTo without looking 2 messages back to copy-paste a “bcc” field.
- This is not the first example in this post that is fundamentally an example of an application that follows the letter of the law with ActivityPub but has foot-gun behaviors. It shows me that he, and maybe Disapora* as a whole, expects a transport protocol that also severely restricts the capabilities and responsibilities of the implementing application , but I don’t know why and don’t want to speculate.
The way of sending interactions outlined by ActivityPub does not solve the ghost reply issue.
This is a very assertive statement that I think Mastodon and Pleroma users would disagree with.
Authentication, Authorization, Verification, Encryption
I share his criticisms in this section.
TL;DR: My views on the shortcomings of the protocol are that shortcomings exist and working within the community is the way forward. Whether that means an actual independent and open Federation of devs needs to be made to help govern the personalities writing the apps, IDK.