no

there is no “use case” here

Like having some portals or borders which lead to the next server

you don’t need federation to do that though… the server could Just™ send a packet to the client to redirect it to another server. minecraft for example already has this functionality and nearly all “large” servers make use of it.

honestly all use cases people think of for federated (in the AP way) game servers just feel like an attempt to cram federation as a buzzword anywhere they can think of “because its the next best thing trust me”, similar to many other bubbles (NFTs, AI)

i don’t blame them honestly. there’s no real point to having activitypub federation in a game beyond silly experiments like this. (the low latency needs of a game would absolutely require a different protocol at the very least, even if federation made sense which i doubt)

yeah no i seriously don’t see how that one actually helps anything. maybe for the odd self hoster it could make sense but realistically it’s way too under-defined (but then that’s the norm for ap, sadly)

let’s say lemmy implemented it. ok. what now? my current account is still under lemmy.blahaj.zone. i still can’t move to some other instance without changing my account’s id and breaking all the existing object ids. i can move my posts between instances (or perhaps connect multiple instance software to the same actor, though a generic C2S server can in theory accomplish something of that sort without needing to alter other instances communicating with mine) but my identity is not any more portable than without it.

actor relative ids requires everyone to anticipate being portable and set their account up with it from the very start. maybe the existing account migrations can be used to one-time migrate a non-portable account to a portable one, but you’re still required to host your own account on your own “identity instance” yourself, and you are more or less stuck on that identity instance if it ever goes down without you sending the same account move activity we already have out. it’s not as simple as taking an account from one instance and moving it to another.

https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md is imo better at accomplishing the goal, and unlike relative URLs it has real existing implementations proving it’s viable in the first place. but it has it’s own downsides as well (severly limiting domain block effectiveness for authorized fetch enabled instances, no key rotation afaict, …)

as a side note, don’t get too hyped up by feps. they have no power over anything and an existence of one does not mean anything for the future of the protocol. implementations are still the only ones making the final call on how the protocol actually functions (because real governance and “spec compliance” is anywhere between doesn’t exist and being actively hijacked by threads via swf), and the only implementation that actually matters in terms of protocol improvements is mastodon.

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)

id argue none of those are fun topics you can joke about but “memes as a form of outrage” (aside from, like, two) which is already a problem (see all the political memes on any of the meme communities for countless examples) we do not need to encourage imo

to be fair there isn’t that much about the fedi in general that you can meme about. the closes you can get are in jokes but:

a) lemmy doesnt have them because this place is uncreative and only serves as a dumping ground from memes from other places when they aren’t bickering about politics
b) in jokes of different parts of fedi do not translate well just because they share a protocol, given the extremely little overlap on people here
c) they’re not really “fediverse memes” just because they happened in the fediverse, are they

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.