4 ms·

The author makes the basic mistake of most of the people implementing ActivityPub services: they want to map the logic of an existing type of web application an

The author makes the basic mistake of most of the people implementing ActivityPub services: they want to map the logic of an existing type of web application and contort existing domain objects into encoding/decoding to an "impractically large number" of options. That happens because they want two things in one: a server and a client. The ActivityPub specification needs to be read with a goal similar to an email server in mind. It should do one thing: receive JSON-LD objects in inbox, process them according to the specification, and(maybe) store them on disk. The idea of "users", "friends", "posts", "feeds" etc, are concepts that belong to the clients on top of this server, not in the server itself. This separation between clients and server will also allow better interop/graceful degradation of object types that the client/server don't specifically understand.

cratermoon 4y ago
OK, but for someone who wants to build a useful tool that does what the author wants, "interacting with the Fediverse", such as federating with Mastodon, how useful is doing that one thing?
- jeroenhd 4y ago
  It depends on your goal. If your server is just a tool you use, you can ignore lot of concepts. There is no local timeline, there are no users, all follows belong to a single user, etc. I can't find the link but a while back there was a post on the front page about how to get a findable, read only ActivityPub profile by just uploading some static JSON files. Not exactly a Twitter competitor, but you don't need much to start exchanging messages.
  - mdasen 4y ago
    I believe you're looking for this: https://blog.joinmastodon.org/2018/06/how-to-implement-a-basic-activitypub-server/ https://blog.joinmastodon.org/2018/06/how-to-implement-a-bas...
    - cratermoon 4y ago
      I did that myself. It's quite a distance from passively accepting requests to interacting with the Fediverse.
- mariusor 4y ago
  If you want to create one just for yourself, sure. If you want to create something for the rest of the world, probably not very much. I get the "scratch your own itch" mentality, but not if you kneecap all efforts that try to build on top of it. :D
- vidarh 4y ago
  I think this is the wrong way of looking at it. If you're doing the whole stack, sure you will end up implementing quite a few things. But consider that you can write a generic ActivityStreams server without supporting any of the ActivityPub activities. Now you have a generic platform to build on. Tack on a tiny bit of support for e.g. addressing etc. as found in ActivityPub and you have what you need for federation. With that generic platform, doing what you're suggesting is a matter of implementing a handful of Activities that mutates Objects and Collections. What the author did is the equivalent of implementing a mailing-list manager by first writing a mail server from scratch instead of just writing the bits managing the list and sends, because he didn't have that lower level layer to build on. There is indeed a lot of missing tooling to work with ActivityStreams/ActivityPub, that makes it painful now, and unfortunately a lot of ActivityPub implementers takes the same tack as the author and builds one big monolith instead of first building that lower layer.
iudqnolq 4y ago
(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.
JustSomeNobody 4y ago
Do you know of a small sample project that does this as an example?
- mariusor 4y ago
  There are no "small sample" projects as far as I know. But if you look in my profile (or other comments in this thread) I did develop a server which only does ActivityPub, client to server and server to server.
still_grokking 4y ago
This comment raised a whole bunch of red flags for me. Fist and foremost: Saying that something is like an email server translates for me into "this is an under- and over-specified swamp at the same time, full of quirks, and actually not implementable in any reasonable way". Because that's what email is. I almost can't think of a greater horror than writing an email server from scratch… I don't know enough about ActivityPub to judge whether it's really like email. I would strongly hope it isn't, as otherwise it would be a tech you should probably better never touch as a developer. The next thing is: If an ActivityPub server only receives and sends some opaque BLOBs what's the whole point of it? But when it's not about opaque BLOBs you need to map the structures in the spec to proper types in a statically typed languages as you can't manipulate them otherwise in any meaningful way. If it's not possible to do that because the spec is vague and/or there is no coherent data model behind it that would be just another reason to not touch this tech. Nobody needs the next underspecified, stringly-typed "email". I really hope I'm reading this wrong!
- mariusor 4y ago
  The email comparison helps people to understand the directional way ActivityPub works, I don't know enough about email (whichever of SMTP or IMAP/POP3/samd you consider that to be) to make a comparison at protocol level. > If [...]receives and sends some opaque BLOBs what's the whole point of it? There are some rules about how to have side effects for said blobs. Some of the blobs themselves have side effects. That's mostly what ActivityPub is: rules about how to distribute the blobs in the federated context, rules to what to do with the blobs when they reach your servers (when coming from other servers, or directly from clients). The vocabulary that ActivityPub is based upon, is another whole specification, called ActivityStreams, and which didn't originate in the W3C group. This vocabulary has three (*main) types of objects: Activities - which provide the backbone of ActivityPub (Like, Follow, Create, Update), Actors - basically different types of users (these are the entities that operate the activities) and, Objects - whatever the Activities operate on.
- WorldMaker 4y ago
  > If an ActivityPub server only receives and sends some opaque BLOBs what's the whole point of it? There's still a difference between "try to black-box the incoming data as much as possible" and "treat the incoming data as opaque BLOBs and assume". The data is mostly JSON-LD which is a far cry from "binary large objects". It is always going to be "semi-transparent" as it will always be JSON. Whether or not you like the "-LD" extensions to JSON (they are heavy, they do have a lot of RDF baggage you may not desire), they give you a bunch of guaranteed "baseline schema" for the JSON objects that you can use for static typing that might be "good enough" for a lot of "meaningful manipulations" (such as following links to pick up related objects; LD => linking data) and that is all easily transparent. A lot of the schemas beyond "LD" in ActivityPub are client/application-specific beyond most of the JSON-LD basics and should be easy to treat as a black box unless doing client/application-specific tasks. That's not necessarily "stringly typed", it's kind of a classic "serialization onion": The server at best needs to know that it is JSON and it may have JSON-LD metadata for relevant related linked objects (and a few other metadata fields common to "introspection", similar to "headers"). The client can dig deeper and know it is not just "any" JSON object but a more specific schema for a given class of thing the client cares about.
MuffinFlavored 4y ago
> JSON-LD https://json-ld.org/ https://json-ld.org/ for anybody else not super familiar

cratermoon 4y ago

OK, but for someone who wants to build a useful tool that does what the author wants, "interacting with the Fediverse", such as federating with Mastodon, how useful is doing that one thing?

jeroenhd 4y ago
It depends on your goal. If your server is just a tool you use, you can ignore lot of concepts. There is no local timeline, there are no users, all follows belong to a single user, etc. I can't find the link but a while back there was a post on the front page about how to get a findable, read only ActivityPub profile by just uploading some static JSON files. Not exactly a Twitter competitor, but you don't need much to start exchanging messages.
- mdasen 4y ago
  I believe you're looking for this: https://blog.joinmastodon.org/2018/06/how-to-implement-a-basic-activitypub-server/ https://blog.joinmastodon.org/2018/06/how-to-implement-a-bas...
  - cratermoon 4y ago
    I did that myself. It's quite a distance from passively accepting requests to interacting with the Fediverse.
mariusor 4y ago
If you want to create one just for yourself, sure. If you want to create something for the rest of the world, probably not very much. I get the "scratch your own itch" mentality, but not if you kneecap all efforts that try to build on top of it. :D
vidarh 4y ago
I think this is the wrong way of looking at it. If you're doing the whole stack, sure you will end up implementing quite a few things. But consider that you can write a generic ActivityStreams server without supporting any of the ActivityPub activities. Now you have a generic platform to build on. Tack on a tiny bit of support for e.g. addressing etc. as found in ActivityPub and you have what you need for federation. With that generic platform, doing what you're suggesting is a matter of implementing a handful of Activities that mutates Objects and Collections. What the author did is the equivalent of implementing a mailing-list manager by first writing a mail server from scratch instead of just writing the bits managing the list and sends, because he didn't have that lower level layer to build on. There is indeed a lot of missing tooling to work with ActivityStreams/ActivityPub, that makes it painful now, and unfortunately a lot of ActivityPub implementers takes the same tack as the author and builds one big monolith instead of first building that lower layer.

iudqnolq 4y ago

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

JustSomeNobody 4y ago

Do you know of a small sample project that does this as an example?

mariusor 4y ago
There are no "small sample" projects as far as I know. But if you look in my profile (or other comments in this thread) I did develop a server which only does ActivityPub, client to server and server to server.

still_grokking 4y ago

This comment raised a whole bunch of red flags for me. Fist and foremost: Saying that something is like an email server translates for me into "this is an under- and over-specified swamp at the same time, full of quirks, and actually not implementable in any reasonable way". Because that's what email is. I almost can't think of a greater horror than writing an email server from scratch… I don't know enough about ActivityPub to judge whether it's really like email. I would strongly hope it isn't, as otherwise it would be a tech you should probably better never touch as a developer. The next thing is: If an ActivityPub server only receives and sends some opaque BLOBs what's the whole point of it? But when it's not about opaque BLOBs you need to map the structures in the spec to proper types in a statically typed languages as you can't manipulate them otherwise in any meaningful way. If it's not possible to do that because the spec is vague and/or there is no coherent data model behind it that would be just another reason to not touch this tech. Nobody needs the next underspecified, stringly-typed "email". I really hope I'm reading this wrong!

mariusor 4y ago
The email comparison helps people to understand the directional way ActivityPub works, I don't know enough about email (whichever of SMTP or IMAP/POP3/samd you consider that to be) to make a comparison at protocol level. > If [...]receives and sends some opaque BLOBs what's the whole point of it? There are some rules about how to have side effects for said blobs. Some of the blobs themselves have side effects. That's mostly what ActivityPub is: rules about how to distribute the blobs in the federated context, rules to what to do with the blobs when they reach your servers (when coming from other servers, or directly from clients). The vocabulary that ActivityPub is based upon, is another whole specification, called ActivityStreams, and which didn't originate in the W3C group. This vocabulary has three (*main) types of objects: Activities - which provide the backbone of ActivityPub (Like, Follow, Create, Update), Actors - basically different types of users (these are the entities that operate the activities) and, Objects - whatever the Activities operate on.
WorldMaker 4y ago
> If an ActivityPub server only receives and sends some opaque BLOBs what's the whole point of it? There's still a difference between "try to black-box the incoming data as much as possible" and "treat the incoming data as opaque BLOBs and assume". The data is mostly JSON-LD which is a far cry from "binary large objects". It is always going to be "semi-transparent" as it will always be JSON. Whether or not you like the "-LD" extensions to JSON (they are heavy, they do have a lot of RDF baggage you may not desire), they give you a bunch of guaranteed "baseline schema" for the JSON objects that you can use for static typing that might be "good enough" for a lot of "meaningful manipulations" (such as following links to pick up related objects; LD => linking data) and that is all easily transparent. A lot of the schemas beyond "LD" in ActivityPub are client/application-specific beyond most of the JSON-LD basics and should be easy to treat as a black box unless doing client/application-specific tasks. That's not necessarily "stringly typed", it's kind of a classic "serialization onion": The server at best needs to know that it is JSON and it may have JSON-LD metadata for relevant related linked objects (and a few other metadata fields common to "introspection", similar to "headers"). The client can dig deeper and know it is not just "any" JSON object but a more specific schema for a given class of thing the client cares about.

MuffinFlavored 4y ago

> JSON-LD https://json-ld.org/ https://json-ld.org/ for anybody else not super familiar