(My only knowledge of activitypub comes from reading this article.)
To receive JSON-LD messages don't you need to send follow requests? And to do that don't you need to deal with the fact the spec is too complicated and most servers implement inconsistent parts of it?
To receive JSON-LD messages, someone needs to send them to you. Sending follow requests is perhaps the easiest way to do that, but those follow requests do not need to be initiated by the same code that hosts the inbox.
The point is there are several potentially independent layers and modules there: The message pump itself at least can be implemented separately from the decoding of individual message types, and separate from managing followers and following, the same way e.g. a mail server knows nothing about how to follow mailing lists, or decoding email messages past the header.
It might sound like a mess if you see ActivityPub in terms of HTTP request, but ActivityPub is a protocol built on message passing, and what is a mess is trying to co-mingle the transport layer for the messages with processing those messages.
I'm not saying it doesn't have some warts and things that could do with being specified more clearly, but if you ignore a central aspect of the protocol and try to treat it as something it is not it will seem a whole lot messier than it is.
> It might sound like a mess if you see ActivityPub in terms of HTTP request, but ActivityPub is a protocol built on message passing, and what is a mess is trying to co-mingle the transport layer for the messages with processing those messages.
You are defending it strongly but the spec is indeed written like that.
It's not even obviously message-oriented when you read it and the notion of following and managing followers is definitely put at the same level that transmitting new information regarding activities.
Don't get me wrong it can definitely be implemented but it's definitely not a good protocol nor is it well specified.
To me it was blatantly obvious that it is message-oriented when I read it given the vocabulary used. It could perhaps spell it out for people not used to it, but the use of e.g. "pub", "inbox", "outbox" and the use of addressing, including even "cc" fields in the spec should be enough for anyone used to writing message pump/queue based systems to see it as a pub/sub message based system. That it also talks of "actors" further underlines this, as the actor model is generally built on message passing.
As I said, it has warts and it'd be nice if the two layers specified had been separated out more clearly so it was more accessible to less experienced readers, but if a reader that don't see the message based foundation of the spec, it does speaks as much to the readers unfamiliarity with message passing systems as the spec.
The spec first definition paragraph is about "Objects". There is mention of object retrieval long before message passing. The concept of messages is introduced in relation to Actors inbox and outbox. It’s not written clearly as being a message passing system and I am not sure it was conceptualised this way. Only from the server to server part you can start infering that’s what it’s supposed to be.
Well, then I guess it's not clear enough for you. For me it is clear as day. The Actor model is inherently focused on concurrently processing messages acting on objects, and the very section you refer to when it talks of objects shows an example mentioning actors and it's followed by a section on Actors.
The inbox/outbox terminology is further inherently tied to async message passing with a message pump/queue, and so on.
You may not be sure it was conceptualised this way, but it really is irrelevant whether or not it was conceptualised this way because the spec-as-written describes an architecture that to someone with experience in the field is most reasonably interpreted that way as it is inherent to the vocabulary used, and where interpreting it that way creates a significantly more cohesive architecture. You're free to interpret it otherwise, but it's now been pointed out to you that treating it this way simplifies the understanding of it - if you choose to ignore that advice, then so be it.
I might be sympathetic to the argument that it is may not be spelled out sufficiently clearly to someone without experience in this area or unfamiliar with the actor model, but there's a question of to what extent a w3c working group should feel a need to assume readers are not familiar with these kinds of models..
Strangely I think we are fondamentaly in agreement. I think the spec is poorly written for the reasons you quote. I am not surprised to see people struggling with the implementation. It's not a good spec.
So we have just the next question: If it's message passing, why was it build on top of HTTP? Wouldn't a RPC-like protocol as base be much more adequate?
This would just strengthen the suspicion that this protocol is badly designed, to be honest.
Because HTTP is ubiquitous and passes through every firewall around, and has extensive tooling. You need a really good reason to pick a different choice if you're going to expose your endpoints to the public internet today.
To receive JSON-LD messages don't you need to send follow requests? And to do that don't you need to deal with the fact the spec is too complicated and most servers implement inconsistent parts of it?