AFAIK the C implementation is a kernel module that's not shipped in stock Android releases. The WireGuard Android app uses that module when available, but otherwise uses wireguard-go.
Good knowledge here, was unaware of this feature of the app. Would there be any case of the app defaulting to the wireguard kernel module if it's not included by any OEM Android release? I would assume that means most users are actually running wireguard-go.
Yeah they could take some lessons from Plato. However, koreader works on everything. Android, Kindle, Kobo, PocketBook etc. Not just on Kobo like Plato does.
It took me some getting used to but it's not bad IMO. It's more that its conventions are a bit different from the commercial readers but that's not a bad thing.
Koreader is pretty intimidating at first but once you dig into its features and know what's going on, it's pretty easy to navigate into the menus. It require some time to invest at first, but after that it's really "set and forget" with some lovely features and power to customise absolutely everything. I love the statistics wallpaper that shows you how much you read previous 7 days, per day, and the fact that you can set every book parameter as default, making every epubs looking the same, something I've never been able to achieve with stock Kobo, where I absolutely hated beginning a new book and discover huge fonts, weird margins, and tiny line-spacing, that I had to set again.
I just installed it on my Kindle Oasis. No way to just replicate the Kindle view of all my books in a list regardless of directory, and the real killer was that it doesn't invert page turn buttons when the display is rotated. PRs welcome, I'm sure, but I had to give up on it.
Unless the author is insanely rich, they probably don't want to spend increasingly large amounts on hosting unless they have a way to make money back (even if it's just to break even).
e.g. the machine is a big box. You can "start" the machine once and "end" it once. When you "start" the machine it instantaneously teleports everything inside it from when you "end" the machine.
If you "start" the machine and break it before "end"ing it, nothing gets sent through, or there's a giant explosion, or the universe collapses, etc.
Alternatively, you can "receive" and "send" any number of times on the machine. But every time you "receive" you get a unique ID, and you can only "send" to that ID once.
Doesn't any scenario of time travel imply an unlimited amount of entities?
If you go back in time to observe (but not interfere with) your younger self, your younger self will get old and go back to that exact time too. So there will be an infinite number of your old selves observing your younger self.
Not to mention that travelling back also means adding matter to the universe.
...and how would you actually do that if we assume that your travel has added matter to the universe, rather than completed an iteration of a time loop that was happening there already?
Yeah, "interfering with" is open to interpretation. One might argue that you don't have to say "hi" to yourself to interfere with, and it is sufficient to be within the same light cone.
Hurricane Electric support a hidden primary as part of their free DNS nameserver service (do you actually want to expose your primary when someone else can handle the traffic?)
Yup, but it's a bit of a dance for bootstrapping, since they require you to already have delegated to them, but some TLDs require all NSes to be in sync and answer for the domain before delegating…
How relevant is this in the context of the mesh networks under discussion?
How resilient are those protocols to attacks on the integrity of the network, when most (or signicant part) of the nodes are controlled by a bad actor and deliberately operate in a mode that prevents the functioning of the network?
I think microsoft(github.com)/steam are the main dominant corpos dragging the world backward, well from an IPv6 point of view. I though steam had now IPv6 addresses.
Don't forget IPv4 is favoring hardcore centralized online services.
I'm in the same situation myself. It's quite frustrating, since 2 weeks I have been told that "the ticket is open and the technicians will take a look soon". Not sure if stuff like this has a low priority since IPv6 works and it's not considered a total outtage? In Germany there are laws to grant consumers compensation in those cases, but I'll see if this counts soon enough.
One problem with the solution in this blog post is that various endpoints block datacenter IP ranges entirely or make you go through various captcha hoops, but no good way around that. Same for common VPN providers.
Since I wanted to fix this for my entire home network I also had to do this on my router - in those cases it's quite beneficial to have a non-standard device like an Ubiquiti EdgeRouter, not sure how I would have set up all the Wireguard routing and nat rules on something like a FritzBox. The only downside is that the Router isn't powerful enough to handle a lot of connections, so I'll have to switch to IPSec which is supported by hardware offloading.
Fritzbox actually has some very nice GUI steps for configuring a VPN connection, intended for Fritzbox to Fritzbox connections but any compatible VPN will do. It also allows setting up static IPv4/IPv6 routes (Home Network>Network>Network Settings>Additional settings>IPv4 routes/IPv6 routes).
The biggest problem you'd probably run into is figuring out what kind of IPsec encryption configuration the router expects from the other side (Wireguard should be a lot easier but then you may run into hardware acceleration issues).
If you need to get down to it, you can also make a backup of the Fritzbox config file, edit the dump to manually configure the VPN endpoint, recalculate the checksum (there are tools for that), and re-import the config file. AVM has loads of config not accessible to the user that you can tweak that way, but they make it a bit hard to access so you don't accidentally brick your router.
Not sure about the situation in Germany, but in the Netherlands, if you have your fixed + mobile connection with the same ISP and there’s an outage on the fixed connection, you can ask for free mobile data until the outage is fixed.
Perhaps this would be an option to ask your ISP about.
The official client is clunky and being electron on the desktop doesn't make it better. Messengers live and die on UX. Since it's an open protocol alternative clients exist of course, but are often not feature complete. Things are often slow, especially with large group channels with lots of messages.
If you host a server yourself - it's great that you can! - you'll try the official implementation, synapse — ...and discover that it's a resource hog. Things got a bit better with some streaming sync protocol or something like that, but last time I looked it up that was still experimental and the server is still a chonker. Again, alternative servers exist, again the problem with feature parity.
I feel like the protocol is bloated as well, but I didn't dive into it too much to have a good opinion on that.
When choosing a messenger, I go to Signal for security, to IRC for simplicity and to Telegram for UX. I never thought "Oh let's use Matrix"...
Alternative clients feel like a broken promise to me, since features seem to be optional or implemented differently. You're basically stuck with Element if you want to be reasonably sure you're seeing what other people are.
Even the official clients are a little weird. Element X, their next gen super fast client released in 2023, still won't allow me to create a thread on iOS. It will let me put a caption on a photo though, but Element won't.
From time to time, I go and check if there's a stable non-Electron Matrix client available - Qt would be nice. Thus, I'm still on IRC. I've tried participating in some bridged Matrix channels, but the IRC bridges I've encountered were super annoying. All messages come from one user, the bridge. Very often, the same message gets repeated twice or more, for some reason. I guess Matrix has no limit on usernames, so some users have names that are more than a line long. It's all very tedious.
The QT client for Matrix is called Nheko: https://nheko-reborn.github.io/
There's a client in just about every toolkit. Just takes a cursory internet search...
Unfortunately, they still use libolm[1] for e2ee which is deprecated[2] and has known security issues[3]. The maintainers appear to not be interested in switching to the newer Rust-based library. Matrix argue that the timing channel attacks are not possible over a network, but the history of timing channel attacks argues that this very few protocols are this fortunate (most people thought timing attacks against TLS were impossible too, until someone bothered to attack them).
Yeah, although Matrix is theoretically about being an open protocol supporting a range of clients and servers, in practice it winds up being heavily skewed to just Element/synapse. I think this is partly because there is still too much churn in the protocol. A decent amount of that churn is improving things, but it still makes it too hard for average-joe devs to keep up with what's hip. I don't think there's much chance of a real menu of feature-rich clients until the protocol becomes stable. Unfortunately, I don't foresee that happening soon.
AFAIK none of that churn is around functionality that actually matters that much to end users, however. Certainly nothing as important as “working clients”.
There's also a really great Gtk client called Fractal from GNOME; it uses the same matrix-rust-sdk as Element X: https://gitlab.gnome.org/World/fractal.
Meanwhile the plan for Aurora (Element X Web) is to run it in Tauri or similar to placate all the Electron-haters: https://github.com/element-hq/aurora
There is also Neochat from KDE, not fully featured like Element and E2E Encryption still experimental the last time I checked, but it is a nice alternative if you want a non-Electron client.
> synapse — ...and discover that it's a resource hog.
I thought that, too, but at the very least it probably grows with usage. On my single-user-server, synapse currently needs ~100MB of RAM and does not consume CPU at all. It's not "slim" but I wouldn't call it a resource hog either.
reply