visual representation of addresses and hashes

[andi-apeunit]

Introduction

In this issue I’d like to give you a short introduction to the topic of address and hash visualization and I’d like to ask you to take part in a discussion on how we could implement and style this idea for our æpps and components.

Purpose

The general purpose of visually representing some address or hash is that we want—and also need—something easily knowable or human-readable when it comes to comparing one thing with another. It’s supercilious to ask our users and developers to compare 32 bytes of Base58-hashed information, especially in some risky situation like making a transaction with lots of funds.

Identicons

We already are using one type of hash visualization in the means of identicons. I think we are using the same identicons as Ethereum-Wallet, which is—if I’m not wrong—a modified version of blockies, namely this one.

GitHub introduced their identicons in August 2013. I still think—after quite some years and also lots of research—they are the most beautiful and functional identicons out there, especially when it comes to different sizes and accessibility—think of all sorts of color vision deficiency.

Another approach towards human-readable address and hash representation is some kind of mnemonic user name. Status, for example, is using a formula consisting of adjective adjective animal which is generated from some script(s) located here. There’s also git mnemonic which can be used for creating ”speakable, rememberable translations for git ref hashes”, though I’m not sure if it’s mnemonic.

Lately, I found one GitHub Pages hosted blog by GitGub user barro which uses four GitHub-like identicons as article identifier … this is also a very smart concept, as the possible amount of unique identicons is probably smaller than the amount of possible æternity addresses. And it looks terrific!

References

The Ethereum Improvement Proposal repository includes some rather current and active issue concerning Feedback on “ETH Avatar Standard” Direction which we maybe should have an eye on.

Good read on Inclusive Avatars via UX Collective on Medium, and another good article concerning Placeholder Avatars in general.

IdentiAddress, a proof-of-concept Chromium/Chrome extension for displaying Ethereum addresses with colored backgrounds. Each background color is defined by hexadecimal color derived from 2–6 characters of the address.

One interesting creative project is Hashworms by Raphaël Bastide, which you would maybe want to check out via Beaker Browser, or just have a look at that screenshot.

There’s some more—more or less interesting and/or serious—approaches to identicons which I’d like to share with you and at least write them down somewhere. Avity, identikon, monsterID, Robohash, pagan, Alien-Avatar Generator, FlatHash, The Identicon package, Vanillicon

Conclusion

I think—in regards of very lots of use cases and different languages, deficiencies, devices, et cetera—we should offer two approaches for our users and developers.

The first approach would be using either one or more images in the style of GitHub’s identicons. Using more of those images, like GitHub user barro for article identifiers, make up beautiful and unique, simple and compact “words” made from special glyphs. We could even create a typeface for this purpose instead of using image or vector files.

The second approach would be using 2–4 mnemonic words with some specific formula, either adjective adjective animal, or adjective color orb, or … please feel free to propose something, maybe æternity related.

Thanks for reading and happily commenting.

[dadaphl]

Can you give us the gist of your references please. I don't find the time to read all this things.

| Placeholder Avatars

In general we should be aware that we are not trying to solve a avatar problem

We are trying to come up with a validation mechanism.

| GitHub ... identicons ... they are the most beautiful and functional identicons out there

We should be careful with personal æsthetic preferences. Not saying its not valid, just here its a very opinionated subject. In my opinion Github's Identicons look pale and boring.

I can not find any source that supports the claim that Github's identicons are the 'most functional' ones . Did I miss it or does it not exist? We should not make decisions based on assumptions. Again, sorry if I was just to impatient to find it.

| ... human-readable address and hash representation is some kind of mnemonic user name.

We have to be careful for many reasons: Most users have encountered mnemonics before in relationship to personal secrets (master private key). We have to make sure that we are not sending mixed signals to users regarding what looks like secret and what looks like sharable information. Maybe we scare users not to share information displaying mnemonic user names because they are afraid to loose their private key. Worst case we educate them to feel save to share their private key mnemonic, because they have shared similar looking information several times before.

We have to make sure that collisions are rare and that tiny differences in public keys create completely different mnemonics.

And most important: It has to be hard (complex, expensive) to generate similar looking addresses with the same mnemonic.

| https://github.com/ethereum/EIPs/issues/928

Discussion in EIP928 seems to be quite developed, yet ongoing. Could you give us a gist of the current state?

| Hashworms

Difficult to differentiate even for me who has perfect sight

| GitHub user barro for article identifiers

What is that?

| IdentiAddress

Seems to disturb the visual flow and grabs a lot of attention in the demo screens. I guess it will be difficult to satisfy designers if their apps will be littered with so many colours.

[andi-apeunit]

We have to be careful for many reasons: Most users have encountered mnemonics before in relationship to personal secrets (master private key).

You’re right about some relationship to secrets, though I wouldn’t ultimately generalize that. Maybe it’s just a matter of wording? Maybe the term “mnemonic phrase” is counter-intuitive, maybe it should be “mnemonic secret”.

Also, though I don’t think the word “mnemonic” is the problem here, we don’t have to call the mnemonic usernames consisting of formula adjective color orb—for example—“mnemonic usernames” … maybe we call them “user identifier” … maybe even “public user identifier” … and in the best case, which we should aim for, “unique public user identifier”.

We have to make sure that we are not sending mixed signals to users regarding what looks like secret and what looks like sharable information.

As written above. Plus it’s a matter of length, I suppose. Compare a three-word user identifier with a twenty-four-word secret phrase.

Please correct me if I’m wrong, but I think to remember that secret phrases are always displayed in lowercase, by design. If true, maybe we could display unique public user identifiers in uppercase.

Maybe we scare users not to share information displaying mnemonic user names because they are afraid to loose their private key. Worst case we educate them to feel save to share their private key mnemonic, because they have shared similar looking information several times before.

That’s, both, not what we want. And I’m pretty sure we can get this right with unmistakable wording and design (by which I mean hierarchical structure and visual appearance).

We have to make sure that collisions are rare […]

Let’s aim for “impossible” …

[…] and that tiny differences in public keys create completely different mnemonics.

Definitely.

And most important: It has to be hard (complex, expensive) to generate similar looking addresses with the same mnemonic.

Yes. And also we’re using an identicon. So it’s three layers of security, by which I mean complexity and expensiveness to generate three items—address, identicon, public user identifier—almost identical to the items they should look alike.

[davidyuk]

Is it possible to use names in AENS instead of identicons? Probably identicons is actual only in the case of signing by a device without connection to the internet (like AirGap or Ledger).

[andi-apeunit]

Is it possible to use names in AENS instead of identicons? Probably identicons is actual only in the case of signing by a device without connection to the internet (like AirGap or Ledger).

In my opinion we should always—if not impossible for reasons—display identicons as graphical identifier plus the unique personal (mnemonic) user identifier or, if registered, the AENS name.

So yes, we should—if there’s one registered—display the AENS name, though instead of the unique personal (mnemonic) user identifier and not instead of the identicon.

[drhus]

I've been working on a similar implementation for Hash (and general purpose large identifier) Visualization, but in addition to recognizability, a capacity to describe and transmit both online and via voice channels. I've shared an introduction here https://ethresear.ch/t/wallet-shape-address-human-friendly-visualization-of-wallet-address-momcode/3482

and you can check out the test-lab >> http://momcode.io/lab