litchralee

some ominous comments stating that it is practically unmaintained (which is not true)

Objectively, I can see that the last commit to the default branch was in March 2026, and that the 10th newest commit was back in September 2025. Of these 10, 3 are new features and 6 are fixes and 1 is documentation. I also see in the issue tracker that no project developer replied to the two newest reports, which were reported 2 weeks and 2 months ago.

As a subjective opinion, the explanation that Conduit is essentially rock-solid and this doesn’t need much upkeep or commits, that is just not credible. The Git history shows fixes and new features, but at a rate that averages just one commit per month. And some of those commits are literally one-line changes.

But let’s suppose that the maintainers are uninterested in small UI or quality-of-life features, and only make changes when it crosses their threshold for what is “important” enough. That’s a choice, sure, but let’s see if that holds water. Here is the project’s response to an issue opened in January, with the response being in February that confirms a UI bug and schedules it for the next release.

That was three months ago. No updates. No mentioned branches or PRs or merges. All while this bug remains in place. And that’s understandable for FOSS project developers, for whom the project is not their day job.

But in any circumstances, the totality of the evidence does not inspire confidence, let alone a determination that Conduit is “rock solid”. And that’s even before looking at the code.

TL;DR: the premise of the question is wrong. Conduit is not maintained.

the original switch (as it looks good) which it turns out, does not really appreciate having to switch 230V instead of the 12V (or 24V?) it was designed for. I believe I can patch up the switch to work as designed, however I do want a better solution to switching the lamp on and off.

Please, please do not ever subject electric components to more than their rated voltage. Unless the switch has an overt label that says it is rated for: 1) 230 volts, and 2) AC, this is a recipe for tragedy.

I will briefly explain why, and then get to the suggestions. In a nutshell, components designed for 12 volts use closer spacing between conductors, premised on air’s natural insulating ability. Likewise, the insulation and plastic housings are designed to withstand that low voltage without becoming a hazard. But higher voltage means the spacing must be wider, the insulation thicker, and above 60 volts is when more strict regulation come into effect, because that’s the international threshold for where there is a serious risk of fatal electric shock.

As for DC vs AC switches, they are built differently to suppress arcs that form when opening the contacts. When a manufacturer gives the voltage rating for both DC and AC, it is often the case that one is substantially lower than the other, depending on which type of arcs they intended the switch to safely suppress. This is a worst-case rating, though, and a modern LED light bulb is unlikely to cause arcs (except when it’s dying).

To my knowledge, there are no common pre-built relays that provide their own low-voltage DC supply. Some relays do provide low-voltage AC (eg 24 VAC to control 240 VAC), but that doesn’t help you since that’s still putting AC into a DC switch.

However, a fairly safe approach would be to use a 230 VAC relay with the most common, safe power supply in the world: a USB phone charger. Provided that your relay can switch on 5 VDC, it should be easy enough to find a small USB charger that can be hidden inside the lamp, wired safely to 230 VAC, and that feeds 5 VDC to your existing tractor switch, which connects to the relay.

Given that your original problem was related to WAN upload performance, why did your investigation lead you to Ethernet flow-control? An ISP connection generally deals in packets at Layer 3 (“network”, eg IP) of the OSI model, whereas Ethernet is a Layer 2 (“data-link”) layer technology.

If there is a bottleneck at your WAN modem, then that will cause congestion at layer 3, but Ethernet flow-control can only deal with congestion that exists at layer 2. What has likely happened is that you have configured your gateway so that congestion at layer 3 is mirrored onto your layer 2 LAN. And if flow-control is enabled, then that would result in back-pressure propagating back to your VMs. Your VMs will then slow down their layer 2 rate, which conveniently forces the layer 3 traffic to also slow down.

This is an incredibly round-about and inefficient way to do traffic shaping. You should not configure a network so that L3 and L2 issues bleed into each other. A major consequence of using flow-control in this way is that it reduces the capacity of your LAN, even for traffic that isn’t going out to the WAN.

The customary approach for keeping L2 and L3 separate is to perform traffic shaping solely at the threshold where your LAN meets the bottleneck. This would be OpenWRT, since after OpenWRT would be the WAN (50 Mbps upload). OpenWRT would be configured with some sort of QoS feature so that certain L3 packets are selectively dropped.

You cannot do effective L3 traffic shaping without dropping packets. In fact, all competent L3 protocols expect dropped packets in order to slow down their data rate: SCTP and TCP have their own exponential congestion control mechanism, UDP simply accepts that some packets won’t make it through, and QUIC has its own mechanism as well. Simply put, all L3 protocols only understand one signal that tells them to slow down, and it is to drop a few packets. They will adjust accordingly, finding the stable equilibrium where traffic flows at the very cusp of congestion.

The Main reason for this problem seems to be the down-stepping of 10Gbit traffic to 1Gbit devices

This is a red-herring, for the reasons I’ve outlined above. With 1+ Gbps connections on your LAN, your L2 network is an order of magnitude faster than your WAN upload. It cannot be the case that a fast LAN makes a slow WAN slower. This is not RF impedance where step-transitions cause reflections; we are dealing in packet-switched networks, where queuing theory controls.

TL;DR: please try OpenWRT QoS instead

This is not a good idea: having to search means an implicit reliance on a search engine. Even with a trustworthy web search – and those are becoming fewer and fewer – why add this complication? The URL doesn’t even have to be large; it just has to be readable.

Even worse is when there’s an adversary: what would stop someone from buying getcontinuwuity.org but have it be pro-Big Tech propaganda, with tracking cookies galore, and then pay Google or Bing to put it at the top of the web search results?

Whereas in 2026, a URL is not confusing at all to include. People know what http:// or https:// mean. Even big brands might not own their own product name’s domain. This exact problem came up just six days ago: neowin.net/…/paintnet-can-finally-be-downloaded-f…

The whole point of marketing is to reduce the barriers for people to find something useful or valuable. Adding an accessibility barrier is antithetical to that objective.

This is the homeserver written in Rust, right?

A suggestion: wherever a QR code is included, the human-readable content should be included next to it. Not everyone has a QR code reader handy, or their reader has the bad habit of immediately opening links or apps. In this case, I see that it just goes to continuwuity.org and is benign, but others may be apprehensive at naked QR codes.

(there’s obviously an exception for QR codes that are intended to convey machine info, like TOTP codes)

Generally, assume the lower result unless explicitly stated otherwise. If there are two pins supplying 12vdc but only a single output rating, then the assumption should be that the PSU produces a single 12vdc rail, and the total of both pins is 5A max. It is implied (unless otherwise stated) that the full rating of 5A can be drawn from just a single pin.

From a marketing perspective, if there were multiple output rails, they have an incentive for them to list them out in detail. ATX PSUs for PCs do this.

From a safety perspective, it would be downright irresponsible to design a connector on a finished product (like this standalone PSU) that has a lower per-pin rating that what the supply can offer, so any decent pre-built PSU will not have per-pin limits that are lower than the total output limit of that group of pins. As a counterexample, ATX PSUs are a component in a larger product (a computer) and so individual pin limits must be adhered to.

Do you need analog? Would a digital logic probe be sufficient? Are you specifically looking for a desktop appliance or would a computer-attachment be acceptable?

Was this question also posted a few weeks ago?

In any case, what exactly are the requirements here? You mentioned encrypted journaling app, but also gave an example of burning a handwritten sheet. Do you need to recover the text after it is written, or can it simply be discarded into the void once it’s been fully written out?

If encryption is to protect the document while it’s still a draft, then obviously that won’t work for handwritten pages.

128 MB (1024 Mb) of RAM, 32 MB (256 Mb) of Flash

FYI, RAM sold to consumers is always in Bytes (big B); it’s only RAM manufacturers (and EEPROMs) that use the bit (small b) designation for storage volume, I think. If you’re using both to avoid any confusion, I would suggest the following instead: 128 MByte. No one will ever get that confused with megabits, and it’s the same style used for data transfer, which does still use bits: Mbit/sec.

I wish you the best of luck in your search.

I agree with this comment, and would suggest going with the first solution (NAT loopback, aka NAT hairpin) rather than split-horizon DNS. I say this even though I have a strong dislike of NAT (and would prefer to see networks using flat IPv6 addresses, but that’s a different topic).

Specifically, problems arise when using DNS split-horizon where the same hostname might resolve to two different results, depending on which DNS nameserver is used. This is distinct from some corporate-esque DNS nameservers that refuse to answer for external requests but provide an answer to internal queries. Whereas by having no “single source of truth” (SSOT) for what a hostname should resolve to, this will inevitably make future debugging harder. And that’s on top of debugging NAT issues.

Plus, DNS isn’t a security feature unto itself: successful resolution of internal hostnames shouldn’t increase security exposure, since a competent firewall would block access. Some might suggest that DNS queries can reveal internal addresses to an attacker, but that’s the same faulty argument that suggests ICMP pings should be blocked; it shouldn’t.

To be clear, ad-blocking DNS servers don’t suffer from the ails of split-horizon described above, because they’re intentionally declining to give a DNS response for ad-hosting hostnames, rather than giving a different response. But even if they did, one could argue the point of ad-blocking is to block adware, so we don’t really care if SSOT is diminished for those hostnames.