2 ms·

> The Fediverse is always described with that interconnected diagram where everything talks to each other over ActivityPub. But I never see that in practice. N

> The Fediverse is always described with that interconnected diagram where everything talks to each other over ActivityPub. But I never see that in practice. Not sure what you mean by this—it definitely comes up a lot in practice. The top story on HN right now is an example of this in practice—it's a post from social.hackerspace.pl, which has been shared to all of the users followers on different servers. You can take a quick look at the list of reblogs on that post to see how many different servers users use: https://social.hackerspace.pl/@q3k/111528162462505087/reblogs https://social.hackerspace.pl/@q3k/111528162462505087/reblog... I count 17 different servers in the first 20 users listed. Many of these are deployments of Mastodon or Akkoma, but they're all completely separate servers talking to each other over ActivityPub > For example: If I have a mastodon.social account, how does that work with pixelfed.social or tube.jenna.net? You can use your account and client on mastodon.social to follow accounts on tube.jenna.net and pixelfed.social. These accounts are displayed inside of the mastodon.social UI. You don't "sign up" for those instances in any way, they're just an integrated part of your following feed. > How do the clients handle the fact that they are different services? There is no special logic needed from clients. For Mastodon specifically, the local server that you're following from will handle the logic of translating the ActivityPub JSON sent by other services into the more limited "Mastodon API" format that clients expect. This has pros and cons—it means that clients are able to handle a more limited and predictable set of posts, but it also means that some remote content gets "squished" down into that format, just like e.g. viewing a blog inside of an RSS reader. Other clients generally use their own similar domain-specific API format

dingnuts 3y ago
one correction: the Mastodon API is actually more expansive than ActivityPub, not more limited. Pleroma and Misskey implement additional protocols on top of ActivityPub, like WebFinger, in order to be able to federate with Mastodon properly >it also means that some remote content gets "squished" down into that format this is true but it's usually content going the other way: FROM a Mastodon instance TO something like WriteFreely that isn't a Twitter clone
- nightpool 3y ago
  By "the Mastodon API" I'm referring to the REST API used by Mastodon clients, not the activitypub "plus" API used by other servers to federate with them. > FROM a Mastodon instance TO something like WriteFreely that isn't a Twitter clone I understand that it may appear like that from a user perspective, but from a protocol perspective the ActivityPub representation is strictly more generic and extensible. Both directions (from mastodon and too mastodon) are very, very lossy. All mainstream servers (except maybe pleroma derivatives) do this kind of "squishing", which is a sad reality of client design and not what the ActivityPub spec was intended for
  - dingnuts 3y ago
    >All mainstream servers ... do this kind of "squishing", which is a sad reality of client design and not what the ActivityPub spec was intended for I understand what you mean by "the Mastodon API" but I think we're talking past each other; this does not seem like a client design problem but a protocol problem. I would like to contend that the ActivityPub spec is too vague and thus clients are forced to do this "squishing" in order to find a portion of the spec that is sufficiently well-defined as to actually be practical for a specific use-case like a federating Twitter clone. As far as I can tell, there's an echo of this lack of definition in the ActivityPub (and actually more specifically, in the ActivityStreams) specification if you do a tour of the ecosystem of implementations, you'll find that almost all of them are in dynamically typed high-level languages like Ruby (Mastodon). Implementations in languages like Go where JSON deserialization must be defined per-type have a very hard time with ActivityStreams and you'll find that Go implementations of ActivityPub like go-fed are much more narrowly scoped in their functionality in order to avoid this problem. I have wasted many, many hours on ActivityPub, and I am extremely sad to make this comment, because I understand why it was invented.. but I'm not sure it's really good enough to achieve its goals.
    - nightpool 3y ago
      The fact that some Go libraries use struct-based deserialization for processing ActivityPub is frankly an implementation issue. Your language choice should not make a difference in how easy you find it to implement something. go-fed could have been implemented 10x more easily using maps, without having to resort to reams of code generation to implement things that dynamic languages implement "trivially". My feeling is that nobody has given a serious AP C2S client implementation (where the narrowing / "squishing" happens on the client side, as defined by the spec, and the server-side is agnostic) a serious effort. It increases client complexity, yes, and there needs to be extensions to the AP spec to make it work, but I think there are a lot of benefits to it that haven't yet been fully explored. I don't think the future of ActivityPub is locked-down implementations like Go that have super strict type safety rules. That's just at odds with what real decentralized protocols have proven to work (HTML, HTTP, SMTP, MIME—all have "open ended" extension mechanisms). I think a pluggable client infrastructure that allows multiple different "types" of clients to share the same agnostic backend server is a much stronger path forward for future development.

dingnuts 3y ago

one correction: the Mastodon API is actually more expansive than ActivityPub, not more limited. Pleroma and Misskey implement additional protocols on top of ActivityPub, like WebFinger, in order to be able to federate with Mastodon properly >it also means that some remote content gets "squished" down into that format this is true but it's usually content going the other way: FROM a Mastodon instance TO something like WriteFreely that isn't a Twitter clone

nightpool 3y ago
By "the Mastodon API" I'm referring to the REST API used by Mastodon clients, not the activitypub "plus" API used by other servers to federate with them. > FROM a Mastodon instance TO something like WriteFreely that isn't a Twitter clone I understand that it may appear like that from a user perspective, but from a protocol perspective the ActivityPub representation is strictly more generic and extensible. Both directions (from mastodon and too mastodon) are very, very lossy. All mainstream servers (except maybe pleroma derivatives) do this kind of "squishing", which is a sad reality of client design and not what the ActivityPub spec was intended for
- dingnuts 3y ago
  >All mainstream servers ... do this kind of "squishing", which is a sad reality of client design and not what the ActivityPub spec was intended for I understand what you mean by "the Mastodon API" but I think we're talking past each other; this does not seem like a client design problem but a protocol problem. I would like to contend that the ActivityPub spec is too vague and thus clients are forced to do this "squishing" in order to find a portion of the spec that is sufficiently well-defined as to actually be practical for a specific use-case like a federating Twitter clone. As far as I can tell, there's an echo of this lack of definition in the ActivityPub (and actually more specifically, in the ActivityStreams) specification if you do a tour of the ecosystem of implementations, you'll find that almost all of them are in dynamically typed high-level languages like Ruby (Mastodon). Implementations in languages like Go where JSON deserialization must be defined per-type have a very hard time with ActivityStreams and you'll find that Go implementations of ActivityPub like go-fed are much more narrowly scoped in their functionality in order to avoid this problem. I have wasted many, many hours on ActivityPub, and I am extremely sad to make this comment, because I understand why it was invented.. but I'm not sure it's really good enough to achieve its goals.
  - nightpool 3y ago
    The fact that some Go libraries use struct-based deserialization for processing ActivityPub is frankly an implementation issue. Your language choice should not make a difference in how easy you find it to implement something. go-fed could have been implemented 10x more easily using maps, without having to resort to reams of code generation to implement things that dynamic languages implement "trivially". My feeling is that nobody has given a serious AP C2S client implementation (where the narrowing / "squishing" happens on the client side, as defined by the spec, and the server-side is agnostic) a serious effort. It increases client complexity, yes, and there needs to be extensions to the AP spec to make it work, but I think there are a lot of benefits to it that haven't yet been fully explored. I don't think the future of ActivityPub is locked-down implementations like Go that have super strict type safety rules. That's just at odds with what real decentralized protocols have proven to work (HTML, HTTP, SMTP, MIME—all have "open ended" extension mechanisms). I think a pluggable client infrastructure that allows multiple different "types" of clients to share the same agnostic backend server is a much stronger path forward for future development.