ShittyKopper

@ShittyKopper@lemmy.blahaj.zone

• ⁨Comment⁩ on ⁨Are there any guides, tutorials, or documentation for how to start building fediverse apps?⁩ ⁨⁨5⁩ ⁨months⁩ ago⁩:

  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:

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

  and depending on which ecosystem you’re targeting:

  • docs.joinmastodon.org/spec/activitypub/
  • join-lemmy.org/docs/…/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 it goes unused in the real world, 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.

• ⁨Comment⁩ on ⁨The Fediverse is Inefficient (but that's a good trade-off)⁩ ⁨⁨5⁩ ⁨months⁩ ago⁩:

  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 data (that could easily be re-fetched when needed) permanently, even if nobody has seen it in years.
  • If your’re lucky enough to be on instance software that backfills replies (GoToSocial, Iceshrimp.NET 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 anything beyond <500 active users is extremely overkill and you’d likely be suited with better 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 this hasn’t taken off enough to be important)
• ⁨Comment⁩ on ⁨The Fediverse is Inefficient (but that's a good trade-off)⁩ ⁨⁨5⁩ ⁨months⁩ ago⁩:

  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.

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

• ⁨Comment⁩ on ⁨How are Misskey and its forks doing?⁩ ⁨⁨5⁩ ⁨months⁩ ago⁩:

  All other devs jumped ship. I think both Iceshrimp and Sharkey were launched by former Firefish devs (at least one of them was, Iceshrimp being a former hard fork of Firefish which was quickly rebased into a more up-to-date Misskey soft fork

  Iceshrimp (Misskey fork) did not rebase their version of Misskey. They’re still based on the same Misskey v12 era code from Firefish and there’s no interest in significantly updating the JS version (as it’d make migration harder) now that the rewrite is well underway and (in my potentially biased opinion) quite promising.

  […] This is far from done which means it’s even farther from being daily-driveable.

  If you’re on a single-user instance, and can limit yourself to apps targeting the Mastodon API, it’s quite usable. The web frontend still needs a fair chunk of work, and moderation tooling required for larger instances are still not there yet. (But there’s enough to fend off spam)

  Iceshrimp was designed for stability which is also why a number of Firefish features had been kicked out. It itself is on maintenance for as long as it will continue to exist, which won’t be that long.

  The only features kicked out were, from what I remember, post imports (which were broken and leaked DMs (Sharkey’s on the other hand should work fine, as their implementation is unrelated to the Firefish one)), and the centered view in the web front-end.

  Sharkey used to be the king of features, but at the cost of reliability. Especially Sharkey’s Mastodon API implementation is infamously bad. The Sharkey community has been waiting for someone to step up and develop a completely new Mastodon API implementation for Sharkey for I don’t know how long.

  Sharkey’s Mastodon API was I believe more or less a direct port of the old Firefish one, which got replaced with the implementation from Iceshrimp some time after Firefish was handed off to Naskya (which may just be the only Mastodon API implementation on Misskey-based software that actually works). And, yeah, it’s not in a pretty state right now.

  Also, the Sharkey devs lost a whole lot of community support when they collected donations for a server for Sharkey purposes and then took the money to set up a Minecraft server. Make of that what you want.

  This is way too much of an oversimplification that I would plain remove this claim altogether. All I can say is that Sharkey/transfem.social has had a change of ownership and things are more or less resolved now.

  And then there’s CherryPick. AFAIK, it’s a Japan-based Sharkey soft-fork in which a whole lot of Misskey and Sharkey issues have been fixed; don’t ask me for details, I only know this stuff from hearsay. Basically, CherryPick is Sharkey in good. Or in better.

  CherryPick is older than Sharkey, and Korean (from what I know, anyway)