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/tails@lemmon.website, 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.

most people on lemmy do not understand the tradeoffs both activitypub and it’s implementors do, as evidenced by this exact community we’re in. these memes wouldn’t gain any traction even if they were funny to their intended audience (which i have doubts on if it’s possible to do but idk i’m not creative enough)

id argue none of those are fun topics you can joke about but “memes as a form of outrage” (aside from, like, two) which is already a problem (see all the political memes on any of the meme communities for countless examples) we do not need to encourage imo

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

iirc mastodon was implementing smithereen’s flavor of groups. no idea if they ended up changing course or anything (not following masto dev tok closely) but the way they work is fundamentally different from how Lemmy and compatible groups work

from what i can tell (from the work in progress pull request) mastodons group implementation explicitly does not aim for compatibility with lemmy

other than that, i agree on activitypub being crap in terms of making interoperability easy

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.

Mastodon moves also take your following with you. You’ll still have to reimport followers, but you don’t lose your ““audience””.

There are software out there (Sharkey for microblogging (Firefish also had it but theirs was broken and leaked DMs), PixelFed for images from Instagram specifically) that allow some form of post imports, but these are only brand new posts that happen to have the same content as the old ones, and not “replacing the author of a post”.

There are work going on regarding nomadic identity and more seamless account migrations across instances, but hell will freeze over before any of the mainstream fedi software implement anything close to that, mainly due to how significant of a conceptual change that is.