Browse Source

New post

Yarmo Mackenbach 1 month ago
Signed by: yarmo GPG Key ID: 37367F4AF4087AD1
  1. 123


@ -0,0 +1,123 @@
title: "Keyoxide Project Update #4"
author: Yarmo Mackenbach
slug: keyoxide-project-update-4
date: "2021-05-04 17:52:10"
published: true
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
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: []( 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 `` could only reference Github so the story ends
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 [ 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
[]( All contributions are welcome!
Until next time.