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.

alternatively: why are you linking to an image at all and not just making a text post

just want to clarify something:

However, the way that activitypub works, the outgoing data is publicly available. Defederating with Meta doesn't prevent that,

there is a technical solution to this in the form of authorized fetch: https://hub.sunny.garden/2023/06/28/what-does-authorized_fetch-actually-do/

mastodon implements it, pleroma/akkoma probably implements it, pixelfed implements it, firefish and iceshrimp implement it (sharkey has a PR implementing it opened just today), gotosocial not only implements it but enforces it, with no ability to turn it off

notably, none of the threadiverse software implement it, and no software other than the aforementioned gotosocial enable it by default.

They aren't forced to do anything. Manifest v3 is just a part of the WebExtensions API (which is not a standard and is really just "whatever Chrome does except we find/replace'd the word chrome to browser") which both Safari and Firefox chose to implement in order to make porting of Chrome extensions easier.

Before that, Firefox had a much more powerful extension system that allowed extensions quite a lot of access to browser internals, but that turned out to be a maintenance nightmare so they walled those APIs off (not a coincidence that Firefox started getting massive performance improvements after that, and extensions stopped breaking every other release) and decided to go the WebExtensions route. I have no clue what Safari was up to but I think they implemented it after.

If they don't implement Manifest v3, extensions that want to work across multiple browsers need to support both the older Manifest v2 and the later Manifest v3, which would be a burden not many extension authors would want to bother with, which would make them just say "yeah we're not supporting anything outside Chrome". Firefox avoids this problem by extending the v3 API to allow for the functionality necessary for powerful ad blocking Google removed in v3 (webRequestBlocking) while also implementing the new thing (declarativeNetRequest) side by side, so extensions that want to take advantage of the powerful features on Firefox can do so, while Chrome extensions that are fine with the less powerful alternative can still be ported over relatively easily.

Firefox does have it's fair share of extensions on top of the WebExtension API already (sidebar support for one), so adding one more isn't too big of a deal.

TLDR of linked gist: wayland is not X therefore it is bad. end of.

Wayland breaks Xclip: As you said it yourself, Xclip is an X11 application, so it doesn’t work on Wayland. Of course it wouldn’t work on Wayland. With Wayland, we’re trying to prevent what happened with Xorg from happening again, or am I wrong?

also, https://github.com/bugaevc/wl-clipboard. perhaps all OP (of gist) needs is a simple shim that can convert calls to xclip to wl-copy/paste? that doesn't seem too hard to make compared to keeping X.org alive I'd say (perhaps they should try making it if it's that much of a problem)

Wayland breaks screensavers: Yeah, that seems to be the case.

from the dev of xscreensaver at https://www.jwz.org/blog/2023/09/wayland-and-screen-savers/ :

[...] Adding screen savers to Wayland is not simply a matter of "port the XScreenSaver daemon", because under the Wayland model, screen blanking and locking should not be a third-party user-space app; much of the logic must be embedded into the display manager itself. This is a good thing! It is a better model than what we have under X11. [...]

[...] Under X11, you run XScreenSaver, which is a user-space program that tries really hard to keep the screen locked and never crash. It is very good at this, but that it needs to try so hard in the first place is a fundamental design flaw of X11. [...]

other people can comment on the parts they know about, these are two i know of off the top of my head

you mean they should turn off the user-count-go-uppinator? but how would the fediverse grow like that?? /s

(sorry i just have opinions on large instances)

Oh no it'll federate alright.

The thing about ATProto is that unlike AP they don't seem to expect each instance to have it's own community with it's own rules and vibes. They seem to be using federation just as a way to "scale up".

If they can get any non-bluesky-the-company folk to create instances then that's just scaling they don't have to pay for and a convenient legal scapegoat for the inevitable consequences of their lax moderation. Why wouldn't they federate?

If they're banned from their own instance, that ban federates out and they're completely banned off that account.

If some other instance bans them, that ban is instance specific and that person can still interact with communities and people from other instances, except the one that banned them.

A better idea would be a generic content warning system replacing the existing NSFW toggle. This would not only improve compatibility with the rest of the fediverse (which does use support CWs) but also give you way more filtering options than just "safe, tits or gore".

CWs should be applicable to both communities and individual posts, and would "stack" on top of each other. (Each post would "inherit" the CWs of it's community.)

Security? Probably. I wouldn't expect any measurable improvements to performance but the with compiler being able to do more checks it might enable some clever optimization trickery that would be harder to maintain in C.

Still, Rust on the kernel probably won't leave the realm of drivers any time soon, so it all depends on if you have the hardware that will use a driver written in Rust.

A popular misconception is that Firefox runs Gecko. And while that is kinda true, the real problem is much more interesting when you come down to the technical details.

Because it's the other way around. Firefox doesn't run Gecko, Gecko runs Firefox. Firefox is built in Gecko. In a similar vein, Thunderbird also runs inside Gecko. It's why they look so similar despite one being a browser and the other being an email client. Gecko is, in a way, a proto-Electron.

You cannot "rip off" Gecko from Firefox and embed it inside something like you can do with Blink/Chromium (unless you're on Android and use GeckoView), which means the only way to have a "Firefox based browser" is to fork the entirety of Firefox. There are forks like the TBB or Librewolf that do this, but the embeddability of Chromium makes it much easier for devs to make something that diverges from Chromium in major ways (stuff like Qutebrowser, for example)