4 ms·

(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 yo

(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?

vidarh 4y ago
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.
- still_grokking 4y ago
  That sounds like a mess. Reading through the other comments here it seems that the spec is in fact a mess…
  - deleted 4y ago
    [deleted]
  - tedunangst 4y ago
    Many people find whining about messes is more fun than doing anything useful.
  - vidarh 4y ago
    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.
    - WastingMyTime89 4y ago
      > 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.
      - vidarh 4y ago
        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.
        WastingMyTime89 4y ago
        Deeply disagree. 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.
        vidarh 4y ago

vidarh 4y ago

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.

still_grokking 4y ago
That sounds like a mess. Reading through the other comments here it seems that the spec is in fact a mess…
- deleted 4y ago
  [deleted]
- tedunangst 4y ago
  Many people find whining about messes is more fun than doing anything useful.
- vidarh 4y ago
  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.
  - WastingMyTime89 4y ago
    > 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.
    - vidarh 4y ago
      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.
      - WastingMyTime89 4y ago
        Deeply disagree. 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.
        vidarh 4y ago