Eh, I’d make the argument the fediverse is overly inefficient, way more than it has to be. (But that doesn’t seem to be the actual point of the post, instead rehashing the same “distribution = good” thing without bringing anything new to the table)

Here are just a few things that could be fixed without needing to centralize fedi:

• A vast majority of instance software will store all old remote non-media data (that could easily be re-fetched when needed) permanently, even if nobody has seen it in years.
• If you’re lucky enough to be on instance software that backfills replies (GoToSocial, the Iceshrimp rewrite as of a few days ago, Mastodon in an extremely limited capacity), it will be done slowly and recursively, when much better alternatives that don’t need to deal with easy-to-get-wrong recursion handing are possible. (There is work going on to improve this, but it may take a while for it to land on enough instance software to make a difference)
• The obvious thing everyone harps on: Abysmal media caching defaults.
• No batching of activities. And relatedly, all sent activities are individually re-signed for each instance on each delivery (to be fair, handling this in a privacy preserving way is hard)
• No batching of fetches.
• RSA, just to make the above signature situation even worse
• Mastodon. Just in general. It’s by far the most heavyweight fedi software I know of, running on a synchronous and poorly threaded tech stack that’s is not very adequate to the fairly IO bound (when not using authorized fetch) and very concurrent AP use case. Running Mastodon for any instance less than ~500 active users is extremely overkill and you’d likely be suited with other, lighter, instance software if you don’t need any of the features that are Mastodon exclusive (which there aren’t that much of).
• Pleroma database rot, an exemplar of why the C2S advocates’ model of “store the raw JSON for everything” is a terrible idea (thankfully the C2S model hasn’t taken off enough to be important)

But these features were totally non-standard extensions right?

that’s the thing, everything in activitypub is a non-standard extension. hashtags are an extension. post visibility the way it’s commonly done is an extension (more like a convention in that it doesn’t introduce anything new, but still not written down anywhere official), the concept of an un-locked account is a convention (and the marker that marks an account as locked is an extension). pinned posts, marking images as sensitive, they’re all extensions

(surprisingly, this is the second time i’m writing this exact thing today)

It’s weird but it almost feels like the fediverse needs a benevolent dictator to kind of get an overview and set a clearer direction, when it comes to the standards.

this has historically been mastodon. and they have put themselves in such a place that anything they do not approve of gets seen as a “nonstandard extension” and anything they approve of gets seen as a part of the standard. see the above reply.

edit: additionally, emoji reactions are federated by the SECOND MOST POPULAR free/open AP software and has implementations in at least 5 other software families (not just forks of one software, entire software families). if they cannot determine a de-facto standard but mastodon can, is AP really an open standard?

this issue is a blocker for mastodon not supporting filtering remote posts by words (which would’ve helped with many spam attacks, which the pleroma family supported just fine for a WHILE via MRF, and more recently misskey has added support for)

if you go to socialhub you’ll find MANY threads of reasonable ideas that are in json-ld representation bikeshed hell as people unnecessarily debate over which exact json-ld representation of the same exact data is the most correctest. the most infuriating recent ones i have seen is the emoji reaction fep discussion and FEP-fb2a: Actor metadata both of which does this bullshit ON FEATURES ACTIVELY FEDERATING RIGHT NOW, where changing it would BREAK BACKWARDS COMPATIBILITY

Yeah, that is a shortcoming of the protocol. But it’s necessary in order to be secure until things improve (and given this is AP, that’s gonna be a while. People seem to love bikeshedding in circles instead of doing actual work)

Instead of sending the entire object embedded in the activity the secure way would be to only the URI instead. This is permitted by JSON-LD.

In the receiving side, if the object is untrusted (i.e. if it isn’t signed or if it’s from a separate authority from the parent object containing it) it should be thrown away and the id should be fetched from the remote instance directly (same as it would happen if it was a URI instead of an inline object). This is completely an oversight on Lemmy’s implementation and not a protocol problem.

I seriously doubt Lemmy currently does any validation whatsoever. There were communities using this blatant security issue for non-malicious purposes (see https://endlesstalk.org/c/[email protected], which re-wrote posts from people (which is only possible if the posts weren’t validated, or at least re-fetched from their origins)).

There is a way to re-share and validate remote activities, either through LD signatures (ew, JSON-LD processing :vomit:) (which only Mastodon and Misskey implement) or the newfangled FEP-8b32 Object Integrity Proofs (which nobody relevant on the microblogging space implements).

Yep, all this ^^^

This is also one of the reasons why I believe ActivityPub client-to-server failed and will likely never gain much traction. It either needs every single client to re-implement all the features it wants from scratch, or the entire ecosystem needs to be dumbed down to fit a single mold. Leave all the unique functionality in “uncommon” software like (streams) and friends, even software like Lemmy or PeerTube would likely be extremely difficult to build in a world where client-to-server actually became a thing.

The only way I can see C2S actually taking off is as IPC protocol between an “app server” (which would be the equivalent of Mastodon or Lemmy or (streams)) and a “federation server” which is just a dumb pipe that distributes and receives objects and activities, and even that has it’s fair share of concerns, both around efficiency and the same “dumbing down” problem.

to be fair there isn’t that much about the fedi in general that you can meme about. the closes you can get are in jokes but:

a) lemmy doesnt have them because this place is uncreative and only serves as a dumping ground from memes from other places when they aren’t bickering about politics
b) in jokes of different parts of fedi do not translate well just because they share a protocol, given the extremely little overlap on people here
c) they’re not really “fediverse memes” just because they happened in the fediverse, are they

the specs are so open ended that i doubt real interoperability will ever happen. you can break interoperability with basically every other current software out there and still be compliant with the specs

that post will have been a text post, not a link (those are likely broken now, and certainly were broken a year ago due to a bug in the misskey 12 codebase inherited by firefish and forks. modern versions of misskey just fixed that a couple months ago)

the username thing does not completely break federation, but it will randomly confuse instances. there’s a 50/50 chance whether an instance will get the correct user it asks or not, and once an instance resolves a user once it’ll have a similar 50/50 chance for each profile update (icon change, sidebar change, etc.). of course, if there’s no conflicting user for a community (or vice versa) then federation will be fine.

oh no that’s not a new change afaik it was always like this

I also wish there was an app that let me browse/post/comment on Lemmy using a Firefish/Iceshrimp account so I could theoretically consolidate accounts.

that’ll be difficult. Lemmy killed interoperability when they first decided that users and groups could share the same username, and now itd be a breaking change in order to solve this on Lemmy’s end.

each software willing to federate with Lemmy correctly needs to be modified to handle multiple “users” having the exact same username, and i suspect most have more important priorities to tackle before getting to that

(misskey 12 derived software also has their own interoperability bugs regarding Lemmy, but those are usually not as big of a refactor as the username thing)

It was never unusable beyond the stability issues large instances (from 1k to howevermany people ff.social had) had. For smaller instances it worked fine and continues to do so. The issues with large servers were the result of it being based on an ancient codebase (Misskey v12) with extremely questionable changes thrown on top (muting enough words could cause the entire instance to slow down), and the issues with ff.social were specifically caused by throwing everything at the wall to try to duct-tape that ancient codebase to function (ScyllaDB was the nail in the coffin i believe…?)

Firefish itself is still going (see firefish.dev), there are forks like Iceshrimp which reigned in the issues enough for larger servers to not fall over every few seconds (iirc both the infosec.exchange hosted Firefish instances migrated over which caused the main issues to be found and fixed). I wouldn’t be surprised if “Modern” Firefish took the most important changes over from Iceshrimp (the devs are friendly, and the Mastodon API implementation and some security fixes were shared between both)

If you want something a bit lighter, Misskey itself is still ongoing, and there are forks like Sharkey that do some of the modifications Firefish and similar forks did to tailor it towards a non-Japanese audience.

(And Iceshrimp.NET is a project worth keeping an eye on, which aims to get rid of the technical debt of the Misskey codebase by completely rewriting it, but is not ready for much more than a single user instance just yet considering it’s been a thing for just about a year)

Iceshrimp is a fork, yes, but Iceshrimp.NET (the repo you’re linking to) is not, being a complete rewrite unassociated with any Firefish or Misskey code beyond keeping the database schema (for easier migrations).

No. They changed hands after the original developer decided to leave for good (and start some crypto scheme which, AFAIK, went nowhere). The repos are now at https://firefish.dev, and no official flagship exists (which IMO is the right way to develop a fedi software)

Simply by choosing a lesser used fedi software you’re helping keep the fediverse from being dictated by a single software’s whims. So that’s a big plus there. Federation issues with kbin/mbin/azorius/other lesser used instance software will inevitably happen as people only test against the largest player in the field (in the ““threadiverse”” that’s Lemmy, in the microblogging fedi that’s Mastodon). So simply by not picking the largest you’re, even if in a small way, helping not only mbin but all the lesser used fedi software as a whole.

Your own local communities being “dead” mainly boils down to communities themselves having a network effect around them where the largest one keeps growing larger as everyone focuses on it. And the largest communities are usually on lemmy.world (or occasionally other Lemmy instances). There isn’t that much you can do there.

In my experience, it’s always the smaller software that innovate. The same is true in the microblogging fedi (emoji reactions, quote posts, markdown, nomadic identity, reply permissions) just as it’s true in the ““threadiverse”” (combining communities together, the ability to follow people, polls apparently (?)).

So really, don’t worry about the size of your own instance’s communities. As long as you trust your instance’s staff to keep you safe there’s no real reason not to get on a smaller instance, or on different software. Especially on here, where “discoverability” is not as much of an issue as it is in the microblogging fedi.

Doesn’t help. Everything from the meme/joke/fun communities you’d expect people to use to tune out The Horrors™ to discussion about the ActivityPub standards (what little exists that doesn’t conflate it with Just Lemmy or Just Mastodon) devolve to US politics in like two comments. For me at least this entire section of fedi is a US politics-radioactive one I try spending as little time as possible (that includes posting non-politics!)

I find myself having significantly more fun on the microblogging side of the fedi, ruining jokes to ground in like 4 minutes with my oomfs and making followup meta jokes about how jokes only last 4 minutes. People actually use content warnings to hide away The Horrors™ when they want to talk about it, which means filters actually work. (Things like alt text for images also helps with word filters!)

small correction: the post that displays the instance you’re on (https://void.rehab/notes/9umvfd1lgoulvm0j) won’t work with “'regular” iceshrimp. it depends on an extra patch added to the version on void.rehab to function.

After seeing a team of fedi software developers drop their Matrix bridge to their Discord after the total lack of moderation tooling resulted in an extremely transphobic spam wave, I for one am not surprised.

Another team I’m aware of also dropped Matrix for other reasons, but went for Zulip instead, which is also open, but more collaboration oriented a la Slack rather than community oriented like Discord, which probably would not fit what the group in the OP is looking for.

Lemmy’s cross posts are separate posts that just happen to link to the same thing. so only replies to the original post would be sent with the current design.

that said, i severely doubt Lemmy will gain anything from this. publishers will not be sending out their posts to any communities, and i highly doubt they will expose any fep-1b12 group actors you can subscribe as a community.

kbin/mbin with it’s ability to follow users may work better, assuming people test their federation with software other than mastodon, and accept any of the interoperability bugs as actual bugs instead of ignoring them. (lemmy itself is no stranger to this: the fact that users and communities can share the same username break quite a bit)