Keyoxide Project Update #4

Posted on 2021-05-04

The update I have been looking forward to for months.

Keyoxide 3.0.0

Every day I work on Keyoxide, I learn more and gain a deeper understanding of how powerful this Decentralized OpenPGP-based Identity verification actually can be. And as we are nearing the first anniversary of the Keyoxide project, I realized all the new ideas and major improvements—most suggested by the community—were being held back by the previous implementation of the code, restricted by my earlier understanding and imagination.

It was time not for a number of superficial additions and fixes, but for a big overhaul of the core code which would then cause a chain reaction of bugs to be fixed and features to be added or improved.

To illustrate what is new in this version, here's my Keyoxide profile.

Visuals

Ok, let's do start superficial, though. Keyoxide 3.0.0 has a shiny new look. I hope you will agree with me that that was much needed. The previous design of the website was made before I even implemented the concept of decentralized proofs.

The new and cleaner design has eliminated most of the clutter and puts all the emphasis on what is important: the identity claims.

Server side rendering

Thanks to the class-based approach of the doip.js library (version 0.12.*), Keyoxide will now do most of the mundane work on the server and let the browser finish the process of identity verification. So who does exactly what now?

The server will try and find the public key associated with the profile to be generated
The server will parse the identity claims stored inside the public key
The server will match the identity claims to the known library of service providers
The server will render the profile page, including the yet-to-be-verified identity claims, and send it to the browser
The browser will parse the yet-to-be-verified identity claims and verify them

Not only is the website now much faster to load, the browser will verify the identity claims in parallel! No more waiting for that one slow identity to verify before showing the result of all the other identity verifications.

rel="me"

The wait is finally over! Server-side rendering means that Mastodon instances can now detect the rel="me" links on Keyoxide profile pages and will reward you with a green tick for every Keyoxide profile you link to in your Mastodon bio!

Here's an example: @keyoxide@fosstodon.org. So satisfying!

Yes, this means Keyoxide can now do and be as much as "any other" identity provider on Mastodon. By just using basic web technology. Without requiring special server protocols. And no VC-funded companies needed.

Small web truly is beautiful, isn't it? (quote from Small Tech Foundation)

A claim failed, what does that mean?

The issue of a claim failing to verify is actually more complex than it seems, and something that the previous versions of Keyoxide did not handle very elegantly.

As an example, let us claim to be Alice on Github. If it fails, it could either mean that we made a mistake somewhere, or we are attempting to impersonate Alice—the very thing Keyoxide is designed to detect and prevent.

In this case, it's simple: the claim https://gist.github.com/Alice/... could only reference Github so the story ends here.

But what if we wanted to verify https://alice.tld/apps/live? From the looks of it, it could be an Owncast server, but that is just a guess.

When this claims fails to verify, does it fail because that Owncast server is not mine (impersonation) or because it wasn't actually an Owncast server? This URL could also very well lead to a repo on a Gitea server.

And what if it also fails to verify as a Gitea account? Was it one of them that genuinely failed, or neither of them?

Keyoxide 3.0.0 now recognizes "ambiguity" in URLs and acts accordingly. Does a claim with an unambiguous URL (like Github) fail? Keyoxide will let the visitor know the claim genuinely failed. Did a claim with an ambiguous URL fail? Then Keyoxide will show a message letting the visitor know that it wasn't sure what the claim was meant to be but regardless, it failed to verify.

Future improvements

Keyoxide 3.0.0 brings a few tweaks, but again, the biggest change is the overhaul of the core code. This will allow a bunch more improvements to be made soon with relative ease. Here's an overview of what is in the pipeline.

Requirement of JavaScript

Previous versions of Keyoxide said "the browser must do everything". This meant that JavaScript had to enabled in order for Keyoxide to be able to do anything at all.

As stated above, Keyoxide 3.0.0 now only lets the browser do the very last step of the whole process but this still means JavaScript is required. However, it is not difficult to imagine now that the server could do everything and just send the finished profile page to the browser.

In a future version of Keyoxide, visitors who have JavaScript disabled and do not mind waiting for up to fifteen seconds (due to some claims taking more time to verify) will be able to request a fully server-side rendered profile page.

a11y and i18n

With more work being done server-side, it becomes simpler to implement internationalisation and render the website in different languages.

Also, with the pages themselves become less dynamic, decent accessibility is also simpler to achieve and currently has the highest priority.

Signing off

That's about it for today. This update marks a big change that will greatly benefit future versions of Keyoxide. I can't wait to start working on the next developments and share them with you as they come along.

As always, the source code is available at the Codeberg.org repo (now renamed to keyoxide-web).

For all your questions and suggestions, be sure to join the conversation in the Keyoxide matrix room or raise an issue on Codeberg.org. All contributions are welcome!

Until next time.