journal is deployed & next steps
Finally the new version of journal has gone live at my personal web site - https://journal.lukebarnard.co.uk. Essentially, this is a blog site and can be used independently from Matrix. I plan to keep the components separate and I’m confident this won’t complicate the implementation of Matrix integration.
The next step is to build something that will bring journal blog events from Matrix to the server that hosts the blog files. I’ve been thinking about how to verify that blog files belong to the author that posted the blog event. I’d like to share my thoughts on how this will work.
Verifying blog integrity
My thinking so far is to use a public/private key pair to enable signing of blog files. The public half will be stored in a Matrix event that the author sends into the room, prior to sending blogs. This is essentially the author’s public identity with respect to blog content.
When a blog file is loaded into a user’s browser, it will contain an optional digital signature that verifies that the content of the blog was written by the Matrix user. It will also contain the Matrix ID of the author. To verify a blog, the blog content, the signature and the author’s public key are taken as input and the result of this is displayed to the user.
Displaying verfication to the user
Generally, this kind of verification is displayed as “verified as @user:Matrix.org”. This will most likely appear at the top of the blog post, next to the author’s name.
It’s important to indicate the Matrix ID because the author name in the blog file may well be inaccurate. A simple yes/no “verified/not verified” indicator does not indicate the entity associated with the digital signature, but the extra step of including the matched Matrix ID closes the loop.
It’s also important to make this indication difficult to forge, so it will be made visually distinct to anything in the blog post itself (which includes the author name).
Unverified blogs can still be shown but will probably have some kind of warning attached to avoid confusion in cases of fradulently posted blogs.
Not using in-built Matrix E2E
The end-to-end security built into the Matrix protocol does indeed provide a mechanism to send verifiable events. But this does not protect data that leaves Matrix (of course) and is also on a per-device basis.
A journal based on Matrix E2E would also be strange for the personal blog and public journalism use-cases.
It’s also a bad idea to tie key functionality to the Matrix E2E, not least because it’s still in beta and decrypting events is a bit tempremental last I heard.
I hope enjoyed this random edition of “What is Luke Thinking About Journal Today”. Please leave a comment… just kidding, you’ll have to wait at least a year for that to be implemented. Looking forward to the first “first” comment on this post ;)
Thanks for reading. Don’t forget to watch & star the GitHub project.