347 karma · joined June 18, 2025
It's a thing, it happens a lot and Lemmy instances have the same problems to fight. Unwanted porn in my eyeballs is sadly a not uncommon experience until you've put in effort to set up blocks and filters on your personal accounts. Peertube being explicitly video based is a natural target for porn pushers.
media.autoplay.blocking_policy
media.autoplay.default
I have mine set to 2 and 5 respectively.[1] https://ziggit.dev/t/migrating-from-github-to-codeberg-zig-p...
It would appear they listened to that feedback, swallowed their ego/pride and did what was best for the Zig community with these edits. I commend them for their actions in doing what's best for the community at the cost of some personal mea culpa edits.
In short: the complete lack of user-facing easy to use controls for data retention and culling in the Matrix (Element) clients is a deal killer for me. That painful experience taught me a lesson - now when I test something new, one of the first things I look for is "how do I extract from this thing?". I never want to go through my Matrix extraction pain again, so a personal life lesson was learned.
(a) the encryption between using a mobile and the webapp desyncs/breaks all the time, it just sucks. I mean you'll get "cannot decrypt" a lot, have to bounce back and forth and generally try and force it to re-sync properly again. Sometimes never worked at all. Lots of issues on GH over the years.
(b) as mentioned in this article, insane delays on new message notif and sending and receiving. Just logging in on the webapp every morning took minutes of some sort of mysterious sync process, often the mobile app had the same problems. The X stuff may fix this, we were pre-X.
(c) cleanup. There's no message retention set on matrix.org, when I wanted to extract and remove our past chats the process and experience was excruciatingly bad. It took tens of hours over several weekends of the webapp (mobile completely non-op in practice for this) polling and loading old content, just so I could select 100 at a time to delete and then it took an hour. Once I started culling back over a year or so, the loading got longer and longer and longer, until eventually it 100% stopped working at all to load old messages.
Signal and DeltaChat are far, far better experiences for one-on-one chats with friends & family. The Delta client is a bit UI/UX behind but not horrible; e.g. you can't correct a typo in a sent message in Delta, unlike Signal - because each msg is a unique gpg-encrypted "email" rather than a database object that can be re-manipulated.
Do these alternatives compare with just how well UWB serves regular, normal daily activity like this? Because to me, what I have is absolutely excellent in use with daily routine.
Tangent, a friend and I started using Delta Chat with a chatmail relay and it's incredibly friendly to get started, and hides the fact GPG tech is being used from the user; one can export a bundle of the key data as needed and easily copy the key profile to a second device over local wifi (I was impressed at how smooth it was).
Not that I've kept track, but Delta Chat's UX is probably the first easy, no-nonsense implementation of using GPG tech as a foundation but keeping it away from the user experience I've encountered (and liked). It has it's pain points but I mean it just works and my buddy and I chat all day over it using a public relay.
# Mullvad Unfiltered
forward-addr: 2a07:e340::2@853#dns.mullvad.net
forward-addr: 194.242.2.2@853#dns.mullvad.net
# Mullvad Adblock
# forward-addr: 2a07:e340::3@853#adblock.dns.mullvad.net
# forward-addr: 194.242.2.3@853#adblock.dns.mullvad.net
As mentioned in the default unbound config, the "#" is not a comment when used in the value, it's used for TLS checks. I followed this simple blog post from years ago: https://www.jwillikers.com/dns-over-tls-with-unboundAs 9.9 returned an IPv6, I tested with AAAA records just now - 1.1/8.8 respond with 4x IPs, 9.9 only 1x so it mirrors the A records in spirit.
Edit: in case useful to someone reading, right now I have an IP assigned out of this block:
NetRange: 172.32.0.0 - 172.63.255.255
CIDR: 172.32.0.0/11
NetName: TMO9
NetHandle: NET-172-32-0-0-1
Edit edit: in the network record is a link to the self-reported geo data, I missed that. Comment: Geofeed https://raw.githubusercontent.com/tmobile/tmus-geofeed/main/tmus-geo-ip.txtWhile testing, I was using Google and Cloudflare as well, and started noticing something - Quad9 does not return all A records listed for a domain, the same way Google/Cloudflare do.
dig -t A google.com @8.8.8.8 +short (6x IPs)
dig -t A google.com @1.1.1.1 +short (6x IPs)
dig -t A google.com @9.9.9.9 +short (1x IP)
This gave me a weird feeling; I get there's a lot of DNS geo magic and 8.8/1.1 serve 2 different subnets, and 9.9 a third. But... where did the other 5 expected IPs from Quad9 get off to?The paradigm itself has been in package managers since DEB and RPM were invented (maybe even Solaris packages before that? it's been a minute since I've Sun'd); it's not the same as NPM, a more direct comparison is the Arch Linux AUR - and the AUR has been attacked to try and inject malware all year (2025) just like NPM. As of the 26th (5 days ago) uploads are disabled as they get DDOSed again. https://status.archlinux.org/ (spirit: it's the design being attacked, pain shared between AUR and NPM as completely disparate projects).
More directly to an example: the Linux kernel package. Every Linux distribution I'm aware of runs a kernel package post-install script which runs arbitrary (sic) commands on your system. This is, of course, to rebuild any DKMS modules, build a new initrd / initramfs, update GRUB bootloader entries, etc. These actions are unique outputs to the destination system and can't be packaged.
I have no data in front of me, but I'd speculate 70% (?) of DEB/RPM/PKG packages include pre / post install/uninstall scriptlets, it's very common in the space and you see it everywhere in use.
The next, next big thing would be the Chatmail relays[1] supporting JMAP based servers (right now it's Dovecot) and this new targeted push extension for faster notifications without battery drain on mobile. I can see how the Fastmail mobile client will benefit from this RFC as well (it's already incredibly battery efficient, thanks to the team).