Stagenet XMR ID request | XMR.ID
get.xmr.id

The test for improved XMR ID sign-ups has concluded on stagenet and the form is now active for mainnet-registrations of “real” XMR ID’s at https://xmr.id.

With this, the parts of the sign-up that do not require human interaction got a boost - while nothing has changed for active XMR ID’s. The qualities of those are the same - regardless of when and how they were registered.

For those interested in the test’s findings, here’s a report for transparency.

If you’d rather be spared the details, feel free to head over to !xmrid@monero.town instead, where I publish tips and announce software aimed at making your Monero-life easier.

Sign-up Test Report

Three major issues were encountered and taken care of:

DNS outage

Our provider for the xmrid.com (secondary) domain experienced a partial service outage. For a couple of hours the DNS wouldn’t return any responses to queries.

Our internal monitoring reported the error at around 11 p.m. local time. Even though the primary domain xmr.id was unaffected, such issues are particularly stressful, as their resolution depends on a third party.

After resolution, the provider explained:

“It was an issue with some domain updates that got triggered by adding records.”

Spam detection

Some major email providers categorize messages from @xmr.id as spam, preventing further sign-up instructions from reaching the user.

There is the drawback of the new, form-based approach: Since you no longer message us first, your hoster doesn’t know that our response is desired email.

At the time, the best way to handle such a situation is to send us an email or message on one of the other channels mentioned in the description box at c/XMRID.

Emoji support

A user tested the form with an emoji username - thereby reminding us that this “edge case” hadn’t been automated by the time.

Adding emoji support demanded most of the resources since the test. It is now working with support for both, Unicode and Punycode submissions and as an added (internal) bonus it also led to establish a more efficient method for automated testing.

Onward

I have decided to leave the stagenet form active for the time being, so that developers and curious users have a playground for testing OpenAliases in Monero. Note that I will clean up names every once in a while.

So, if you want to try an emoji just enter a heart 🧡, an animal 🦅, a ninja 🥷🏿, some flag 🏳️, your favorite ᚱune or a simple (anti-)smiley 😡 into the username field when filling out the form :)

Independent of the topic of registrations, there’s an integrators guide around the corner. There are certain things that wallet devs can do to further secure XMR-ID use. Oh, and the guide will be accompanied by a tool for simplified Monero transactions that fans of “suckless” software are bound to love …

Finally, a big thanks to all the testers who participated!

(Note that none of the stagenet restrictions apply to “real” XMR ID’s from https://xmr.id.)

  • geterdoneOnagoradesk@monero.town
    2·
    7 months ago

    Consider this, there are no emails ever sent encrypted unless the user explicitly does/enables this, services such as protonmail claiming e2e is ridiculous because the keys do not belong to the user(e2e on chat clients the user installs on their own devices is actually productive in this sense because the keys are actually with the user even if they do not know this) they are held by the server owners thus no real security whatsoever if “the state” decides they want to read your emails for whatever arbitrary reason. This default method easily finds itself contributing to the data trove of not only marketing material but, surveillance being purchased by the american government in wholesale. This is of course being the tip of the iceberg.

    It would seem beneficial to the users if anonymity was maintained by randomly creating an “whatever@xmr.id”, then following that step and requiring the users send you their public PGP key so that you can by default encrypt the messages going to them. If you want to take it a step further, exclude yourself from the information shared by both parties by sending them a link or similar that requires them to submit their public PGP key to encrypt before anything happens and now you truly have no middle man other than bringing the 2 parties together.

    Our presentation of this may be a slightly bit convoluted but, the gist is keeping things random at the “signup” (not really a signup in so much as a random generation of whatever), then after that make it mandatory to encrypt the emails going out because you have no control over who can read what when it leaves you, especially when it is in plain text as a majority of emails are.