2 Live Crew, Thanks for Everything! Julie Newmar

Yeah I've always wondered this too. I saw a Mastodon account promoting someone's peertube thing by username, and I clicked through, and I could only see two posts from a year ago. I realized "oh what if I click this URL to go see it on its own page" and it had been making daily posts over on peertube, they're just 100% invisible from Mastodon. Like, what? You can't even use it to subscribe cross-platform? Why market it as being the same protocol then?

(the activitypub defender logs on)

I think better compatibility is POSSIBLE and this is more of an indictment of Mastodon than ActivityPub itself. Like in your example I do agree it's weird that Mastodon has zero accommodations for Pixelfed posts with more than 4 images-- it would be nice if it would at least parse that there are more than 4 images and then say "well our product relies on there being fewer than 5 images, so we'll just show the first three and then insert a fourth image that indicates to the user that there are more images at the source". It also should then make it so that ANY clickthrough to details of the source takes you to the pixelfed instance's page, because it has recognized that it doesn't have the ability to fully represent the post on Mastodon, but it's still useful to show up in the timeline as a sort of lighter-than-RSS-but-better-than-a-fucking-Zapier-automation play.

like, I think the thing is that more people should be making a new generation of activitypub apps that actually take interop seriously and consider from a human/"product thinking" standpoint what it takes to make that valuable, because I do think the current solutions are fucking it up but that there is actual potential just sitting there wasted (signed, the person who spent a full day trying to figure out how the hell to publish an AP Note with hashtags in it that would integrate with Mastodon's hashtag search capabilities, which are HANDLED PURELY CLIENT-SIDE WHAT THE HELL)

I think even the partial federation between PixelFed and Mastodon is potentially very interesting, as someone who posts a lot of photos and a lot of shitposts.

There are several limitations on that in practice, such as

• PixelFed is not fully cooked
• Mastodon is, as a culture, stressful to me
• It would definitely be better if there were a way for the system to know that it's me on PixelFed and on Mastodon. I'm not technical, but naively it seems like it should at least be possible if they're both running on the same domain, e.g. if my Mastodon instance were to also start a PixelFed instance.

I think that there is value in the federation model, I like the idea of being in a community that has its own norms and standards but being able to interact with folks in other communities. However, in practice, what it takes for instance moderators to keep up with fediblock stuff properly, usually without adequate, or in many cases any, compensation, really counts against the fediverse's ability to to scale without becoming toxic.

i think it comes down to the sort of Big Shining Ideal that activitypub enthusiasts have for being able to consume feeds of various types from various sources in the client of their choice butting up against the reality that most people's activitypub client is specifically written for mastodon. like, i run a decent-size masto instance and it's honestly kind of annoying when someone tries to follow a pixelfed feed using their mastodon account, bc it downloads so much more media than most mastodon/pleorma/etc text-first feeds do.

re: identity--matrix is (as i understand it) trying to do something interesting there with the concept of an identity server, which may or may not be part of someone's homeserver, but afaik the only people using it are matrix. i also run a matrix server that's interlinked with the mastodon bc it can serve as an SSO provider, and now anyone with an account on the mastodon can automatically log in to an account on matrix. i think that feature, masto being able to do SSO, gets overlooked by the other fediverse/activitypub projects a lot. it would certainly make things easier than having to maintain a separate account/identity on each of the federated services!

i'd love to have compatibility with pixelfed with The Fediverse App because i want to post art in a way that can be seen by others as i want to present it, but with how things are now i've just been forced to stand up my own mastodon server and accept that as good enough

the idea that "built on activitypub" is a description of use of it as a federation protocol in the same way "www is built on http" is a description of how to access content feels like the best reason why there's all this incompatibility

but no "fediverse browser" exists yet that lets you view everything you'd be accessing with activitypub in a sensible manner, and if one did i think it'd feel like some strange combination between a website, a browser, an rss client, and an email client

1. It might clarify things a little to be aware that there are two modes of "compatibility" on the Fediverse, the "Mastodon API" which allows GUI clients to connect to servers and display a Mastodon feed specifically, and ActivityPub which is the API that the "real Fediverse" runs on. In principle you could make a GUI client with the ActivityPub protocol alone, but generally people do not (and people making non-Mastodon-like Fediverse apps tend to loudly complain that people do not do this).

2. It probably makes the most sense if you think of ActivityPub as "RSS with push". Several of your questions become clearer if you mentally edit out "The Fediverse" and substitute "RSS". ActivityPub, like RSS, is a primitive more complex software can be built on. Why do some ActivityPub features only work with some methods of accessing ActivityPub? Because those are application-specific extensions to ActivityPub. (In RSS one understands that there can be nonstandard extensions for special clients but you degrade to a more basic form of operation when they're not in use.) Why use ActivityPub at all, if you may not be able to take advantage of those application specific features? Because the least-common-denominator form of operation is often useful, because there is always the possibility for your application to grow those application-specific features later, and because even for the most incompatibility-heavy extensions of AP modeling your distributed application atop ActivityPub saves time over designing it from scratch. (With RSS we saw multiple quasi-RSS standards, including total reinventions like Atom, pop up using RSS as just a base.)

3. There really isn't a single "Fediverse". There are several fediverses, the Mastodon verse, the Pleroma verse, the Pixelfed verse, the Lemmy verse. The Mastodon and Pleroma verses mostly interoperate, the others maybe not so much. I think this is okay because "Fediverse" is kind of bad branding to me, it sounds like the alternate plane of existence the video game "Control" is set in

4. "some of this can be easily chalked up to very different modes of interaction but if that's the case, why advertise as being part of the fediverse when that's only somewhat true?" Because most people talking about the Fediverse this way are interested only in the "Greater Mastodon" community of Twitter-like services, and within "Greater Mastodon" there pretty much is reasonably full interoperability— you're more likely to see two servers within that "application" unable to speak to each other for moderation reasons than because of feature incompatibility, and a server being blocked off for moderation reasons is ostensibly a "feature". And, of course, there's an assumption that even if some applications can't interoperate well, they will be able to in future; in principle those "least common denominator" apps like Mastodon should eventually be able to support, if not full app interoperability, the ability to intake anything another app publishes as a subscribable linear feed (remember, ActivityPub is RSS with pubsub; one doesn't expect to be able to use a web app fully through RSS, one just expects to be able to use it to subscribe to linear feeds). Any failure to do this will probably be treated as a bug and eventually fixed, in the Pleroma/GTS branches if not the Mastodon-dot-social branch. (There's already some interesting quirkmode features toward that end in basic Mastodon servers, for example, Mastodon-dot-social is able to render rich-text posts from servers that support that, even though Mastodon-dot-social is not able to create such posts.)

5. "even some sort of shared identity system would do a lot to mitigate this!" I want to linger on this. At present, there is a real problem in ActivityPub software where instances bundle together being an application provider with being an identity provider. I believe all of the Fediverse's most significant practical and UX frustrations are downstream from this problem. If you have an account @you@mastodon.social then mastodon.social is not just your domain name, mastodon.social is the application you use to access the fediverse (and any additional GUI client you might stack on top of that, an iPhone app or something, are just frontends/skins to that application). You aren't using ActivityPub; your instance is doing it on your behalf. It is (notionally not literally) like if your email server had to individually support each type of attachment you might want to add to an email. This feels deeply unnatural and is difficult to explain to end users without trying to explain what's happening at the code/protocol level, which is not something you should have to do with end users.

   However if application provider and identity provider were delinked, like they are in (for example) BlueSky, then you could have a single shared login and use it to log in to both mastodon.social and pixelfed.org, and get Mastodon application features from mastodon.social and Pixelfed application features from pixelfed.org while (a) presenting the same username on both and (b) not having to commit to create an entire new "account" just to try out a thing or two on Pixelfed. There are proposals that could get us to this point (for example Christine W.L. who was an editor on the ActivityPub standard, has a proposal for attaching DIDs [the standard BlueSky uses an extension of] to ActivityPub) but at present they are not being adopted and getting to the point they are adopted will be a challenge (and worse, it's a community-building challenge rather than a technical challenge— IE, the hard kind). As a Fediverse-software developer I spend a lot of time thinking about how to make this work happen and I don't currently have an answer I feel confident in.

6. "but if i want to use pixelfed, i need a pixelfed account in addition to my mastodon account. how, other than the general "free software" shit, is this better UX than having an instagram account and a twitter account" I don't know how to use Pixelfed so I'm going to answer substituting Lemmy (that's Fediverse Reddit). At the moment, the advantage of using Mastodon instead of Twitter is that Mastodon cannot get bought by Elon Musk, go berserk, and ban all third party GUI clients, and the advantage of using Lemmy instead of Reddit is that Lemmy cannot decide to go IPO, go berserk, and ban all third party GUI clients (or instead of banning third party GUI clients substitute any other wild thing Musk has done in the last year). Or rather— Mastodon.social can go berserk in this way, or Lemmy.ml can go berserk in this way, and you might actually have to abandon your account on one of those servers and move somewhere else. But the community is not on any one server, it is on the agglomeration of the servers, so you have the option of switching to another server. Lemmy.ml (the "main" Lemmy instance) actually is going through an interesting thing where the moderators are taking some… let's say "interesting" stances with regard to politics discussions, and so people are moving away from Lemmy.ml. But moving away from Lemmy.ml is relatively low cost, so this has little effect on the overall community. It would definitely be nicer if there were a migration feature so I wouldn't lose my post history, and even nicer than that if DIDs or something existed so I don't lose my handle/address, but even without those nice hypothetical features I am able to move from Lemmy.ml to Beehaw and my experience of using Lemmy does not noticeably change, because the community is in ActivityPub, not on Lemmy.ml. Whereas if I stop using Reddit, I… I stop using Reddit. That's it. The only way to switch from Reddit to Lemmy is to completely abandon one community and join another.

   You may have noticed this doesn't answer your question. That's because the answer to "How is a Mastodon and a Lemmy account better UX than having a Twitter and a Reddit account?" is "it is not better". One can argue that having a Mastodon account is individually better than a Twitter account and that a Lemmy account is individually better than a Reddit account. But at present, we are not at a place where the Fediverse is getting real benefit from Mastodon and Lemmy, or any two sufficiently dislike ActivityPub-based applications, having least-common-denominator interoperability.

   (In order to get there, we need to either do the identity-application delink I propose above [5], or Mastodon and Lemmy would both have to individually do work to integrate their applications better [unlikely given Eugen's approach to product management, but maybe either Lemmy can make it easy or Lemmy can better document how to make use of whatever least-common-denominator features already exist], or every single Fediverse user would have to start hosting their own instance so that they can add whatever feature plugins they want [untenable] [although CalcKey is trying to make it happen].)

7. "no one has done an especially good job explaining why the fediverse is better than centralized solutions" I am not interested in making a persuasive argument to anyone on this particular point. I am okay with simply losing the argument if that is the argument that is happening

I think this is actually an excellent point to rise. Shared protocol doesn't automatically imply functional compatibility, and can even enable 3E tactics. My first thought about fediverse was "I still remember how Google and Facebook devoured Jabber."

For whatever my personal analysis might be worth, there are different classes of problems, here, that all look the same. You've got different layers, different teams, and so it's not all one thing. Specifically:

• There's some excessively utopian design in ActivityPub, where the original team designed it to work for "anything," by specifying (next to) nothing. That means that it's always possible to share content across systems, but it'll never happen accidentally. That leads into a related issue.
• All software is (essentially) unfinished software. There's always more to do, and not enough time to do it, so shared content is incomplete, and account migration relies on Eugen (for example) caring about it enough. And since he's unlikely to migrate servers on a regular basis, that's probably low on his list unless there's a massive outcry.
  • In one word, your post outlines half of a perfect example: OpenID. There's no reason that we can't have every ActivityPub server serve as an OpenID provider and automated logins across servers, except that none of the teams has probably given it any thought.
• While "just run your own" is laughably naive, it's still a legitimate option that reduces the modern equivalent of the "Bus Factor." (As in, we used to ask "how many people on the team can you afford for buses to hit before the team can't continue?", but now should mean something like "how many people do you need to buy off before this site betrays all its users?") Federation means that no single organization can wipe out everything, but there's always going to be someone who can pull the plug on any given post, if only because they can stop paying the server bills, barring something (ick) blockchain-y where every participant keeps a copy of everything in perpetuity.

My overall opinion is that I prefer decentralization (and open source), on the basis that (as I hinted earlier) it's a guarantee that there's no way to take out the entire network. I like it here much more, for example, but however high and maybe shady, there exists a dollar value that could put Cohost under highly unpleasant management. No price can do that to the Fediverse, because you'd need to go through every server and still can't stop the next person to run one. That's worth some (as yet) unfulfilled promises.