You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Alexander Nicholi 22ea7cad5a
update package versions
1 month ago
dist fix naming for output 1 month ago
src remove hashbangs 1 month ago
test remove hashbangs 1 month ago
util add library concat to build 1 month ago
.gitattributes Initial commit 1 month ago
.gitignore Initial commit 1 month ago Initial commit 1 month ago
CONTRIBUTING Initial commit 1 month ago
COPYING Initial commit 1 month ago
README Initial commit 1 month ago
package-lock.json update package versions 1 month ago
package.json add library concat to build 1 month ago



qMMM mmm .jAm, ,MMMj ,amMMMMMmm,
MMMaaaaaaaMMM zMMMmmmMMm, MMM ^^^ MMM:

Your self-hosted, federated video sharing platform


HALO is a self-hosted high-bandwidth content sharing platform that fuses
federated client-server social activity with scalable, cloud-like data hosting
and delivery systems to enable the public to platform heavyweight content like
video without reliance on third parties. Unlike other decentralised platforms,
it provides rock-solid access control, opening a full spread of avenues for
creators to monetise their work and support the infrastructure they stand on.

This program is free software: you can redistribute it and/or modify it under
the terms of the GNU Affero General Public License as published by the Free
Software Foundation, either version 3 of the License, or (at your option) any
later version.

This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more
details. You should have received a copy of the GNU Affero General Public
License along with this program. If not, see <>.


§1. Executive summary

Quote from the README:

Some bullet points:

- Halo provides a reference implementation for its backend. This is currently
written in JavaScript.
- Halo servers are of two kinds:
- “Arbiters”, which provide authority and centralisation for a network
- “Bastions”, which provide content and its infrastructural guarantees
- Arbiters provide very high-granularity access control:
- Individual authentication for each viewer
- Creator-controlled paywalling of content
- Conventional payment APIs may be used, as well as cryptocurrency
- Arbiters can federate with one another to cooperatively share content and
- Arbiters provide enough independence and tooling to create fully-fledged
online entertainment networks

§2. ‘Domestic’ and ‘Federated’

Halo implements a system of federation quite similar to Mastodon’s. Two
definitions used in documentation are Domestic and Federated (as capitalised).
These are in reference to users of Halo, where Domestic users are local to the
network they’re interacting on, and Federated users are tuning in from some
other network which has a working relationship with the local network in
question. Generally, the protocols for Domestic users will be simpler and more
consistent than they are for Federated users, as the latter involves checks and
limits imposed by the agreements in force between the two networks, which may
be more restrictive than those imposed on locals.

§3. Networks

A ‘network’ is a digital community centre for the publication and sharing of
content. Under the hood, this is supported by a running instance of an Arbiter
server. Content creators register with an Arbiter, gain membership with its
network, and upload content, build their audience, and drive revenue through
patronage or advertising, which may then support the running costs of the
Arbiter’s associated Bastion servers to deliver the content to the world.

§3.1. Vendor lock-in

A common problem creators often face after building their audience up is the
so-called “vendor lock-in”: they are inherently vulnerable to network providers
because of their position as middlemen, and become beholden to them, for better
or for worse, even as the content creators did much of the work to bring the
audience that pays the bills, and are arguably the only reason people visit.

However, there are a lot of benefits that only come with strong networks:
reliable infrastructure, additional resources and connections, and most
crucially, advertising links. While Halo of course leaves the option open to
self-host as a creator, there will be inevitable economic incentives to join a
network for some.

With all of that in mind, Halo makes no compromises and chooses no side to this
question, as it can offer the benefits of world-class entertainment networking
without the potential detriments of irresponsible middlemen. Using OpenPGP,
users who subscribe, follow, or otherwise substantially interact on an Arbiter
instance can sign a cryptographic ledger recording the event. Creators can then
download these events in a cryptographic digest, which can then be presented to
any other server to facilitate an “audience migration”. Thanks to cryptography,
no part of this process requires any input whatsoever from the old network.

§4. Types of federation

Halo addresses the core problems with federating heavyweight content at scale.
In doing this, it presents two types of federation: Arbiter Federation (AF),
and Bastion Federation (BF).

§4.1. Arbiter federation

This is the typical sort of federation, and often the first to come to mind.
With this federation, two or more Arbiters are conjoined together following
a technical set of terms and limits, allowing those involved to
‘cross-pollinate’ each other’s communities by sharing content and creator
profiles, and allowing payments to cross network boundaries for subscriptions
and more. In doing so, the networks will come to a compensation agreement that
financially provides for the server loads incurred by Federated activities,
usually via a predetermined rate factored with some objective metrics. Halo can
also provide cryptographic verification of such metrics so both parties can be
sure the right amount of money is changing hands.

§4.2. Bastion federation

Also known as ‘headless federation’, this type of congregation doesn’t involve
Arbiters in the normal usage. Two or more (usually several) heavyweight servers
owned by the same entity can be brought together to facilitate horizontal
scaling of the load incurred by content consumption. In doing this, the server
owner can use the tooling provided for Arbiter federation to contractually sell
server resources at a preset rate, making them money for putting their servers
to full use. This enables large hosting providers to easily sell scalable
backbone material for network operators as a business.