litchralee

For an example of where constant current sources are used -- and IMO, deeply necessary -- we can look to the humble LED driver circuit. LEDs are fickle devices, on account of their very sharp voltage-current curve, which also changes with operating temperature and is not always consistent from the factory. As a practical matter, the current through an LED is what predominantly controls the brightness, so constant current sources will provide very steady illumination. If instead an LED were driven with a constant voltage source, it would need to be exceedingly stable, since even a few tens of millivolts off can destroy some LEDs through over-current and/or over-heating.

For cheap appliances, some designs will use a simple resistor circuit to set the LED current, and this may be acceptable provided that the current is nowhere near overdriving the LED. Thing of small indicator LEDs that aren't that bright anyway. Whereas for expensive industrial LED projectors, it would be foolish to not have an appropriately designed current source, among other protective features.

In a nutshell, voltage incompatibility is generally more damaging than current mismatch, typically in a frightening or energetic manner. Many Americans tourists find this out when they bring their 120v AC hairdryers to an overseas hotel with 230v AC power. If there is only room for one number to be emblazoned on an outlet or plug, it should be the rated voltage, first and foremost.

For current protection, we've had thermal fuses since the 1890s, and thermo-magnetic circuit breakers since the 1940s. There are even more fancy transistor-based current protections available for industrial equipment that can shut off extremely fast. In a sense, protection against over-current has basically been solved, in the scenarios where there's enough of a risk of humans or property.

Whereas voltage mix-ups still happen, although consumer electronics are now moving to automatic voltage detection (eg an 18v electric drill battery charger refuses to charge a 12v battery) and through actively negotiated power parameters (eg USB PD). And even without human error, under- and over voltage transients still happen in residential and commercial environments, leading to either instant damage or long-term product degradation (eg domestic refrigerator motor drive circuits).

It should be noted that a current starvation scenario, such as when an ebike is current-limited per regulations, does not generally cause a spike in voltage. Whereas in a voltage starvation situation, resistive loads will indeed try to draw more current in order to compensate. Hence why current protection is almost always built-in and not left to chance.

Firstly, I wish you the best of luck in your community's journey away from Discord. This may be a good time to assess what your community needs from a new platform, since Discord targeted various use-cases that no single replacement platform can hope to replace in full. Instead, by identifying exactly what your group needs and doesn't need, that will steer you in the right direction.

As for Element, bear in mind that their community and paid versions do not exactly target a hobbyist self-hosting clientele. Instead, Element is apparently geared more for enterprise on-premises deployment (like Slack, Atlassian JIRA, Asterisk PBX) and that's probably why the community version is also based on Kubernetes. This doesn't mean you can't use it, but their assumptions about deployments are that you have an on-premises cloud.

Fortunately, there are other Matrix homeservers available, including one written in Rust that has both bare metal and Docker deployment instructions. Note that I'm not endorsing this implementation, but only know of it through this FOSDEM talk describing how they dealt with malicious actors.

As an aside, I have briefly considered Matrix before as a group communications platform, but was put off by their poor E2EE decisions, for both the main client implementation and in the protocol itself. Odd as it sounds, poor encryption is worse than no encryption, because of the false assurance it gives. If I did use Matrix, I would not enable E2EE because it doesn't offer me many privacy guarantees, compared to say, Signal.

Obligatory mention: !keming@lemmy.world

Approximately 90% of people are right-handed. In European writing systems that use quills and pens, reading and writing left-to-right makes more sense so that you can hold the pen in your right hand and drag it rightward, not into the ink you just laid down.

In East Asia, before writing on paper was a thing, they wrote using inscribed bone, but then eventually moved to vertical wood boards, bound together by string. Each character on the board would be ready from top-to-bottom, and then move to the next board. The most logical choice for a right handed person is to stack the wood pile on their left, and use their right hand to draw the next board to meet their gaze, then set it down on their right. Later, this bundle of wood boards would become paper scrolls, but would still be pulled from left-to-right by a right-handed scholar.

For this reason, the historical writing system common to China, Japan, Korea, and Vietnam for centuries was read right-to-left (because instead of scrolls, we have pages, which can be moved easily). But the native Korean script is left-to-right, as is the modern Vietnamese script. And Chinese and Japanese in the 20th Century switched to left-to-right. And yet, Japanese books are still ordered "backwards" so that the title page is what Westerners would say is the back of the book, and manga panels are read from the right side toward the left.

So far as I'm aware, this means some Japanese signs can be rendered left-to-right (modern), right-to-left (historical standard), and top-to-bottom (traditional). The only orientation that's disallowed is bottom-to-top (although vertical news tickers will do this, so that readers see the text from top-to-bottom).

It all boils down to right handedness, but it depends on whether your hand is moving, or the text is moving.

Are ham radio operators in the EU able to use LoRa radios and be exempt from duty cycle limitations?

Admittedly, I haven't finished reflashing my formerly-Meshtastic LoRA radios with MeshCore yet, so I haven't been able to play around with it yet. Although both mesh technologies are decent sized near me, I was swayed to MeshCore because I started looking into how the mesh algorithm works for both. No extra license, since MeshCore supports roughly the same hardware as Meshtastic.

And what I learned -- esp from following the #meshtastic and #meshcore hashtags on Mastodon -- is that Meshtastic has some awful flooding behavior to send messages. Having worked in computer networks, this is a recipe for limiting the max size and performance of the mesh. Whereas MeshCore has a more sensible routing protocol for passing messages along.

My opinion is that mesh networking's most important use-case should be reliability, since when everything else (eg fibre, cellular, landlines) stops working, people should be able to self organize and build a working communications system. This includes scenarios where people are sparsely spaced (eg hurricane disaster with people on rooftops awaiting rescue) but also extremely dense scenarios (eg a protest where the authorities intentionally shut off phone towers, or a Taylor Swift concert where data networks are completely congested). Meshtastic's flooding would struggle in the latter scenario, to send a distress message away from the immediate vicinity. Whereas MeshCore would at least try to intelligently route through nodes that didn't already receive the initial message.

Very interesting! Im no longer pursuing Meshtastic -- I'm changing over my hardware to run MeshCore now -- but this is quite a neat thing you've done here.

As an aside, if you later want to have full networking connectivity (Layer 2) using the same style of encoding the data as messages, PPP is what could do that. If transported over Meshtastic, PPP could give you a standard IP network, and on top of that, you could use SSH to securely access your remote machine.

It would probably be very slow, but PPP was also used for dial-up so it's very accommodating. The limiting factor would be whether the Meshtastic local mesh would be jammed up from so many messages.

I've only heard bits and pieces of this from friends and strangers through some specific events so far

Can you tell us what bits you've heard, so that we don't have to give redundant answers?

The catch with everything that implements E2EE is that, at the end of the day, the humans at each end of the message have to decrypt the message to read it. And that process can leave trails, with the most sophisticated being variations of Van Eck phreaking (spying on a CRT monitor by detecting EM waves), and the least sophisticated being someone that glances over the person's shoulder and sees the messages on their phone.

In the middle would be cache files left on a phone or from a web browser, and these are the most damning because they will just be laying there, unknown, waiting to be discovered. Whereas the techniques above are active attacks, which require good timing to get even one message.

The other avenue is if anyone in the conversation has screenshots of the convo, or if they're old-school and actually print out each conversation into paper. Especially if they're an informant or want to catalog some blackmail for later use.

In short, opsec is hard to do 100% of the time. And it's the 1% of slip-ups that can give away the game. As an example, we need only look to the group chat of cabinet members using a knock-off Signal client to discuss military operations, and accidentally added the editor of The Atlantic to the chat. Although that scenario highlights more PEBKAC than SIGINT.

Sadly, I'm not familiar enough with Nginx Proxy Manager to know. But I would imagine that there must be a different way to achieve the same result.

BTW, when I read "NPM", I first think of Node.JS Package Manager. The title of your post may be confusing, and you might consider editing it to spell out the name of Nginx Proxy Manager.

I'll take a stab at the question. But I'll need to lay some foundational background information.

When an adversarial network is blocking connections to the Signal servers, the Signal app will not function. Outbound messages will still be encrypted, but they can't be delivered to their intended destination. The remedy is to use a proxy, which is a server that isn't blocked by the adversarial network and which will act as a relay, forwarding all packets to the Signal servers. The proxy cannot decrypt any of the messages, and a malicious proxy is no worse than blocking access to the Signal servers directly. A Signal proxy specifically forwards only to/from the Signal servers; this is not an open proxy.

The Signal TLS Proxy repo contains a Docker Compose file, which will launch Nginx as a reverse proxy. When a Signal app connects to the proxy at port 80 or 443, the proxy will -- in the background -- open a connection to the Signal servers. That's basically all it does. They ostensibly wrote the proxy as a Docker Compose file, because that's fairly easy to set up for most people.

But now, in your situation, you already have a reverse proxy for your selfhosting stack. While you could run Signal's reverse proxy in the background and then have your main reverse proxy forward to that one, it would make more sense to configure your main reverse proxy to directly do what the Signal reverse proxy would do.

That is, when your main proxy sees one of the dozen subdomains for the Signal server, it should perform reverse proxying to those subdomains. Normally, for the rest of your self hosting arrangement, the reverse proxy would target some container that is running on your LAN. But in this specific case, the target is actually out on the public Internet. So the original connection comes in from the Internet, and the target is somewhere out there too. Your reverse proxy simply is a relay station.

There is nothing particularly special about Signal choosing to use Nginx in reverse proxy mode, in that repo. But it happens to be that you are already using Nginx Proxy Manager. So it's reasonable to try porting Signal's configuration file so that it runs natively with your Nginx Proxy Manager.

What happens if Signal updates that repo to include a new subdomain? Well, you wouldn't receive that update unless you specifically check for it. And then update your proxy configuration. So that's one downside.

But seeing as the Signal app demands port 80 and 443, and you already use those ports for your reverse proxy, there is no way to avoid programming your reverse proxy to know the dozen subdomains. Your main reverse proxy cannot send the packets to the Signal reverse proxy if your main proxy cannot even identify that traffic.