An optional field was added to the userdb to allow storing birthdate. That’s it.

The systemd project merged a pull request adding a new birthDate field to the JSON user records managed by userdb in response to the age verification laws of California, Colorado, and Brazil.

This is the same record that already holds basic user metadata like realName, emailAddress, and location. The field stores a full date in YYYY-MM-DD format and can only be set by administrators, not by users themselves.

An optional field in the userdb JSON object. It’s not a policy engine, not an API for apps. We just define the field, so that it’s standardized iff [sic] people want to store the date there, but it’s entirely optional.

–Lennart Poettering

https://itsfoss.com/news/systemd-age-verification/

I haven’t had time to build out or promote the community, so there’s only one post right now, but this would be perfect for !totallylookslike@dubvee.org if you had a side-by-side image.

I mean, if you’re not shitting your guts out after drinking a glass of tap water, then it’s clean enough.

Pure water tastes like…nothing. The minerals and such give it the good, crisp taste.

That said, my water is so hard it has comparable calcium to a glass of milk.

Added :) I also disabled the “Create Post” button if the community is on a defederated instance even though, technically, you can still post to your instance’s local copy (it just won’t federate).

Edit: This only works one way. i.e. it can only know if your instance is defederated from the community’s. If the community’s instance is defederated from yours, there will be no indicator because there’s no way to do it without a remote lookup which is both unreliable and inefficient at scale.

You mean like if there’s a community called !cats@example.com and your home instance no longer federates with the instance example.com?

If so, I’ll add that to Tesseract as it sounds useful.

My friend got me into it, and it was the first and only MUD I ever really got into. So kind of loved it by default. I tried out a few others but never really got very far beyond the first few levels in each.

Beyond that, it was intuitive as far as MUDs went, had a massive world and lore, and was well “modded”.

I used to play the crap out of A.V.A.T.A.R. As of a few days ago, it was still alive and active.

avatar.outland.org:3000

You can use telnet or a more capable MUD client. I used to use zMUD back in the day, but it hasn’t been developed since 2008. The last time I sat down and played, I used Mudlet.

Dude! Awesome! On all fronts, awesome.

Agree. Which is why I get so irrationally annoyed when sharing a good piece of journalism that’s not catering to ad-clicks and the peanut gallery here grabs their torches and pitchforks while shouting “PaYwALL!” despite me posting the gist of the article in the post body (enough to get the gist but not the full article for copyright reasons). It’s one of several reasons why I don’t even bother anymore.

Like, good journalism costs money. That money’s gotta come from somewhere if you want good journalists to be able to eat and keep doing what they do.

When I put the IMEI into OP’s tool, it said I had to go through TMobile to [bootloader] unlock it since it was a retail model.

TMobile said the phone “wasn’t in our system” and couldn’t provide either SIM or bootloader unlock codes.

but I can only find it t-mobile locked. I can carrier unlock it myself

Careful with that assumption. I bought a TMO-locked OP Nord N200 thinking I could do that but even after using it on my account for a year, they say “it’s not in our system” and it remains carrier-locked. Basically when it hit the secondhand market, it was removed from TMO’s system and they have no record of it and cannot carrier-unlock it (or that’s the story that was told to me by 3-4 different people within TMO).

but will I be able to access the boot loader

Depends if you can carrier-unlock it.

https://service.oneplus.com/us/search/search-detail?id=op588

I disabled local thumbnail generation almost a year ago, and things mostly work the same.

Instead of a local thumbnail image URL for things like news articles that get posted, it will be the direct URL value from the og:image metadata from the source. Usually those load fine, but sometimes they don’t due to CORS settings on their side. Probably only 1-2% of posts have issues, though.

For image posts that come in via federation, (memes, pics, etc), the thumbnail image URL is the same as the post URL. In other words, you’re loading the full res version in the feed. Since I use a web client that has “card view”, this actually works out better, visually. YMMV whether that’s a drawback for you.

The only pitfall is that you will lose thumbnails for image posts if an instance goes offline or shuts down.

I’m sure that does increase load slightly on other instances, but no more than if the remote instance had image proxying turned on. And the full-res version always has to load from the remote instance (even if you have local thumbnail generation enabled). All in all, I’d say the additional load is acceptable given the benefits of disabling local thumbnail generation.

To mitigate that, in my case anyway, I have my own image proxy/cache in place. My default UI is Tesseract and it’s configured with the image proxy/cache on by default… (I think I saw that Photon is also working on something similar). In this configuration, the first person to scroll past a remote image fetches it directly (via the proxy/cache) and it’s now available locally in the cache for everyone else (unless they’re connecting with a different client that doesn’t use Tesseract’s proxy). Granted, I shutdown my instance last year and it’s just now a private testbed for development, but when I did have daily active users (plural), the proxy cache helped.

Now the only images my instance stores are ones that are uploaded locally.

Why did I disable local thumbnails?

• I closed up my instance and didn’t want potentially problematic thumbnails being generated while I wasn’t actively modding it
• Generated thumbnails go in, but they don’t go out. There’s no way to clean them up later other than the ephemerally generated ones (if someone requests a version in a custom size, for example)
• Increasing storage costs. Like, I’d be scrolling the feed and see some of the dumbest shitposts while constantly thinking “Ugh, this is costing me money to store a copy”.

Orphan Black: Live

I prefer sans-serif fonts visually but prefer serif for readability. So I use Atkinson Hyperlegible which is a mish-mash of both.

And bonus meme:

Atkinson Hyperlegible is my new jam. I’m dyslexic and it helps tremendously even though that’s not its primary goal. It also looks a lot better than OpenDyslexic which I used to use.

Loaded “Hyperlegible” onto my Kobo, the reader app on my phone, and set it as the default font on my desktop environment.

Also added it as an option in Tesseract UI (which I swear I’ll be releasing “soon”).

Probably “copying” Apple’s iNoun naming convention?

Ran into a hiccup while trying to reproduce (there seems to be considerable lag between adding a domain to the filter list and the federation processes handling it), but now that I was able to reproduce it successfully, I made a bug report: https://github.com/LemmyNet/lemmy/issues/6320

Granted, I don’t think the instance level URL filters were meant to be used for the domains of other instances like I was doing here. They’re more for blocking spam domains, etc.

e.g. I also have those spam sites you see in c/News every so often in that block list (e.g. dvdfab [dot] cn, digital-escape-tools [dot] phi [dot] vercel [dot] app, etc) , so I never see/report them because they’re rejected immediately.

During one of the many, many spam storms here, it was desired by admins for those filters to stop anything that matched them from federating-in instead of just changing the text to removed on the frontend. So it is a good feature to have. Just maybe applied too widely.

Though I think if a user edited their own description to include a widely-blocked URL (no URLs are blocked by default), they’d just be soft-banning themselves from everywhere that has that domain blocked.

If a malicious community mod edited their communities’ descriptions to a include a widely-blocked URL, then yeah, that could cut off new posts coming in to any instance that has that domain blocked (old posts and the community itself would still be available).

All of those would require instances to have certain URLs blocked. The list of blocked URLs for an instance is publicly available from the info in getSite API call, so it wouldn’t be hard to game if someone really wanted to. Fortunately, most people are too busy gaming the “delete account” feature right now 🙄.

The person who cross-posted it was probably definitely from your local instance.

You only ever interact with your local instance’s copy of any community, even remote ones. If the community is to a remote instance that is either offline or since de-federated, there’s nothing that prohibits you from interacting with it*. Because lemm.ee is no longer there to federate out the post/comments to any of the community’s subscribers, only people local to your instance will see it.

*Admins can remove the community and, prior to it going offline, mods can lock it. But if an instance just disappears, you can still locally interact with any of its communities on your instance; the content just won’t federate outside your instance.