b3nsn0w

only two-letter tlds are controlled by specific countries. i forget who owns the specific tld for .world but i doubt they can pull this trick, there’s a lot of competition there

which B is hard?

Only reason I see is because of phones breaking. My current Mi 10T Lite was great for the first two years, then it started getting annoying. I can no longer use Wallpaper Engine because of a stupid system update, notifications started getting stuck, sometimes it has other minor annoyances. The hardware is still fine, there’s no reason this phone shouldn’t work, but it doesn’t. Xiaomi clearly wants me to go buy another phone.

So I did. Just not from them. My Fairphone should be arriving any day now. My friend already got hers, and she got me super excited for it.

i don’t think there’s an api endpoint for that yet. the database definitely stores it, it would be doable, but it’s not implemented yet in the backend

are you subscribed to any lemmy.world communities? you only get updates if you subscribe

i’d also recommend running lcs to pre-seed your instance, it’s a bit of a space hog but it makes things much easier to use

that would be something you do when registering a domain. you enter what you want and the thing tells you whether it’s available – or you can use one of the domain checker sites that do the same thing, or run a DNS query yourself and see if it resolves with NXDOMAIN (although that might be wrong, i’m not completely up to date on the details of this one)

I think it should go on the client, and the hash is pretty much a space saving measure. There are three options, as far as I see it:

1. Assign random colors every time a page is rendered. This could get confusing on repeat visits, but it would come with the added perk of ensuring the impostor has a low chance of hitting the same color as the person they’re trying to impersonate every time.
2. Assign random colors and save them on the client. This would probably balloon without an LRU data structure, but it could work.
3. Use the hash. This basically generates random colors in a predictable way, implementing #2 without having to store anything.

Given that Lemmy does a lot of reloads on navigation I don’t think #1 would work well. The hash is a quick and easy way around the complexities of other implementations.

And yeah, in theory the server could store the client secret, making the colors consistent across all devices of a user, but it has to be non-public info. If it’s public, an impersonator could target a specific person and find a collision that fools them in particular.

lol, yeah, that would crash any instance

(jokes aside, you’ll probably need to keep it somewhat low-res, and i’d also recommend cropping it to square. my instance uses a 128x128 icon)

i’m currently hosting an instance for about 20 users on a dual-core epyc-7002 based cloud vm with 2 gb of ram and currently a 50 gb ssd volume. memory tends to sit around halfway and total disk usage is 14 GB, of which it’s 4.5 GB for the picture server and 2.3 GB for the database for now, i’m monitoring both in case upgrades are needed. cpu usage is quite low, usually sits between 5-10% and never went above 25%. it was the highest during a spambot attack when they tried to register hundreds of accounts – speaking of, enable captcha (broken on 0.18.0) or set registrations to approve-only.

i’m paying about $10-15 per month currently, which includes a cache to keep the instance snappy.

holy hell

lmao just how powerful is your server icon?

yeah, the point is that if hyazinthe@feddit.de hashes to, say, blue, they can try to find a similar-looking username that also hashes to blue, therefore helping with the impersonation. if you hash a client nonce that’s different for everyone, you may hash to blue on my screen but green on yours, and there will be no relation between who hashes to which color on your screen or mine. the impersonator will have no way to guess if their name would match colors on either of our screens, and if we have, say, 25, colors, it will be a static 4% chance no matter what they do.

it already is though. you get stuff like “creator”, “mod”, or “admin” appended next to usernames, at least on the web ui (“creator” means op, idk why they worded it this way)

display names kinda run counter to this and I’m not certain they’re a good idea

i think they would be a good idea if they worked like they do on mastodon: you get the display name and profile pic displayed prominently, but you still have the full username displayed below, with the domain included.

damn, he was killing off subreddits before it was cool

i think this could be resolved by assigning a color to each user based on a hash. maybe people would try to find collisions there (i.e. specifically find usernames that get the same color as you), but if you do something like color_index = hmac(user_address, client_nonce) % color_count where client_nonce is unique to each client, it would be impossible to manipulate usernames to get a collision or even a higher chance at it.

https://pricefield.org for me. i’ve seen the move to lemmy, thought for half a second about my favorite fandom, and knew it had to happen.

it’s been a rougher ride than i expected but it’s hella exciting

you might wanna clean up your database there. at least purge anyone from the local_user table who doesn’t belong there so that they can’t log in. if you also remove all the relevant entries from person it will fix the displayed user count as well.

I’m gonna preface this: IANAL either.

There are also different legal bases for different kinds of data processing. For example, I’m pretty sure ensuring your site’s security counts as legitimate interest, and it’s pretty common that IP addresses are stored and processed as such. You don’t need to remove someone’s IP from your access logs just because they asked for it, because your interest in keeping your site secure for both yourself and everyone else outweighs their interest in the privacy of their data. Legitimate interest is the fuzziest of the six legal bases and it doesn’t help that advertisers have started attempting to qualify their BS as “legitimate interest” especially in consent forms (if they need your consent it’s not legitimate interest, it’s user consent, and they really should stop lying) but it still exists to keep things viable.

As a rule of thumb, if you’re storing data to provide a service you need to export or delete that data upon request, and if you’re doing anything over what’s strictly necessary for providing your service you need to ask the user about it. And you’re right, this applies to anyone whose instance is used by EU citizens.

Also, pseudonymous data still counts as personal data as long as the pseudonym can be linked back to personally identifiable information. You need to sever this link to comply with a deletion request.

yup, that sounds perfect

i can’t track down a non vendor-specific guide right now but if you just expose the same settings in config.env that you’d have in the lemmy.hjson file that should be more than sufficient to get an external service going