Earlier last week, I wrote out a very general, ‘executive’ summary to explain why HALO exists and what it hopes to change with content online. Today, I’m going to go over the nuts and bolts of HALO as a software suite, in a still general, still executive, but more technically-focused approach. There are three major software components I will introduce today: the Arbiter, the Bastion, and the Single Auth Infrastructure, or SAI. In concert, these components (respectively) enable network administration, content delivery, and identity management + authentication.
The Arbiter is the command centre of a given HALO content network. Its purpose is to coordinate user activities, mediating between clients and the website at large. Before a user can start streaming a video, their client must request a view key from an Arbiter, and only then connect and stream that content from a given Bastion server that has it. The Arbiter provides the basin of the network’s community of users and creators: it is the root of authority for everything about the network. To better manage users, it divests from handling identity and account data, deferring that to the SAI we’ll go over later. TL;DR: the Arbiter is head of the network.
The Bastion stores and delivers the goods: video content is kept, curated, colocated, and delivered to users CDN-style across the globe – with the assent of their presiding Arbiter, of course. An Arbiter keeps a pack of Bastions to do the naturally expensive task of hosting its content. Bastion servers are then sustained by the revenue made from the network’s successful market strategy. They hold no agency or oversight, really, and only take orders from their Arbiters, delegated or not. The intricacies of this relationship are sorted out nicely with cryptography, in practise. They interact with users upon request, doing their job as long as the Arbiter is okay with it. They do not interact with SAI servers as they are exclusively secondary to their Arbiters, who vet the authenticity of their requests on the Bastion’s behalf.
The Single Auth Infrastructure, often shortened to SAI (pronounced phonetically), provides to users what Arbiters provide to networks: agency. SAI employs the OpenPGP suite to implement a state-of-the-art cryptography and identity system for people online. It offers a general API chiefly used with the HALO Arbiters to verify that somebody is who they claim to be by their profile. SAI portals allow the usual logins with email and password, and two-factor auth, and behind the scenes they provide secure, short-term keys for the associated services to use instead of a login. SAI servers can create a cryptographic ledger (sometimes called a blockchain) that can record interactions and events that take place, in an independently verifiable and downloadable format. These can prove extremely powerful for preserving the independence of content creators by saving proof of their followings, among other things.
These components work together in a highly modular fashion, enjoying many benefits from their technical independence, while coming together to pass that independence on to be the benefit of their users. Take a look at this graphic illustrating the process of connecting to watch a video:
If you follow the annotations on the user’s icon, you’ll notice that they are acquired when needed, and gracefully let go once their job is done. First, Sam obtains an identity token to use with an Arbiter. But after she obtains a viewing key to use with the Bastion, that key is sufficient to get her connected and streaming, so the identity token is discarded.
An important thing to remember about these tokens and keys is their significance in HALO’s cryptography. This has a remarkable implication: when the transfer starts at the end, several things hold true in regard to the encrypted stream: it will be totally different from every other stream emitted from the Bastion, every other stream consumed by the user, every other video the two ever connected for, and every other stream for that video from that Bastion to that user.
While this probably isn’t a revolutionary idea on its own (see TLS 1.3 and its mandatory forward secrecy imposition), its worth noting that this happens on a layer closer to the app than, say, TLS or SSL. The trust context of every interaction is derived from SAI, making it special to the programs that use SAI’s identity and auth services (chiefly HALO). SAI doesn’t rely on centralised Certificate Authorities and doesn’t silently break its integrity with HTTP proxies, which is nice because it can easily take advantage of them with Web Sockets.
I hope this helped flesh out the foundation of HALO better for you. Of course, I am always happy to hear feedback, which you can post on Twitter if you wish. Some time this week I hope to adjust the landing page to include a better spread of social media links, and one to this place. I’m also going to port over this weblogging codebase to the Arqadium weblog, and follow through with my other promises regarding that site. Next week I’ll go over HALO’s tech stack as it is and as it used to be, along with a brief explanation on why it changed, so I hope you’re interested in that. Until next time!