Skip to content

Instantly share code, notes, and snippets.

@DougAnderson444
Last active August 2, 2023 01:02
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save DougAnderson444/8fb1dffa4e9b43e41d81b13069d8c96f to your computer and use it in GitHub Desktop.
Save DougAnderson444/8fb1dffa4e9b43e41d81b13069d8c96f to your computer and use it in GitHub Desktop.
Vouched Discovery

So let's say I want to find someone in Web3 by some contact information I have about them.

  • Phone number
  • Email address
  • Physical address
  • First name

...whatever.

Let's assume there's a network where anyone can save this sort of information, like IPFS / libp2p.

I do ping the network for matches, but since anyone can post to the network how do I know which search results are legit?

The typical way to do this would be signing using a Public key, but that assumes that I know their public key... in which case I probably wouldn't be looking for their public key, I'd already know it.

Plus, public keys change all the time, what if they've changed or added a key?

Yes we could use a centralized solution like keybase but we're trying to get away from that.

So what we want is a solution where I take their first name and phone number, ask the network for a response and then get solutions from which i can pick in order to get their latest public key.

Right?

So with BLS12-381 curve signatures we can do these neat crypto moves like selective disclosure of information.

And recent advances in Delegated Anonymous Credentials allows us to anonymously update these selected disclosures...

So by combining these two ideas, we can develop a system where anyone can issue a credential about another person, and they can add some more information to that credential without revealing anything else about themselves, just the issuer.

Let's issue a credential for name + phone number, then add/update our public keys are required!

For example, Alice is popular, well known and trusted throughout her community. She creates and sends some Credentials via text message to her network to "vouch" for their phone number. Alice also includes their first name in the credential she sends.

Bob receives one of Alice's credentials, awesome! He sees that Alice vouches for his name and number, but lacks any public key info he has.

Because the Credential can be extended, he adds a couple of public keys he has, his IPNS key and his Nostr key, so people can get in touch with him through those channels.

Bob generates a cryptographic proof for his updated credential and posts it to popular networks like libp2p, bitcoin, his website, whatever the popular place is where people will look for his info.

Charlie has Bob in his contact book, he already knows Bob's phone number. But Charlie wants to message him in Web3 so he needs his public key.

Sure Charlie could always ask Bob for his latest keys, but keys change, Charlie and Bob are busy people and out of band requests like that are prone to error and security risks.

Charlie instead looks up Bob's name and number in Libp2p to see if there's a proof posted that matches.

Charlie finds the proof and sees that Alice issued the credential. He can check Alice's key against the one he has for her posted on her website.

Charlie can also see any other proofs generated by any other issuer and use the ones he trusts.

Once Charlie has Bob's keys, he can get further updates via more proof searches if he likes.

Now imagine instead of Alice vouching for folks it was businesses. They are public, have websites and want to be seen by people anyway. Imagine every time someone is searched, there's a list a businesses/websites who vouch for someone's contact info.

It's a win-win. Spam gets eliminated, businesses get a bit of mild advertising, and a decentralized Web3 gets funded.

@DougAnderson444
Copy link
Author

Another great thing about this protocol is if all of the keys are lost, the entire chain of events can be re-created and re-posted from scratch and it still works.

Bob would ask Alice to send new Credential, to which he would add a new public key, and post the latest edition online for people to discover.

Searchers would simply use the latest vouched posting and discard the rest.

@DougAnderson444
Copy link
Author

If Bob receives his credential via SMS text, he can always just use it to update his details and repost to the network.

The protocol should periodically check the contact book for updates to this key value store

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment