not much beyond "look at what other apps you're trying to interoperate with output and try to reverse engineer your way through". reading through the sources of other apps may be a good idea.

some links that may get you started, picked from https://socialhub.activitypub.rocks/t/guide-for-new-activitypub-implementers/479 :

• https://flak.tedunangst.com/post/ActivityPub-as-it-has-been-understood
• https://www.w3.org/community/reports/socialcg/CG-FINAL-apwf-20240608/
• https://swicg.github.io/activitypub-http-signature/
• https://seb.jambor.dev/posts/understanding-activitypub/
• https://tinysubversions.com/notes/reading-activitypub/

and depending on which ecosystem you're targeting:

• https://docs.joinmastodon.org/spec/activitypub/
• https://join-lemmy.org/docs/contributors/05-federation.html

counter intuitively, avoid reading the specs if you're looking to federate with existing software. the official specs are... extremely lacking beyond giving you the bullets to shoot yourself in the foot with (half of what little it defines goes unused in the real world, important things like "how do i know this activity is sent by the person it claims to be" is completely undefined (hint: everyone has more or less settled on http signatures).

once you get something federating, you can then look in the specs in an attempt to learn the concepts in depth, but writing code following the specs will result in code that simply won't federate.

A lot of it boils down to most fedi software not being "native" and only having federation designed more-or-less as an afterthought addition on top of a traditional centralized-ish system (even for ones that have federation from the get-go). Meaning you make assumptions like "it's fine if I deletes the replies of a post if the post gets deleted".

This, combined with how much data you can't re-load and have to track as it comes in (e.g. nobody implements the necessary collections to backfill who liked or boosted what from it's source, so you have to track that implicitly through Like and Announce activities), makes it extremely infeasible to implement while keeping the same user experience. Hell, even reply collections needed to backfill missing replies are a rarity (though a lot more common than the others given Mastodon implements them).

Additionally, people want the same user experience they're used to in centralized systems, like search actually searching through everyone, globally. This is something I believe AP simply isn't "intended" for. ATProto, for example, is much better in this specific regard (but comes at it's own hefty costs, as an implementor).

I don't blame the implementors for doing things this way. IMO it's better to partially implement something like AP as an extension, as opposed to diving in head first into being AP-native. The standards are extremely vague and incomplete once you start looking below the shallow surface, and this way at least if a better protocol comes by migration (or multi-protocol federation) won't be too difficult compared to if your source of truth was the same AS2 data you federated, the way AP intended you to.

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)

I mean, I'd say that all instances copying media by default, to be stored forever, is kind of unnecessary. (And as far as I'm aware Mastodon is the only one configured like this by default anyway)

The largest instances? Sure. I'd say they have an obligation to not DoS smaller instances by simply hotlinking or proxying without any kind of cache. But smaller ones can get away with short lived middleware-level caches, and single user ones can often get away with hotlinking (oh boo hoo your firewalled IPv4 behind enough CGNATs to block any incoming connections got exposed)

One idea I’ve seen floated around is to have some sort of cooperative CDN for instances. Let’s say four or five relatively kindred instances, make a commitment to last and pool their resources to maintain a joint CDN from from which they’ll get their “media federation” from. This would reduce costs and issues a lot, since by the very nature of the fediverse, if everyone builds their own caches most of those caches are going to be hosting most of the same content. Basically: deduplication, but the poor man’s version.

https://jortage.com/ already exists, and the code behind is open.

yep, definitely. i just thought "hey wouldn't it be funny if two dudes just ate some undefined substance because it's cheap" and, uhhh, yeah

i genuinely love it when people make their own meaning about shit i make sleep deprived out my mind because i thought of a funny word

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.

Am I understanding right that this has a low percentage chance of triggering on every tick

yes!

but will release a bunch of angry Enderman when it finally does?

no. you'll get teleported to where the enter pearl is and the potions will be shot towards you, killing you instantly.

open source perfume, cuz y'all stink

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

as far as i can tell this particular image is fake. and as far as i know pluton does not work like that.

https://www.reveddit.com/v/Piracy/comments/wojic3/does_the_idea_of_this_concern_anyone_else_why_is/ikclsct/#faithfully_engaged

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)