cross-posted from: https://monero.town/post/3097215
If you are anything like me, you much prefer a good CLI over clicking around in a GUI.
Now, with Monero it’s never “fire up, issue transaction, exit”.
Catching up on a week’s worth of blocks can mean a long wait - especially if there are anonymity networks between you and the node.
If you decide to cope by leaving the CLI running, you find your tx-notes gone after a reboot. Less recent versions would even loose your sync level. Uff.
You could make it a habit to follow your
set_tx_noteup with asave, but that’s not ideal.XMRPC
To tackle the issue for myself, I’ve started to write XMRPC, a POSIX-compliant shell script that allows you to interact with
monero-wallet-rpc.This way you can have the RPC continuously syncing in the background and interact when necessary.
In fact, XMRPC takes care of launching the RPC and also creates a wallet if you happen to be starting from scratch.
The tool is aggressive in that it doesn’t require user confirmations. If you tell it to
transfer, it will try to do just that - with whatever fee or delay the official Monero client suggests at the given moment.It can be launched interactively as seen in the image or as “one-shot”, where only the command passed as argument is executed (e.g.
./xmrpc.sh balance).Support for labelling transactions has yet to be added, but some parts of XMRPC have already been powering the OpenAlias-service XMR.ID successfully for a while.
You can check out this first version, tagged 0.1.0-beta, at https://xmr.zone/sxmo-onfire/xmrpc.
That’s I nice little quick tool.
Your xmr.id service, that’s just a central directory right? So not really censorship resistant in any way?
Thank you!
XMR.ID is two domains from separate registrars (Indonesia and Canada), ran from two different nameservers (providers in Iceland and Nevis).
Then, with a third party entity (not me), users get an independent monitoring account (USA) that alerts them directly in case of unexpected changes.
As far as DNS is concerned, this is as censorship-resistant as it gets. Nevertheless, I am constantly evaluating new technologies that could be added into the mix to fortify this further in regards to both, censorship resistance and security.
Working with what is there, for example, since you get one
username.xmr.idand anotherusername.xmrid.com, my tools will query both and compare the results. A match will be stored locally. Next time you want to send to the same recipient, all three locations will be compared. Devs of any wallet can decide to do the same.The ideal scenario, security-wise, is when you give somebody your XMR ID in-person and glance at their screen for the peace of mind that it resolved to your destination (and then they persist it in their local Monero client’s address book).
Personally, I have both, the full Monero destination and my XMR ID, printed on my business cards. A sender can enter the short ID and check if it turned into the long destination on-screen. (Why no QR codes? Most people do not know how or are not set up to scan with their PC’s, so non-mobile users would be left out.)
That’s a “quick” response that turned out a bit longer than expected - If you see any potential for improvement, shoot :)
I’ll be happy to look into any promising suggestions!
Well, I think you’re right, when it comes to DNS that’s as decentralized as it gets, and I’d say this is better than adding a ton of complexity trying to integrate solutions from other blockchain networks. A lookup table it has to be somewhere.