nickwitha_k

All good. I'm going to likely have bursts between the holiday, house guests, and other projects (ex. converting a "dumb" digital bbq thermometer into a Prometheus endpoint).

I've got a few things that I need to get done in the next few days (hopefully mostly sorted today) but you've got me rather intrigued with this as a puzzle. I'll see if I can get some time to sketch some thoughts out and maybe some high-level implementation of some bits in Python (it's faster to POC things).

A few quick thoughts:

• I think that an existing or novel protocol built on top of the Internet Protocol is likely the way to go. Following the OSI model, you can target Layer 4, with some simple stuff for higher layers. Client/Server (possibly the same binary) and associated automation should handle Layers 1-3 (translating between different carriers for Layers 1 and 2, and handling routing of data packets in Layer 3).

• Message routing strategies and their impact on OpSec is worth consideration. By this I mean: broadcast-only vs targeted-only vs both vs hybrid. All three have trade-offs.

Broadcast-only: Makes it harder to know the intended destination of the message. Conversely, by being routed to either all known addresses or all approved addresses, it can be more vulnerable to interception by a compromised endpoint.

Targeted-only: May be harder to intercept as the path that a packet takes should result in it hitting fewer potential endpoints. Conversely, some form of addressing is necessary to know, at the least, the next hop in transit. This makes tracing the intended endpoint, as well as network hops much easier (ex. running a traceroute).

Both: Gains the advantages and disadvantages of both approaches, depending on the which mode the data is transmitted in. Ensuring that data is transmitted correctly becomes important and has implications on the requirement of maintaining known good versions of the client/server software to avoid unintentional or malicious improper routing.

Hybrid: Could take many forms but the one that comes to my mind is a multilevel hub and spoke architecture (I'll draw this out). Basically, you end up having 2-3 "modes" for a client/server: hub, spoke, and endpoint. One or more client/servers operating in a hub "mode" act like traditional servers, kinda like a bulletin board, holding packets for local delivery or transmission to another hub. Client/servers in the spoke mode act as hops between hubs. Client/servers in the endpoint mode are the actual intended destination (this could be combined with the spoke mode). To protect endpoint identity, the destination could be part of the encrypted data packet allowing an endpoint to attempt to decrypt packets received from a hub locally, making it harder to know which endpoint a message is intended for. This does still require greater visibility of hub addresses for routing.

• Encryption of packets is vital. Supporting some modularity might be of value so as to allow use of simpler cryptography for PoC but, the protocol should ensure that it is possible to break reverse compatibility (normally NOT what you want to do for networking protocols but avoiding an "it's an old code but still checks out" situation would be more important).

• Amateur radio should be avoided both in PoC and hypothetical "production" use cases. The ban on encryption is insurmountable there and illegal use of encryption could lead to hightened visibility because the FCC, historically, does not fuck around with illegal radio signals. This means all wireless should be below 1W in the US, in bands that are legal for unlicensed use.

• Any physical layer that supports arbitrary data transfers should be possible. The implementation to support it would be part of the client/server. So, Bluetooth, 802.11, LORA, sneakernet, and many others could be hypothetically supported. Again, though, this relies on the protocol's stack to be and to understand it, either directly, or translated by another component.

• A web of trust may be a good approach for authentication and identity.

Indeed. I'd really suggest going for something based upon Internet Protocol, with any software that you need at endpoints to read and/or transmit. I might poke about at some ideas on the weekend (long holiday). What languages are you thinking to use?

Good call. You might try games like Tomb Raider or the first Prince of Persia reboot for movement accuracy.

ETA: Just to be absolutely clear, the "/J" was "jerk" like the old "circlejerk" subs, not serious. You probably know that but I'd rather be sure and not assume as I don't think being dicks to eachother makes the world a better place.

L2P n00b! /J

In seriousness though, I find the trackpads to be very useful for precision. Unfortunately, you have to build up the skill, like anything else. Work at it over time and you should get there. For practice, really depends on what you want to play. I'd suggest something that has a good system for criticals/headshots. Looks like Aim Lab might work on the deck, so maybe try that?

Oh that's interesting. I might suggest looking at implementations of IP Over Avian Carrier (IPoAC). And I do mean that seriously. The idea started as an April Fools RFC but some people have actually implemented it. Basically, just using a different physical layer.

The Senate is the trickier one to solve. It was not intended to be a proportional body originally. In the short term, the balance could be impacted by not treating politicians as above the law and actually prosecuting crimes that they have openly committed.

State legislatures effectively are only going to be fixed with a new court or voters overcoming the gerrymandering.

A plan to keep Republicans out of office permanently so that they can never wield this new power in retaliation (even Lincoln messed up on that one)

That one is simpler than it sounds. Restore the proportionality of the House of Representatives (broken by the Apportionment Act of 1911). The GOP is a minority party and would not have a chance if their voice wasn't amplified.

As long as you're using TCP (what SSH uses) or a similar protocol, you should be able to deal with a situation like that. You'd mainly need to ensure that your client and server are tuned to meet your needs. With TCP, every packet is considered important and if the receiver does not acknowledge receipt, the sender will resend.

I both love and hate this so much. The performance and recording is incredible but any super tech nerdy parody just causes me immense internal cringe. I couldn't make it more than a third of the way through that and I love working with K8S.

Absolutely the best kind of space crashloopbackoff.

... Hydrogen cyanide is literally what has been used to execute people in gas chambers and genocide during the Holocaust. The LC(Lo), the lowest recorded lethal concentration is 107ppm, resulting in death in 10 minutes. That's, objectively, far more dangerous than the respective material that firefighters were exposed to at Chernobyl. You don't want that in any appreciable quantity in the air around people that you want to continue living.