ShittyKopper

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.

my condolences

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.

Just because you wish to talk about your own country does not mean I want to listen to the politics of a country I am not a citizen/resident of nor have ever set foot in. That's what content warnings and other functionality allow me to do. Unfortunately, Lemmy.

(Also notice how I specifically single out "US politics" and not "politics" in general. That is a different thing where "politics" is sometimes used to mean "anything I don't like not from a white cis het from the upper middle class person". That is not the case here. I am simply tired of hearing about Trump and Biden and Harris and whoever the new VP is or whoever the Republican Main Character of the day is or the Democrat Main Character of the day is)

True, that will at least let you figure out what is a fediverse link and what isn't. Most implementations I know either use the same URL for both the AP representation of a post and it's HTML one (differentiated by the Accept header), or have a redirect from the HTML view to the AP representation when an AP type is requested (or, very rarely, the via Link header/ html tag), which means you can reuse code used for the "search URL to load community" feature in order to make this possible.

Given the list of fedi instances your instance is aware of is already present in the API, clients already have the tools to do this, I believe.

How do you expect for that auto-detection to work? Just a regex on example.com/c/community? What happens when some other instance software decides to use a different URL format? Or do you just assume Lemmy is the only thing out here?