Yeah, but does that mean, (supposing they are different machines), a package is installed on both computers? On the client and the server? It sounds redundant, and pretty strange if and that's indeed what happens. I will read eventually the docs and find out myself, but it's gonna take 2-3 hours to dig out documents.
> if you care to understand the code you are running and you are THAT concerned about security it can be an excellent aid toward peace of mind.
Elisp can be more difficult to review that Rust. It is much more difficult to hide malicious pieces of code, inside a Rust program that in Elisp. Elisp is pretty powerful as many lisps are, but you can write Emacs modules in Rust. See ubolonton's project on github. I tested it at some point and it works.
>if you have a lots crypto assets
If i had crypto assets, (which i don't), then the correct way to organize money units, tokenized pieces of housing, tokenized pieces of cars, a thousandth of a car for example, is to use an identity which can create children identities, and each child identity can be revoked on demand by the root identity or the parent identity. Then you only really have to keep secure the root identity, everything else is revocable.
Dont take it as advice, but I think the deamon will handle the macro business, so in that sense you are connected to a compromised remote machine.
> Elisp can be more difficult to review that Rust.
Im not a rust programmer, so to each their own I guess. To me it is pretty easy to spot weird lisp code while rust is a headache to me. However as far as I know rust also has macros and unsafe options. Im also wary of anything that markets itself as "safe" because overconfidence is enemy of safety
The point about crypto assets is that you dont normaly use an editor to interact with it (or any full blown computation) and security is pretty straighforward. However if you are developing a software product it is less straighforward. You will use an IDE, probably some third packages, etc. Lots of ways something can go wrong