I’ll do the classic compare and contrast. I’ll briefly describe how we all share addresses today because, well, it’s not impressive to say the least! And then I’ll intro Addresso sharing.

Every active user will recognize the following sad sequence:

• Copy the address ➜ Paste the address ➜ Describe the address ➜ Note the particular network(s) as needed.

And as someone who’s received such information, you’ll also recognise:

• Copy the address ➜ Find some place to store it ➜ Paste it ➜ Copy the description ➜ Paste it ➜ Copy the network(s) ➜ Paste it.

This.

Is.

Seriously.

Clunky.

It’s a bit easier for NS names such as alice.eth because the name corresponds to an address and network(s), but it's not much easier. You still need to keep tabs on which Alice this is, if indeed it’s a particular Alice at all. And you might make a little description of the NS name some place so you can make sense of it at a later date. As the truism goes … identity is actually in the eye of the beholder.

To share:

• Click “Share” ➜ Click “Generate share link” ➜ Sign the share ➜ Copy the share link

To accept:

• Click the link ➜ and then one of:

  • Add to your Addresso Book

  • Create an Addresso Book and add to it

  • (You can also just copy the information if that floats your boat)

If the signing address is already in your Addresso Book, you’ll see the name you’ve given it instead of the address. You'll have added the signer to your Addresso Book because you have a level of trust in the corresponding person or organization, and can then take this into consideration when thinking about adding the shared info to your Addresso Book.

If the signing wallet isn’t in your Addresso Book, or if you’re starting your first Addresso Book via this share, then you’ll be adding two entries in one action: the info shared and the wallet used to sign the share. Sweet!

Addresso is yours ... a part of your everyday carry. Addresso runs across your devices under your control not someone else's at their whim. Your Addresso Books sync between your devices automagically without cloud storage. Not Your P2P Software Not Your Tech.

P2P is awesome. The local-first force is strong in our team. But it is challenging to live up to when we’re all the heirs of client-server architecture. We’ve worked hard to make our first version of Addresso sharing easy, private, secure, and local-first.

By private we mean there’s no way our team should know anything about who’s sharing what with who. We’re already totally ignorant of everything, so let’s keep that up 😆. And by secure we mean having confidence that nothing has been tampered with along the way.

So here’s how it works (sequence diagram below):

1. Your Addresso app generates a 4-digit PIN and derives a symmetric key from it

2. Your Addresso app uses the symmetric key to encrypt everything being shared

3. After you sign the share, your app sends the encrypted data and signature to the Addresso relay server and receives a 8-character reference in return

4. Your app generates and exposes a base64 containing the 8-char reference and the 4-digit PIN within a my.addresso.com URL

5. You share this link

6. When Bob follows the link his browser sends only my.addresso.com to its DNS and his browser is directed to the Addresso app (the progressive web app)

7. Bob's Addresso app unpacks the base64 to get both the reference and the PIN

8. His app uses the reference to load the data from the Addresso relay server

9. His app derives the symmetric key from the PIN and decrypts the data

10. His app presents him with the information being shared and the signing information.

While a relay server is in the mix, no-one controlling the server could possibly make any sense of what’s going on. And everything is deleted after 7 days — I can see our magnificent dev team named the server’s services StoreEphemeralData and GetEphemeralData.

We have some idea how we might further decentralize the process down the road. And of course, we hope you’re with us for the journey.

😍

Photo by Wesley Tingey on Unsplash.

Digital identity has not been designed to rise up to the roles and operations that the vast majority of other disciplines (e.g. psychology, sociology, cultural studies, history, political science) attribute to human identity. It's designed explicitly not to be contextual, malleable, multiple, social, temporary, subjective, dynamic, emergent. Most fundamentally, whereas digital identity is merely a thing to render users legible to the system for authentication, authorization, and/or record keeping, human identity is a socially vital process and sense-making capacity. In short, digital identity as it's currently conceived and operationalised is not what you might call human at all.

This disparity may have been OK(ish) when ‘the digital’ was somewhat detached from ‘the real world’, but we’re at least fifteen years on now from that being the case. 'The digital' is irreversibly fused into the fabric of our lives with the growing pervasiveness of social media, the mass migration from big screens to small ones, and the astonishing growth in the computing and sensory capabilities of those small screen devices. It is inappropriate to continue referring to such devices as phones; they represent our exobrains and exo-peripheral nervous systems. They are our interface into and through 'the digital' just as we are the interface for digital systems into the analogue world.

Regardless, the operations of human identity remain forever essential for dignity, autonomy, cooperation, and flourishing. The exponential expansion of digital identity now being contemplated — cheered on by technologists and policymakers alike — threatens the continued operation of human identity. What are they not yet seeing? How are the celebrated protocols toxic? And how must we proceed from here?

[An extract from Digital identity is not human identity, and that matters, July 2022]

• Names are not coordinated by some central authority

• Names are secure i.e. no-one can pass themselves off as someone else

• Names are meaningful and memorable e.g. not telephone numbers

You might say that it describes the challenge of accommodating two very different ways of 'thinking' about names — the computer way and the human way.

Perhaps the most prominent approach to achieve all three is the idea of petname systems first formally described by Marc Stiegler. To be more precise, petname systems do not actually realise names with all three properties, but they may be said to realise a system that can offer a similar experience to the human participants in the system. In Zooko's own words:

You can have a namespace that is distributed and secure [the first two bullets above] and in addition you can offer your users a computer agent, which runs locally to them and is loyal to them, which translates the self-authenticating names into human readable names for their use.

In Pet Names, the user still gets the usability benefits from all three sides of Zooko's Triangle.

The translation operates both ways. Or in the technical lexicon, there is both forward and reverse resolution.

If Alice faces a choice between less or more friction in a digital system, between more or less convenience, you know the choice Alice is going to make. Should Alice opting for lower friction / higher convenience correspond to what’s best for the health of the system overall, we have a fortunate alignment. Empower Alice now! Decentralize!

However, when such a choice is disadvantageous at the system level, she will ultimately come out the worse for it alongside the rest of us. Let's use a 2012 Wired article by way of example:

Imagine a world where banks take into account your online reputation alongside traditional credit ratings to determine your loan; where headhunters hire you based on the expertise you've demonstrated on online forums such as Quora; where your status from renting a house through Airbnb helps you become a trusted car renter on WhipCar; where your feedback on eBay can be used to get a head-start selling on Etsy; where traditional business cards are replaced by profiles of your digital trustworthiness, updated in real-time.

Porting reputation data from one context to another serves Alice wonderfully in the moment. We would all find it low friction / highly convenient. But this vista is deeply alarming, not that the author recognised as much at the time it seems. 

Programmatic quantification of reputation is an inevitable evil due to the unavoidable self-moderation and modulation it inflicts on its subjects beyond that which might be argued as 'good for society'. To be clear, the social accretion of local, contextually relevant reputation with forgiving opportunities for reparation has served communities for millennia. We are however considering universal, non-contextual and irremediable scoring and algorithmic assessment. Mix in a naïve conceptualization of identity and we will have excluded from society anyone for whom identification is a question of personal safety, and shackled the very psychological change processes we all experience and rely upon.

This reputation system epitomises a misalignment of self-interest and system-interest. In not appreciating the long-term systemic consequences, our self-interest works very much against our self-interest.

It’s unethical then to decentralize power when the system is wrought with such misalignment. More research and development is required to secure alignment, and the misalignment can be neutralised with good governance in the meantime.

The process of governance entails the determination of authority, decision-making, and accountability, and ethical governance in situations of such misalignment will necessarily incorporate a mix of talents dedicated to the flourishing of the system at all scales.

While not perfect, this is the basis of human and societal development for the past century. Rather than an abrupt switch to a new governance model, one that would be destined to fail hard, we can blend old and new forms of governance to get to where we all want to go sooner than later.

There is no need to trust that 2+2 will equal 4 tomorrow, it just will. Ditto other deterministic processes such as cryptography. Nevertheless, technologists love the word in the context of deterministic technology, particularly those predicated on some cryptographic technique.

Now we might say in everyday parlance “I trust my [tech thing]” but we actually mean we trust those who have designed and delivered it, and perhaps those who have tested and certified it, etc. We are willing to take the risk of making ourselves vulnerable to the product of this combined intelligence and labour.

So what about the idea referred to as the web of trust?

The idea emerged in the 90s with the advent and uptake of cryptographically secured electronic communication directly between individuals. The phrase expresses the hoped-for qualities of two people (say Alice and Bob) forming a cryptographically secured communication channel and the process by which one can trust that a third person is who they claim to be solely courtesy of existing relationships (say Alice and Charlie exchanging cryptographic keys based on Bob vouching for both of them).

The web of trust approach lacks the convenience of trusting a centralised service but avoids the concentrations of power and inevitable vulnerabilities any such centralised service carries.

Interestingly, the approach involves both social and technological actions and so interweaves trust as social scientists understand it with trust as technologists have appropriated it.