

there is no “use case” here
there is no “use case” here
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 :
and depending on which ecosystem you’re targeting:
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 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)
no