![](https://infosec.pub/pictrs/image/6974f67d-0f4b-4d85-8561-66763db949cf.jpeg)
disabling image uploads and image serving
I’m assuming this means death for image-based communities here on infosec (the hardware community comes to mind).
Will this impact images originating from (served by) other instances?
disabling image uploads and image serving
I’m assuming this means death for image-based communities here on infosec (the hardware community comes to mind).
Will this impact images originating from (served by) other instances?
The SEO-angle is interesting, thank you for the insight!
Trying to catch up on documentation, I’ve been implementing a couple of services during the past few weeks and need to write it all down before I forget.
I do this for every service I implement as part of my backup strategy, it tends to be easier to recover from a disaster when you have reproducible steps to follow.
I respect and understand your decision, I’ve personally had to block a few communities from that instance due to their problematic content.
For the sake of transparency (which I feel have been the spirit of this instance so far), could you give us some examples that led up to this decision?
I think everyone that selfhost their RSS-feeds have at one point or another thought “now what?”.
I have 3 recommendations that might help get you started:
feedspot is a great place to start to just discover what’s out there.
GitHub releases can be followed as RSS (atom) feeds. This is a great way to keep up with changelogs for services that you selfhost. For example, here is the RSS/Atom feed for Jellyfin: link
Do you listen to podcasts? These can usually be found as RSS-feeds and is a great way to get your daily dose of news on your morning commute.
“Tell me you don’t understand web apps without telling me you don’t understand web apps”