Indeed it does, I was talking about adding a checkbox tagged “Only transfer blocked users” instead of having to click through some menus.

Sure, the code is completely client-side, simply clone it. If you’re running into CORS problems due to the file:// scheme Origin of opening a local file, simply host it as a local temporary server with something like python -m http.server .

This is due to the two ways most instances validate Cross-Origin requests:

• Sending Access-Control-Allow-Origin: * (allow all hosts)
• Dynamically putting your Origin into the Origin header of the response to your requests by the backend

file:// URLs will result in a null or file:// Origin which can’t be authorized via the second option, therefore the need to sometimes host the application via (local) webserver.

The whole point of this being a web app is to make it as easy as possible for the user to download/modify/transfer their user data. LASIM is a traditional app the user has to download and install, similar to a script this web app was developed to replace due to being too difficult to use for some users.

The import functionality targeted by this API is additive and my app features a built-in editor to add, modify or remove information as the user sees fit. To achieve your stated goal, you’d have to remove anything except the blocked_users entries before importing, which my app supports, I added a wiki entry explaining the workflow in more Detail.

I may add options to modify the exported data in some ways via a simple checkbox in the future, but I wouldn’t count on it. I’m always open for pull requests!

• “display_name” ​
• “bio” ​
• “avatar” ​
• “banner” ​
• “matrix_id” ​
• “bot_account” ​
• “settings” ​
• “followed_communities” ​
• “saved_posts” ​
• “saved_comments” ​
• “blocked_communities” ​
• “blocked_users” ​
• “blocked_instances”

The export/import functionality is, yes. This implementation uses the same API endpoints, but the main reason for this existing:

An instance I was on slowly died, starting with the frontend (default web UI). At least at the time, no client implemented the export/import functionality, so I wrote a simple script in Bash to download the user data, if the backend still works.

Running a script can still be a challenge to some users, so I wrote a web application with the same functionality.

It’s a bit redundant if we’re talking about regularly working instances, but can be of use if the frontend isn’t available for some reason.

The export/import functionality is, yes. This implementation uses the same API endpoints, but the main reason for this existing:

An instance I was on slowly died, starting with the frontend (default web UI). At least at the time, no client implemented the export/import functionality, so I wrote a simple script in Bash to download the user data, if the backend still works. Running a script can still be a challenge to some users, so I wrote a web application with the same functionality. It’s a bit redundant if we’re talking about regularly working instances, but can be of use if the frontend isn’t available for some reason.

Good call, I’ll add some explanations, kinda forgot about those.

EDIT: Done.

Yep!

Great synopsis!

The cool thing about GrapheneOS: It provides basically all the comforts and usability as any Android (stock) ROM minus some compatibility issues with a portion of Google Apps and services (Google Pay doesn’t and probably will never work, for example) while providing state-of-the-art security and privacy if you choose to utilize those features. A modern Pixel with up-to-date GrapheneOS, configured the right way, is literally the most secure and private smartphone you can get today.

Protocols to authenticate email senders exist, e.g. SPF and DKIM. Mostly an enterprise thing, though.

It still amazes me that the security concept against spoofing a number for phone calls and SMS is “Please don’t do that, it’s illegal”.

Pretty much anything, from your Desktop Environment to the simplest application running in the background, will have way more of an impact than pretty much any semistatic website. I’m curious, what do you mean with “in the optimal way possible”? Are you constantly maxing out your RAM already, and if so, how?

I prefer Lemmy for:

• actually engaging with content (commenting/posting/voting) instead of simply consuming. By the time the API restrictions came around and the ads/bots started to dominate, it felt pointless to engage on Reddit any more.
• the positive parts of the federated and FOSS nature. Choose an instance, build your own, use or build any client you want to, federate or defederate whoever you want.

I prefer Reddit for:

• getting info/recommendations on things. The knowledge base is magnitudes larger than anything Lemmy can offer atm. Also, due to the centralized nature, it’s so much easier to search for something on Reddit.

Lemmy’s got some problems and I can’t stand the interinstance drama, also, due to the decentralized nature, some instances can’t keep up or the admins don’t care any more, so whole communities can essentially be held hostage or simply die until a toolset to move a community from one instance to another (and propagate the change properly to the Fediverse) becomes available.

Just be mindful when restarting automatically, as some OS offer. It’s neat not having to remember to manually restart every few days, but your pending notifications will get lost and, depending on your setup, your cellular/network connections will not automatically reconnect until you login.

Well, this tells us that more privacy minded people with a background or interest in technology tend to be more present/engaging on Fediverse platforms. Not really surprising.

While this is certainly a cool concept, local voice assistants like this are currently a novelty. Cool to play around with, though!

You can expect around 5 seconds processing time to start generating the response to a basic question on a very basic model like Llama 3 8B.

For context, using Moondream2 (as recommended) on a RasPi 5, it takes around 50 seconds to process an image taken by the Camera and start generating a description.

Without trying to sound condescending, you’re basically rambling surface level half-truths about encryption, companies, legal pressure and proprietary components like IME.

Firefox Sync is open source. It gets encrypted locally. If for some reason someone is interested in your bookmarks, they won’t be able to get them from a Firefox Server. They’ll simply grab them from your local system in their unencrypted state.

Yes, most currently relevant CPUs for consumers, implement something like the IME or the AMD equivalent of it. This can be a source of paranoia, but, unless you are expecting to be the target of state actors, not a very logical one.

It honestly sounds like you read some technical keywords, looked up their definition on Wikipedia and drew your own, wrong conclusions.

The problem isn’t necessarily “stuff not sent over vpn isn’t encrypted”. Everyone uses TLS.

Never said it was. It’s a noteworthy detail, since some (rare) HTTP unencrypted traffic as well as LAN traffic in general is a bit more concerning than your standard SSL traffic contentwise, apart from the IP.

For this to be practical you first need a botnet of compromised home routers

This is more of a Café/Hotel Wi-Fi thing IMO. While it may take some kind of effort to get control over some shitty IoT device in your typical home environment, pretty much every script kiddie can at least force spoof the DHCP server in an open network.

Interesting read.

So, in short:

• The attacker needs to have access to your LAN and become the DHCP server, e.g. by a starvation attack or timing attacks
• The attacked host system needs to support DHCP option 121 (atm basically every OS except Android)
• by abusing DHCP option 121, the attacker can push routes to the attacked host system that supersede other rules in most network stacks by having a more specific prefix, e.g. a 192.168.1.1/32 will supersede 0.0.0.0/0
• The attacker can now force the attacked host system to route the traffic intended for a VPN virtual network interface (to be encrypted and forwarded to the VPN server) to the (physical) interface used for DHCP
• This leads to traffic intended to be sent over the VPN to not get encrypted and being sent outside the tunnel.
• This attack can be used before or after a VPN connection is established
• Since the VPN tunnel is still established, any implemented kill switch doesn’t get triggered

DHCP option 121 is still used for a reason, especially in business networks. At least on Linux, using network namespaces will fix this. Firewall mitigations can also work, but create other (very theoretical) attack surfaces.

The problem with Nix and its forks, imho, is that it takes a lot of work, patience, time and the willingness to learn yet another complex workflow with all of its shortcomings, bits and quirks to transition from something tried, tested and stable to something very volatile with no guaranteed widespread adoption.

The whole leadership drama and the resulting forks, which may or may not want to achieve feature parity or spin off into their own thing, certainly doesn’t make the investment seem more attractive, either.

I, too, like the concept of Nix very, very much. But apart from some experimental VMs, I’m not touching it on anything resembling a production environment until it looks to like it’s here to stay (predictable).