𝘋𝘪𝘳𝘬

Definitely seeing some people complain about the design changes

The great thing about Mastodon is, that you can freely chose what client you use. If you dislike the original client or web interface, just use Elk, Semaphore, Tusky, etc. whatever you prefer.

Daily reminder to defederate from and block threads.net (and optionally all instances that do not do the same).

Like Mastodon, but commercialized?

So wasn’t Google when they killed XMPP.

I cannot see anything bad here. Blocking an actively malicious actor should be the norm.

That’s just paid advertising.

I know about muenster.im which is a Mastodon instance specific to the city of Münster. There is also mastodon.hamburg for example.

Those are not local-by-default social media services, though. But I guess it’s easier to find an instance with a local focus instead of “Jodel but federated”.

Comment IDs are not unique between instances so you simply cannot change just the part after the @ to link to the same comment but accessing it from another instance.

You can always take the comment’s full URL and put in in the search field of your instance, this will show that particular comment in your instance so you can interact with it from there.

This is why this instance is so well. Thank you for all the hard work in reliberating the web!

Looking forward to Forgejo supporting it in the far future.

To me it feels it never lifted off since release in 2012.

So you want to centralize the decentralized nature of the Fediverse through a company running off venture capital?

This one. And 2-3 others that popped up in the federated timeline recently.

Is there a way - as a user - to block/ignore whole instances instead of only single communities?

If you see a way to simplify it, pull requests are always welcome

All components that are needed to run a Lemmy instance could be provided as single stack and the containers could be made configurable using environment variables (usernames, passwords, and DB locations). Database and reverse proxy should be handled completely separated from the “Lemmy containers” and the “Lemmy stack”. manually editing upstream files before composing the containers should be avoided.

Since I do not use MS GitHub I cannot help with issues, PRs, or anything else there, sorry.

multiple services

This is what I think about. While those 3 containers contain different programs: are they really different services and not just different components of the same service?

pict-rs, lemmy-ui, lemmy

Why can’t those be bundled? I need 3 containers and another database container just to have an instance. Also, none of those is easy to setup. All of those are messy and annoying and need me to fiddle with upstream files.

Containers should be reusable. None of those is reusable for anything else.

So more difficult installation is not a major concern.

In the long run this is where it will fail. Make it intentionally hard and annoying to setup will lead to people not setting it up.

Edit: Been there, done that, failed. Since then I always try to make my stuff as easy to setup and use as possible.

Last time I checked, it wanted me to modify multiple upstream files before composing the container and manually create directories instead of using Docker volumes – for multiple images.

Also the compose file contains a database and a reverse proxy for no reason.

Where’s the simple Docker container that does not want me to do that? Just deploy, set some environment variables, use one volume for persistent data and the sqlite database and that’s it?

Why is selfhosted Docker such a mess?

I wish clicking this link would actually show the context instead of just refreshing the page.