You use your mastodon account to tell your mastodon instance to follow a user on the pixelfed.social instance. Your mastodon instance starts getting a feed of all the posts by that user from the pixelfed.social instance and displaying them to you in your mastodon timeline as if they were mastodon posts.

This works because while pixelfed and mastodon and tube.jenna.net display things differently, the things they are displaying are in fact very very similar. Posts by users, consisting of maybe a video, maybe an image, maybe a reference to a post they're replying to, and some text. Ultimately it will be up to the individual implementation what to do with posts that are different enough that they can't figure out a reasonable way to display them.

> 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/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

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

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

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

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.

There are some initiatives that are doing more what you are looking for, vocata and activitypod. These treat activitypub more like a modern email server, that recieves and sends activities to different federated servers.

In a world where those would be used, "apps" would just subscribe to the activities that interest them, and you would be one user that adds apps to your system. You'd be able to have something closer to google suite, where your calendar app can display notes from your note app, or your notes app could display shared notes, comments etc.

Today though, most of the big activitypub players decided to implement their own activitypub server and don't really follow the protocol to the letter, so unfortunately it's not as interoperable as it could be. You also need to have an account for each service, which is unfortunate.

It’s federated like email. If you have a Gmail account, you can talk to people with a Yahoo account. You can’t use your Gmail account to log into another server, though, unless that server adds code to specifically support it. They’re separate servers operated by separate entities.

You just follow those users at their @[email protected] or @[email protected] handle. Depending on the service you are using there can be caveats (I think pixelfed only tracks new content from mastodon after you follow the user) but otherwise it "just works".

caveat: This only works as long as your instance hasn't de-federated those instances.

If pixelfed and mastodon are federated with each other, you should be able to view users and posts from both sites on either site - no need to sign up for both.

You can't (yet?) log in at other websites, but you can follow anyone from any fediverse service. I follow accounts from PixelFed and PeerTube on my own self-hosted version, which feels very web native and self evident when you get used to it.

ActivityPub would not appear to be a focus for the mainline Mastodon team. My tests show that most ActivityPub endpoints of the main Mastodon server software are not CORS enabled so are unreachable by webapps. They are public endpoints and should obviously be CORS enabled. For a HTTP-based protocol, this is a glaring oversight. (It's fixed by at least some other Mastodon servers like Glitch.) Most other ActivityPub implementations correctly enable CORS. CORS is just an example of the treatment that ActivityPub gets.

The ActivityPub endpoints are not CORS enabled because requests to those endpoints are supposed to come from homeservers, not from users' clients. That's the server-to-server protocol, not the client-to-server protocol.

Mastodon devs admit some endpoints should be CORS enabled, and did so. Whatever you do to make this fact "fit" your logic should be extended to the other endpoints. Glitch already extended it.

I haven't seen anybody else talk about what the experience of following somebody from another service is like on the user-end.

Following pixelfed accounts from Mastodon is actually fairly straightforward. You simply see them as a tweetlike message with an image attached. One caveat there is that Mastodon does not allow for as many attached images as pixelfed, and I believe will simply drop any images after a certain point (I want to say max size is 4).

Following a peertube account or channel (you can do either) will show a post whenever new videos are uploaded. You can find the OP on mastodon at https://mastodon.social/@[email protected]. One neat bit of functionality is that if you put all of your peertube follows into a single list, you've basically got a chronological subscribed page (a la youtube). Also take note that comments can be left on either the peertube site or from within mastodon.