Introducing Keytrace — Keytrace Blog

What problem does Keytrace solve? It's a bit of a non-problem for most folks, but how can you prove that you own another account? I am @orta on GitHub, and @orta on npm but I'm not @orta on linkedin - someone beat me there! So, it might be a good guess that I get somewhere first but it's not that easy to claim a 4 character handle. You could know my website: orta.io and then assume that the links on there are a good source of truth, but I could say anything I want on my website!

People who have used Bluesky might be aware of how handles work there, my handle on Bluesky (@orta.io) is my website. To 'claim' that handle, I had to prove I owned the website via DNS. It's a bi-directional relationship where both point to each other.

Keytrace extends that type of relation to other accounts on the internet: Reddit, GitHub, npm, Twitter/X, LinkedIn, Instagram, Mastodon and more. Keytrace will walk you through the process of making some form of user content to prove your ownership which links back to your atproto/Bluesky account, and then Keytrace provides an open-source library to verify that connection and you can also run it from this website.

This idea is not new. Back in 2014, I signed up with Keybase and proved I owned my GitHub account for them. But, I think it is worth talking about the changes I have made in architecting how Keytrace works.

Keybase was an extension of the PGP Keyserver concept, where you had a central place for people to put their public PGP keys, and the Keybase CLI (or website if you gave them your PGP private key) would be able to do a lot of interesting cryptography things. Keybase did a lot. The part which I think really stuck around in people's minds is "Proofs" which are bi-directional verified proofs:

Your PGP key was used to make a cryptographically signed message on the other account, and then separately Keybase's API would verify proofs by reading that website's public pages to compare the data.

Keytrace evolves this model:

Data isn't stored on Keytrace's servers, so, no risk of me getting bored and stopping the project
Data can be posted by other people's systems, anyone can verify or check other people's verifications
Keytrace's runner for the proof verification is open-source and available for others as an independent npm module
The data is created so that Keytrace can offer an API which only requires GET requests and the capacity to validate a JSON Web Key to prove that the data is 100% verified by Keytrace

That said, I make a pretty big breaking change though:

PGP isn't the primary identification around which the system is based, your atproto account (and by-proxy it's unique identifier (DID) is)

PGP is well used in certain subsets of the net, but I'd like Keytrace to be more broadly available than that. So, you can put your public keys on - I have verified the same PGP key I used for Keybase. However, Keytrace is a bit more focused on user/developer convenience at the expense of being PGP-focused.

Other than that, I have a second, more technical write-up so that people can audit the details, but you're welcome to verify your related accounts!