this should be fixed now, Cloudflare was detecting a potential vbulletin exploit

afaik this is not something that we were involved in, but the lemmy devs implemented a threshold to exclude instances with 30% or more monthly active user share.

i don’t mind it, better distribution of users across instances is good.

seems like youtube is using incorrect geoip mapping.

our server is hosted in finland, but afaik google is running their own geolocation stuff, which i think is less accurate than other geoip databases.

ah, that makes sense. anaustralianphotographersnotesbook is 34 characters and the limit is at 26 currently.

I believe some alternative UIs/mobile apps have this feature but it’s not available in the default Lemmy interface.

I believe this was due to rate limits being misconfigured. Should be fixed now.

I believe this was due to rate limits being misconfigured. Should be fixed now.

we all do this in our spare time. if we had set working hours then it would be easy to do so, but even then I don’t think a daily maintenance window would be necessary when we don’t changes that frequently.

we believed this change to be doable without downtime, otherwise we would’ve announced it ahead of time.

this change is important for our anti spam measures, especially if we tune it to be more aggressive, which might increase the false positive rate, it is important for us to be able to distinguish removed pms from user deleted pms in case we need to restore them at a later point.

due to that it’s a somewhat urgent change that was fit in where we had spare time available to allow us to continue improving our efforts to combat pm spam effectively.

(mobile) apps could do this, but I don’t think browser based apps would be able to. the generation of YouTube thumbnails works by requesting the html content of the YouTube page and then extracting a metadata component from it, where YouTube provides the actual preview image as a link. browsers set restrictions on how you can interact with other websites for security reasons and I dint think this would be allowed there.

manually this is of course doable, but it’s rather cumbersome.

yeah, the actual issue was the replaceable schema being applied, which starts with

DROP SCHEMA IF EXISTS r CASCADE;
CREATE SCHEMA r; 

and then continues here and here

we’re aware of this issue and already looking into it

at this point i don’t know what people are even talking about, anyone signing up since saturday should get an email if their account was denied.

it’s also impressive how many people can’t follow simple instructions.

local server time is UTC.

time in UTC is included both in the title and the post itself.

incremental backups might also be something worth looking into

we’ve been observing that in a few cases over the last weeks, we’re planning to investigate this in more detail after updating lemmy and our db to a newer version, as that should already improve performance in a few places.

the monitoring alerts aren’t very accurate currently, we’ve been looking into improving them to better reflect reality, although that’s still in progress

why shouldn’t the email filter be enabled?

I have to admit that it doesn’t do much for us, as the support emails we have in sidebars and posts are unfortunately federated to other instances where they’re not getting obfuscated and will be crawled there, but we do have contact emails on the website. I’m currently not aware of any issues caused by that.

glad to at least have confirmation that this isn’t just us, thanks!

do you remember whether this has still been happening while lemm.ee was on lemmy 0.19.5 or 0.19.8?

that has nothing to do with this issue.

we’re not running any modifications that would impact caching and we don’t have any custom caching logic. we’re only caching what lemmy/lemmy-ui return as cacheable, which suggests that the issue is likely in one of those services, however, i couldn’t find it in either one.

it’s also rare enough that it’s extremely difficult to troubleshoot, as we see people report this maybe once or twice every few months but without any useful information that would allow us to look into this further than trying to find bugs in related code just from the general symptom of seemingly invalid cache.

additionally, the impact of this should be fairly low, as, unless this somehow impacts private messages as well, no data would be returned that isn’t already otherwise public. with this seemingly “just” being a caching issue, there is also no risk at impersonating other users.

nonetheless i agree that this should not be happening in the first place, even if it’s rare and the impact appears limited.