You can check every website there via the domain.

I’m really not sure about that being inexpensive. The files will grow and the list of people to follow usually grows as well. This just doesn’t scale well.

I follow 700 people on Mastodon. That’s 700 requests every interval. With 100-10000 posts or possibly millions of interactions in each file.

Of course you can do stuff like pagination or something like that. But some people follow 10000 accounts and want to have their timeline updated in short in intervals.

Pulling like this is usually used when the author can’t sent you something directly and it works in RSS Feeds. But most people don’t follow hundreds of RSS feeds. Which reminds me that every mastodon profile offers an RSS feed - you can already do what you described with an RSS reader.

But only once. If an account doesn’t post/interact for a year, it doesn’t cause any traffic. With your approach, I constantly need to pull that account’s profile to see if something new showed up.

So I have to constantly check all files from everyone I follow for new entries in order to have a working timeline?

Auch erst kürzlich entdeckt, Game Changer

The answer to the first two questions are helm charts. They are collections of parametrized yaml files and the most popular way to install things into k8s. You just need one config file for each helm release (values.yaml).

If you want to go declarative with gitops rather than imperative, check ArgoCD or flux.

Thank you for the info. I thought the *key instances and maybe pleroma already had it and wanted to see how it looks. But I’m almost exclusively using an app anyways so I should be looking how Tusky implements it anyways.

I wonder why there’s no preview for the quote posts in that article. And I need to check if Tusky plans to implement it…

Edit: Tusky does https://codeberg.org/tusky/Tusky/issues/5181

Die müssen nichts kapieren, denen entsteht überhaupt kein Schaden. Die wissen, dass sie beim nächsten Mal dann auch gedeckt werden. Das bisschen Image interessiert da nicht groß.

Das ist so gewollt. Wer da nicht mitmacht, wird rausgemobbt.

That’s just how it is. You can only see favs if the post is on your instance, or if the fav is from your server. A fav from a remote instance to another remote instance is not known to your instance.

It’s the same on mastodon.social but not as noticeable because it’s so big

Es ist eben nicht einer, der 99 schlecht macht. Es sind die 99 die die Fresse halten oder sogar lügen damit der eine davon kommt.

Im Rolladen, also direkt am Fenster?

Keine Sorge, vom Arbeiten ist noch niemand reich geworden.

It’s not that difficult. You can create a second VM from the backup with a few clicks and move the necessary data with scp.

I’m sure they are glad they are protected from the free information war and that you, in true solidarity, are decidedly not helping them to gain free information access. 🫡

Not wrong, just saying that every Vaultwarden client is a backup basically since they cache everything and it doesn’t expire.

Klingt ja viel zu sinnvoll

Wtf are you talking about, nobody is climbing anywhere. By running snowflake, you are offering a piece of infrastructure that other people can use, it’s not specific to the Iran. They can’t install it themselves if the local internet is censored, that’s the whole point of this.

It’s the best we have. What’s your specific problem with it?

Ofc! But since this is the selfhosting community I figured the Docker thing would be more practical. My laptop with the browser isn’t always on.