We’ve had a couple of great calls with the team at Planetary:
They’re building a native mobile app powered by the Secure Scuttlebutt (SSB) protocol.
One of the challenges everyone building on alternative, peer-to-peer protocols has is interoperability with the web.
How can you use your SSB identity on the web? How do people, as we move between networks, make our usernames portable, even while the private keys and other unique identifiers on different networks remain coupled to their native protocols?
More broadly, we’re discussing interoperability and portability around things like accounts and usernames.
Mobile App Logins to Desktop Web Apps
One of the patterns we’re increasingly seeing is combining usage of a mobile phone and a desktop web browser. WhatsApp logs into a desktop browser by scanning a QR code with the app on your phone.
The user experience that the Planetary and Fission teams will be exploring is very similar: scan a QR code in the browser, authenticate with the Planetary app that holds your SSB identity on the phone, and then use the web app logged in with that identity.
Verifiable Credentials for Username Linking
Fission’s UCAN Tokens are built with the W3C Decentralized Identifiers (DIDs) standard.
Verifiable Credentials are another emerging W3C standard. In essence, a claim is made and verified cryptographically, and associated with a DID.
Can we use Verifiable Credentials to solve the relatively narrow use case of claiming and verifying usernames across networks?
So, while I’m “bmann” on Twitter and “boris_mann” on Telegram, and Evan from Planetary is “rabble” as many places as possible, this is both not easily discoverable, and there is no way to communicate or link this across networks.
- Use Webfinger so that networks can be discoverable
- This also makes for a very low bar for self-hosting – just needs the ability to host a
.well-knownfolder at a domain - use DID / VC in a way that doesn’t go all the way down the rabbit hole of an “enterprise” or government service, but see what we can do for interoperability from self-hosted hacker to social apps
Next Steps
We recently had the Qri #qri team explore using our UCAN decentralized authorization standard. They implemented a version in Go.
We’re going to explore what mobile to web logins look like between Planetary and Fission, as an example of interoperability “plugfest”.
Join Us
Are you interested in portable usernames and DIDs? We’re going to have an open session on these topics to see who else is interested in interoperability and wants to try plugging into each others’ systems.
We’ve scheduled for Thursday, October 15, 2020 4:00 PM
Notes
Portable Usernames is the wrong phrase. The “linkability” of usernames and the uniqueness of using did:key seem to be core. How do you link one or more human readable usernames to unique keys.
Key point: did:key as the unique / portable ID that we are building UP from to add usernames. Just like IPFS has content-addressing as a building block to uniquely address a piece of content (even outside of other parts of that system).
Discovery: Goal is to have discovery to have people find each other from other systems. Once you link / verify an email address or external social username, this should go into “find other people in this network who want to be found, in a way that doesn’t share all my contacts”.
General interest in UCAN. Keep working on it / extending it as the building block to work on together? User Controlled Authorization Networks (UCAN) Resources
Evan: human identifiable names linked to keys is holding up adoption. Either solve it in SSB (doing this without a spec internally), also need to solve it on the web.
Evan / Kris: SSB can be built in a weekend on top of existing libraries. Not seeing this in the did:key space. Would want to easily stand up a service, auth built in decentralized. Look people up in a service.
Brendan: a bit like Zooko’s triangle – human-meaningful names, decentralized, and secure. Are we OK abandoning unique usernames? Discussion on how Discord does this with display names (set per server), and underneath a unique global identifier
Brendan: snappiness! Has to be as fast as any web1 system. Not willing to give up UX.
Evan: once you have the ability to map identity to keys, you want to look them up. Which contacts from system X are here?
Evan: do this without exposing your contact list. Mention of OpenMined, that re-implemented COVID privacy preserving model. zkProofs (example: OpenMined Blog: What are zero knowledge proofs?)
Discussion of account recovery / key recovery.
Blaine: consistency of sign in and discovery and recovery. eg boris @ discord, boris @ fission etc. Likely we should make these look like email addresses or in fact use email address.
Brendan: key rotation too big to solve. Like the UCAN model of creating derivatives that give you permission to yourself.
Boris: on Google and bouncing between domains and setting multiple cookies. As far as we can tell they are using the concept of Macaroons, which is the concept that @expede built into UCANs.
Chat Log
a few items from the chat log
Amanda highlighted “discovery and recovery” as a one liner of the two flows where existing accounts can be helpful.
Evan: we do key escrow by falling back to apple keychain / iCloud in planetary. Brendan from Qri says chasing the same thing.
Brendan: but we’re really describing username@PUBLIC_KEY, aren’t we?
Boris: Username @ (service that knows how to map to public key)|
So can be both self hosted or centralized service, identifiers are are owned by users
Blaine: what boris said. and anyone is free to run ${service}|
Boris: Like content addressing, the unique portable identifier is what matters