jkap

CEO of posting

butch jewish dyke
part of @staff, cohost user #1
married to @kadybat

This user can say it
osu stats


🐘 mastodon
xoxo.zone/@jkap
🖼️ icon credit
twitter.com/osmoru
🐦 twitter
not anymore lol

something that sort of confuses me about the fediverse, conceptually, is the idea that these disparate apps are cross-compatible in some way. like obvs there's mastodon-compatible platforms (pleroma, akkoma, etc) but in general other fediverse (pixelfed, kbin) are either only partially compatible1 or not compatible at all2.

some of this can be easily chalked up to very different modes of interaction3 but if that's the case, why advertise as being part of the fediverse when that's only somewhat true? is it just for Buzzword points?

even some sort of shared identity system4 would do a lot to mitigate this! 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? if anything, it's maybe kinda worse because twitter and instagram at least don't pretend that they're compatible, and i don't have to pick a Twitter or an Instagram, there's just one and i know that it'll be the same one my friends are on.

i guess a lot of this comes down to: "no one has done an especially good job explaining why the fediverse is better than centralized solutions." i realize i am somewhat biased as someone who runs a centralized solution, but this has been a problem at least since i first made a mastodon account in 2017, and i sure as shit didn't run a centralized platform then.

many of the problems that exist on centralized platforms (content can disappear at any moment, you are at the whims of the admins, etc etc) exist on the fediverse too5, and there aren't a ton of benefits beyond "you can host your own."6

this is not an especially coherent set of thoughts, and it's mostly prompted by me seeing kbin, seeing that it's On The Fediverse, and then learning that it holds zero compatibility with THE primary fediverse application. what's the point of building this beautiful, platform-agnostic platform that's the future of the internet if everything is dependent on their own non-compatible extensions to actually function.


  1. pixelfed posts can be viewed and boosted on mastodon but won't display past the first four images

  2. afaict, despite kbin being activitypub based, there is no connection between it and any other activitypub software

  3. reddit and twitter are not the same, so platforms cloning one are not going to be especially compatible with others

  4. hold on while i reinvent openid

  5. first person who says "you can move your account to a different instance!" gets to be the first block on this account. you can't. it's a fiction invented by the mastodon project. "you can export your follower list and force everyone to follow you on a new account" is not account migration. until there is any story for migrating content7, claiming that account migration exists is misguided at best and actively deceitful at worst.

  6. i used to disparagingly joke when people were being shitheads "ok bud, go make your own website then. it's easy. however, now that i've done this for over a year, i can not in good faith suggest anyone else do this. i would only wish "running a social media platform" on my worst enemy, and my worst enemies aren't here for me to clown on them.

  7. "but i don't care about migrating content," you might say. that's great for you! you are not the only person who exists and many people do care about that.


You must log in to comment.

in reply to @jkap's post:

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?

Like if the protocol is just an implementation detail that’s fine, but people keep marketing it as though everything using AP is cross-compatible and it isn’t in any meaningful sense? It definitely isn’t as a default thing. So what’s up with that

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

That first note (masto should add some sort of notification to posts saying "there is more content here") wouldn't that have to be bespoke for each site? that feels hard to scale.

I guess it could be a generic thing? Like any post with "un-showable content" would have a generic note saying "there's more here". It feels like a weird thing -- if it's an open protocol with agreed-upon behavior, and some participants aren't adhering to that behavior, is it a functional open protocol?

wouldn't that have to be bespoke for each site? that feels hard to scale.

depends on which "site" you mean? if you mean each distinct codebase across the fediverse, I don't think that's really scaling, it's just a natural part of building a product that has certain requirements. When people build the product in their mind and then tack on AP support afterwards, it should be on them to figure out how the different capabilities of AP map to what they're going to display. And they're not going to get it right immediately, or even know all the other fediverse apps they should support, but building on the web is building and maintaining a growing and mutating thing, for better or worse

if it's an open protocol with agreed-upon behavior, and some participants aren't adhering to that behavior, is it a functional open protocol?

I mean, (gestures wildly at caniuse.com) "the web" has been doing this to varying degrees of success for decades. I'm eagerly awaiting wide support for text-wrap: balance but I still think CSS has been making really good progress lately

"'there is more content here'… wouldn't that have to be bespoke for each site?" One way to address this at a technical level would be to introduce some kind of "identify your extensions" extension on ActivityPub. IE, you add a field saying "if you can't comply with the PixelFed-1.2 extensions, you should alert the user of missing content add a link to the original post" and the receiving end recognizes that field and acts on it. This sort of extension negotiation is well-understood by programmers and would not be hard to add to the applications or even the spec.

Note my micro-proposal here would still require every instance on the Fediverse to add support for it, but getting every instance in the Fediverse to add support for one extension is not so hard, what would be hard would be Mastodon adding a special handler for PixelFed and also Mastodon adding a special handler for Lemmy and also PixelFed adding a special handler for Lemmy and vice versa and etc. If we can bring the problem down to fix it once per instance instead of create a separate fix for every single pair of Fediverse Application<->Other Fediverse Application, then the problem becomes manageable (in coder terms it scales linearly instead of geometrically). Of course, you'd still have to convince instance software (or at least glitchsoc, gts and akkoma) that this is a problem worth caring about at all.

(Note every ActivityPub post has its "original URL" embedded in it already, and every post on Mastodon already has a "see on original site" option in the ⋯ menu. That's not the part that would require work to add. The thing that would require work to add is alerting the user they want to do this otherwise-unusual thing.)

would be Mastodon adding a special handler for PixelFed and also Mastodon adding a special handler for Lemmy and also PixelFed adding a special handler for Lemmy and vice versa and etc

I guess in my comment what I was thinking was that you'd add a special handler for particular payload types, not with any particular alternate app in mind. In this case it's the "has more than 4 images" payload type, which is not a problem specific to Pixelfed itself, it's just the most likely place you'd notice it. It's fundamentally a restriction that Mastodon (rightfully) decided about their own product when designing it, but it is a symptom of Mastodon's disinterest to do anything but technically support federating with other AP apps to assume that no payload it renders will violate its own assumption.

Note every ActivityPub post has its "original URL" embedded in it already

I know this to be true, but the number of times I have seen people complain about it tells me that Mastodon isn't doing a good job of handling it in their UX and needs to be fixed (but I also have given up on almost any concept of Mastodon being fixed in any way I, or anyone I know, cares about on any reasonable timeline)

I think what I'm thinking is: Handling additional images from PixelFed is one thing. But handling any type of content, functionality, protocol extensions or verbs in any site… that, you might have to do some actual thought for.

It seems intuitive that if the spec (AP) has no limit on the number of attached images, and some specific instance implementation (such as Mastosoc) imposes a limit of 4, then it seems "obvious" Mastosoc should notice the fifth image and electively add the "click for more at home server!" tag– because in that case it is Mastosoc, not the remote instance, who is deviating from the spec. But for the Fediverse to actually grow at some point people are going to start adding actually novel things, and because that could be virtually anything (for example imagine like, a Fediverse Steam that lets you join in on a game from the client, and a "game starting!" announcement is posted as a status– "join game" isn't really a new type of content, it's a verb), it does seem like we have to expand the spec a little to fix this problem for "non-obvious" content (or we fall into the "bespoke for each site"/"hard to scale" problem Dante mentioned).

I do agree that Mastodon gGmbH's general disinterest in, like, standards of any kind or interoperability with literally any server except the one on their github is the major impediment to this kind of feature work, and in fact in general is the major impediment to growing the Fediverse in any interesting way. Which is frustrating because Mastodon gGmbH's tunnel vision is also the thing that makes the Fediverse successful, to the extent it's successful at all, IE, Eugen's bullheaded insistence on making a website people want to use over like waiting for a standardization process or whatever is the reason people have heard of Mastodon but not Friendica or GNU Social. But wow it creates problems! (Actually, it's possible the spec already has this sort of extension-in-use alert capability and I just don't know about it because Mastodon doesn't implement it.)

definitely just hit discard on a long comment on my phone, sigh, but basically I agree with you that that more abstract way of thinking would be great and should be carried forward by some kind of active standards group that is working on making the aim of ActivityPub
increasingly more useful and successful. whether that group exists or not today I have no idea, so I guess I’m thinking more pragmatically about what people with commit access to individual apps that speak this protocol could do today.

I agree with what you said about Mastodon/Eugen and what they’ve accomplished! It’s a double-edged sword, and it’s also kind of unfortunate that their idea of “a website people want to use” is not quite true for a large portion of “people”

(also tangentially the AP spec’s companion spec ActivityStreams stubs out an Invite Activity as a subset of the Offer Activity — for anyone reading who isn’t familiar, Activity is a type of Object that describes a verb and usually has an Actor that did the thing and some Objects that represent the target and/or materials necessary)

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

This is an extremely good writeup and, having read it written out, I think #7 is the most important part to me. I'm tinkering with ActivityPub because I can do it, and already have, and it's fun. We are now in a timeline where ActivityPub software will continue to exist on the internet, much like IRC continues to exist on the internet, and that's interesting/compelling to me whether it is to anyone else or not

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.

i didn't say it was fundamentally impossible to tunnel a good protocol over activitypub, because that would be an insane thing to say. i said it has no concepts or amenities for these very important things, and they have never planned for them.

Please allow me to present how you're coming off, here, before I stop replying to you.

I said: "decentralization...[is] a guarantee that there's no way to take out the entire network"

You replied: "the thing you like decentralization for is not present in the fediverse..."

I politely corrected that statement, and you claim to have not said it. I don't appreciate that. I don't appreciate your interest in telling me what to like and not like. I don't appreciate your attempt to use me as a proxy for your annoyance with other people. I don't care what justification you're planning to type about why no, you think you technically acted in a totally different way.

If you want to get involved with the ActivityPub spec, I recommend getting involved with the appropriate groups, rather than trying to pick a fight with me. If you want to avoid ActivityPub-based applications, you have my full permission to do so, if that's what you're looking for. My opinion doesn't need to be your opinion, and you should accept that yours will not be mine.