But do we need some kind of SSO layer with DID verification? All I need to prove my identity anywhere, technically, is my private+public keypair. As long as I hold on to this keypair, distribute it between apps/computers, back it up, I could log in anywhere on a federated platform and use it.

I hope we’re going to see key-based decentralized identity on ActivityPub at some point… Having accounts tied to instances is just not very robust or scalable.

Their first album indubitably is my favorite, obviously.

Most of the Koopa kids were named after musicians

• Wendy O. Williams from the Plasmatics
• Iggy Pop from Iggy Pop & The Stooges
• Roy Orbison, the songwriter and rock & roll legend
• Lemmy Kilmister from Motörhead
• Ludwig van Beethoven, obviously

YunoHost “packages” are just scripts. In the case of Lemmy, Lemmy_ynh’s install script actually fetches the Lemmy Docker image and extracts the files (including pre-built binaries) from it. And then it writes the config files to use the system Psql instance instead of a containerized version.

FWIW I don’t care how YunoHost installs the apps. Whether it’s fetching and running containers, or building from source, or grabbing binaries. As long as the apps work and the reverse proxy gets wrangled it’s fine with me. Just in this case refusing to run the Docker images directly is, at least momentarily, a problem for updating the app.

Well it is “working” for me. I’m using a YunoHost Lemmy 0.16.7 to type this comment :). But I agree there should be some kind of warning on the project that it’s only really partially working, and very outdated (thanks to the recent flurry in activity and changes).

Mainly though I wish YunoHost would just support Docker idiomatically and install Lemmy “as intended”. Yeah Docker can be a bit of a pain and it uses more resources, but it also has many real advantages like siloing the apps from the host system…

Were you able to migrate your database from an outdated YunoHost installation to a v18 Lemmy running in Docker? I like YunoHost but I’m considering the same move, as this old Lemmy version has a lot of incompatibilities and other issues.

The main blocker, at least so far, was Lemmy is designed mainly to use use Docker containers to version itself and its main dependencies like Postgresql, while YunoHost runs on the bare system. And since YunoHost is still on Debian 11 it only has access to Postgresql 13 while Lemmy now wants 15. This unfortunately is hard to resolve. YunoHost doesn’t want to introduce Docker, and upgrading the entire platform to Debian 12 is slowly happening but it’s a lot of work.

Because what Twitter really needs right now is less engagement.

If they really do shut off API access I’ll go into partial link aggregator withdrawal. My Lemmy instance still isn’t upgraded to the latest versions which are compatible with apps, so I don’t browse on my phone.

Yeah, this happened to Mastodon (aka the microblogging part of Fedi) also. I was on Mastodon on-and-off for years before the Twitter exodus, and it was a very different place back then. I can see why people miss the overall community on a platform before it became popular, but then I feel like ActivityPub gives us the tools to shape the communities we want, so we have to engage with it and be more selective than we were before.

Oh, yeah in that case I guess Lemmy propagates this information so other instances can show the “banned” information on a user profile.

Great, but all this activity also has a subtle downside. Lemmy.world is by far the slowest federating instance I see on the Lemmyverse. It typically takes hours for posts and comments to reach my instance.

Hopefully improvements to Lemmy will make federation faster and more efficient. Sidekiq seems to do a good job on large Mastodon instances.

I think some people reacted a bit too quickly to that sublemmy appearing though… Give admins some time to evaluate and resolve the situation before impulsively defederating an entire 6000-user instance.

Those must be bans from communities, I assume. A community is linked to a single instance so it can control who is banned. But banning a user from an instance is only meaningful on that single instance. At least that’s my understanding…

We’re just like the big commercial social media sites then. Sweet success!

I think a difference between email and ActivityPub-based social media is there’s arguably less of a need to have federation between any two servers. If you can’t email the government, your sister living abroad, or a client, that’s a big problem. But if you can’t follow a cat pictures account or your friend’s constant stream of baseball rants because the servers don’t federate it’s not quite the same.

If Meta becomes ActivityPub interoperable instances may or may not federate with them. Either way it’s not necessarily going to change my social media experience.

Sadly, I feel like the Fediverse, based on ActivityPub, was fundamentally designed wrong for scaling potential. I do like Fedi and I like ActivityPub, but I think instances should not have to be responsible for all of this:

• Owning user accounts
• Exclusively host communities
• Serving local and remote users webpages and media
• Never going down, as this results in users and content becoming unavailable

Because servers “own” the user accounts and communities it’s not trivial for users to switch to a different instance, and as instances scale their costs go up slightly exponentially.

I wish the Fediverse from the beginning was a truly distributed content replication platform, usenet-style or Matrix-style, and every instance would add additional capacity to the network instead of hosting specific communities or users.

I guess it’s a bit too late for a redesign now… Perhaps decentralized identifiers will take us there in some form in the future.