* If you need a "real" terminal emulator, you can use something like vterm (https://github.com/akermu/emacs-libvterm/).

* If you need to be able to attach/detach Emacs sessions on remote machines, you can use something like dtach or abducto (https://www.brain-dump.org/projects/abduco/).

Unfortunately, there are cases where you simply can't just "re-implement" something. E.g., because doing so requires access to restricted tools, keys, or proprietary specifications.

To prevent malicious Wi-Fi clients from attacking other clients on the same network, vendors have introduced client isolation, a combination of mechanisms that block direct communication between clients. However, client isolation is not a standardized feature, making its security guarantees unclear. In this paper, we undertake a structured security analysis of Wi-Fi client isolation and uncover new classes of attacks that bypass this protection. We identify several root causes behind these weaknesses. First, Wi-Fi keys that protect broadcast frames are improperly managed and can be abused to bypass client isolation. Second, isolation is often only enforced at the MAC or IP layer, but not both. Third, weak synchronization of a client’s identity across the network stack allows one to bypass Wi-Fi client isolation at the network layer instead, enabling the interception of uplink and downlink traffic of other clients as well as internal backend devices. Every tested router and network was vulnerable to at least one attack. More broadly, the lack of standardization leads to inconsistent, ad hoc, and often incomplete implementations of isolation across vendors. Building on these insights, we design and evaluate end-toend attacks that enable full machine-in-the-middle capabilities in modern Wi-Fi networks. Although client isolation effectively mitigates legacy attacks like ARP spoofing, which has long been considered the only universal method for achieving machinein-the-middle positioning in local area networks, our attack introduces a general and practical alternative that restores this capability, even in the presence of client isolation.

house of lords

https://caselaw.nationalarchives.gov.uk/ewhc/kb/2025/3063#lv...

However, you do need to avoid call-process (spawning blocking processes) as much as possible. Also, my experience with TRAMP has been pretty awful due to the fix for https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12145 (literally: TRAMP blocks all of Emacs while waiting on a network connection).

> Maybe in my retirement I will end my career by helping to make emacs + EXWM multi threaded. I am guessing that is a daunting project, but it sure would be fulfilling.

This isn't fixable with threads, unfortunately. The issue is that:

1. Emacs e.g., launches a process with call-process. This blocks EVERYTHING (including other threads). 2. That process wants to map the window but EXWM can't respond to this request because Emacs is blocked. 3. The call to call-process never returns because the process can't create its window.

You'd have to fix Emacs to not block everything in cases like this, but that has been tried before: https://mail.gnu.org/archive/html/emacs-devel/2023-06/msg007...

At this point, I think the right answer is to write a minimal out-of-process window manager (e.g., a wayland compositor).

1. During normal operation, it would behave like EXWM and ask Emacs how to manage windows, etc. 2. In special cases (TBD), it would behave autonomously, acting like a standard floating window manager until Emacs becomes responsive again.

Worse, GitHub (back in 2016 and 2018) would mark a recipient as "unavailable" after a single bounce, refusing to send any more notifications to that address. They since improved the situation and their support was actually very helpful and responsive here, but it's pretty clear that modern SMTP senders have an expectation that recipients will be "always online" that didn't exist when the protocol was invented.

I guess I get why it works that way (avoids some issues with domain expiration) but... honestly, I'd rather have my domain name in control. Even after registering my own rotation key, I'm still at the mercy of the centralized PLC directory.

Unfortunately, it looks like it's not possible to migrate to a web DID without starting over.

From my reading of your blog post, it sounds like the DID is the ultimate authority and not my domain name, which sounds like a pretty big problem for user portability.

- My handle is something _I_ control. I can make it point at a different PDS at any time.

- My DID is something my PDS controls.

I could solve this by indirecting through a web DID under my control, but there's no recommendation anywhere in Bluesky's documentation. Is that something everyone needs to do to ensure real identity portability?

edit: I'm not sure this CAN be solved without running a PDS given that I can't use my own keys. What am I missing here?

However, now that I think about it, the fact that "unauthorized" apps can still be installed via ADB exception may cover this?