And just today with a comment by a world admin! Hopefully they’ll get it sorted soon.

Lemmy.world has been under repeated attack recently though, and the behaviors you’ve described match what I see when th service is down. You can see current status and the history of frequent incidents at https://lemmy-world.statuspage.io/.

To relate to your statement about what fails and how, I can say I’ve seen the failure-modes change as they adapt the setup, and it’s a more complex stack than other lemmy instances in order to deal with the attacks and large scale. It degrades in complex ways that are hard to fully reason about unless you’re pretty deeply familiar with how things are out together.

I suspect you’re seeing a combination of “lemmy world is broken sometimes”, “Cloudflare gives weird errors sometimes”, and “clients cache things or degrade to unauthenticated connections sometimes”. But in any case, seeing lemmy.world be flaky is not weird, it’s having a heckuva time.

It’s not guaranteed that every federated app integrates with every other federated app in a particularly useful way. You kind of need to take it on an app by app basis:

• Kbin and lemmy integrate very well. “Magazines” on kbin show up as communities in lemmy. You have almost certainly already read and responded to posts and comments from kbin users, and you may have subscribed to communities on kbin.social, the largest kbin instance. Interacting between the two is pretty much seamless.
• Mastodon and Lemmy integrate, but less completely. If you’ve seen a post full of #hashtags and with an @thecommunity@instance mention, that’s probably from a mastodon user. I’m not sure how a lemmy user can initiate contact with a mastodon user, but a mastodon user can at-mention a lemmy community as if it were a mastodon user and doing that will create a lemmy post. Comments on the lemmy post look like replies to the mastodon toot.

Other fediverse projects will interact in varying specific ways, and you need to figure each pair out individually.

The earth and sun and milky way are temporary. Like these things, the Beehaw defederation is ongoing and has no predetermined end.

I don’t think it is more complicated than, e.g a VPS provider or a SaaS platform and a customer that wants to have run a server online or a managed application.

That’s a very reasonable comparison, but to me the more relevant comparison is that of creating a commercial social media account or standard fediverse account today. This is much less accessible to users than that process, and also much more demanding on server admins.

I’d certainly be overjoyed to learn that I’m wrong and for this to revolutionize account mobility. But I don’t see volunteer server admins lining up to facilitate DNS delegation for fun or users lining up to pay VPS prices for commercial hosting of their own social media domain. The bar for simplicity and usability for me is quite a lot higher than I see this sort of approach evolving to provide.

Fair enough. The level of close coordination required between takahe server admins and domain owners seems to make domain migration at-scale somewhere between very expensive and simply prohibitive relative to self-service account sign up though. And I’m not sure I see a clear path to resolving that issue, though it’s certainly an interesting project even if it can’t deliver domain mobility at scale.

If you are not happy with the server, you just move to a different service and get your domain to point to the new server.

I’m just learning about takahe now, but it very much looks like domains are the remit of server admins, not users. Setting up a domain appears to require admin-privileges on the computer running takahe, not something that an individual user or non-admin group of users can do. So it seems to me that takahe doesn’t facilitate users controlling domains and improving mobility of domains between different servers controlled by different admins, but rather appears to be a tool for a given admin-team to segment their users and move them around among the group of servers they control.

I could very much be missing something here, this doesn’t seem to be a scalable approach to server mobility or a way to extricate yourself from an admin team you’re in conflict with.

Awesome feature. It’s great to see you thoughtfully trying to balance the community discovery problem with the federation overhead caused by mass subscription.

While I continue to favor and recommend manual subscription, I’ve bookmarked lsb and lcs to recommend to folks looking for automated approaches. I think they’re looking pretty good right now and seeing you proactively address feedback gives me faith that they’ll get even better.

I’m not experienced at cleanup, and I don’t think lemmony offers an undo. But if you used an account other than your primary… I think deleting that account will nuke its subs and you can start over. If I’m wrong, this may leave a bunch of orphaned subs with no user and no way to write an api-script to unsub.

In either case, I do recommend doing your automated subs on a different account and viewing them in all rather than directly subbing your main account to all that junk. It definitely give you more options for cleanup.

I think you more or less have it. Rather than saying no app can do everything, I’d probably frame it as different apps being optimized for different things. An app that tried to offer an optimized experience for everything is going to end up feeling like a bunch of apps bodged together anyway (basically like meta) because community stuff wants to looks different than microblogging stuff which wants to look different from photosharing stuff.

Of the 3 subscription bootstrappers listed in this thread, lemmony is by far the worst of them because it subscribes to EVERYTHING by default.

Lcs forces you to pick a number of communities to subscribe to, and the other one has default threshold heuristics that pick a limited number of active communities. Lemmony signs you up for the entire firehose of the threadiverse which both makes instances using it pretty bad fediverse citizens in terms of generating a 50x-100x the federation load of a “normal” single-user instance that subs maybe a hundred communities… and also exposes novice single-user instance owners to legal liability by subbing all the small under-moderated communities full of questionably illegal stuff.

I would recommend one of the better designed tools, and to review the resulting subscription list manually to ensure you’re not signing up for some sketchy stuff.