Librecast - 2025 Strategic Plan

Last updated: 2025-02-10

Diagnosis

Background

Universal group communication is a requirement for human rights to flourish. Problems, such as climate change are global and affect the rights of all humans. Our ability to communicate, regardless of frontiers, is essential to our need to be informed, to organize, to promote and enjoy our rights, and to hold accountable those that would violate our rights.

All organizations and power structures must be held accountable for human rights to have any meaning. To monitor and hold accountable global power structures such as corporations, governments and NGOs, we require global communication that is not subject to interference, interception or control by those powers.

Our Internet is a requirement, not an option, for our global civilization, but that Internet is not fit for purpose. We need a Next Generation Internet (NGI) built around group communication and the tools to use it effectively.

The Challenge

The Internet we have today is built for one-to-one communication (unicast), but our communication needs are many-to-many (multicast). Group communication built on top of unicast is inefficient and cumbersome, and often relies on centralized 3rd party servers controlled by large corporations.

While there are corporations working on what they call “multicast”, this is almost always one-to-many rather than many-to-many, and is mostly about content (and advertising) delivery. The focus of these corporations is on shareholder value, not human rights values. Standards bodies, such as the IETF and W3C are largely driven by corporate interests, so any forthcoming standards that are useful for group communication will be purely accidental.

Policy

To enable multicast on the unicast Internet we start by building an encrypted overlay network using point-to-point links between participating nodes. Once established, our overlay network can run whatever protocols we require, unimpeded by routers and middleboxes and which is resistant to interception, interference and netblocks.

Our initial implementation will use WebRTC data channels for creating connections between participating nodes.

WebRTC is a point-to-point, encrypted protocol that is widely used in commercial teleconferencing, and which can use any type of signalling to establish and maintain peering, and it can penetrate most forms of NAT. Our use of WebRTC data channels is indistinguishable from other uses, and so blocking it would result in blocking other desirable commericial traffic. WebRTC builds on a number of existing IETF standards, and is well tested and implemented in major web browsers for more than a decade. We can use the same protocols for non-browser implementations, allowing seamless communication between browser and other nodes.

Actions

In order to provide multicast functionality on the unicast Internet, we will build an overlay network with participating nodes and implement our own many-to-many multicast protocols using that overlay. We will achieve this with the following steps.

Build Peer Discovery Backbone

Peers can be discovered by any means, such as via connection to a signalling backbone over websockets, email, or even carrier pigeon. We can provide multiple means to enter the network.

We have implemented a signalling backbone using HTTPS websockets (RFC 6455), but peers can join the network in any way they see fit.

Establish P2P Overlay Network

Using WebRTC data channels, we establish an overlay network using a convenient network topology.

We are testing several topologies to determine which is the best for certain use-cases and numbers of nodes, including a fractal network topology.

Multicast Routing

Develop a multicast routing protocol for the chosen network topology. This needs to manage the Outgoing Interface List (OIL) for each router interface and propagate channel/group JOIN/PART messages in a timely manner. Low latency, and the ability to handle large numbers of groups is important.

Network Coding

To maximize network throughput and resilience we will utilize network coding techniques.

Network coding addresses two problems: coping with packet loss, and maximising throughput across diverse links. Compared to simple routing, network coding allows us to maximise throughput when there are multiple paths between source and destination.

We have built a network coding library (liblcrq) which implements RaptorQ (RFC 6330) to handle packet loss. We will extend this library to implement network coding based around Batched Sparse Codes (BATS), as described in RFC 9426.

Multicast Tools

In order to demonstrate the effectiveness of our multicast solution, we need some tools that use it. Once we have established the viability of our methods and APIs we hope that other developers will use it as the basis of their group communications, porting the base libraries to other systems and languages. The following tools are in development.

Librecast File Syncing Tool (lcsync)

lcsync is a tool to sync files over multicast or the local filesystem. It splits the file into blocks, hashes them, and compares them in order to efficiently transfer a minimal amount of data.

Data is compared by generating a merkle tree using BLAKE3 hashes.

For local file syncing we walk the trees and compare the hashes to find which data blocks are different.

To sync remote files, each file is split into blocks and a merkle tree is built by hashing the blocks using BLAKE3. On the sending/server side, this tree is sent on a Librecast Channel that is formed from the hash of the filename. The receiver/client joins this channel, and receives the tree. If the client already has some data to compare, it builds a merkle tree of the destination file and uses this to quickly compare which blocks differ. It builds a bitmap with this information, and then joins the Channel(s) for the block(s) required which are sent by the server.

There is no unicast communication with the server, and the load on the server will not change regardless of how many clients are requesting the same block of data. There are no requests sent, and the server can sit behind a firewall which is completely closed to inbound TCP and UDP traffic. Instead, the server listens on a raw socket for Multicast Listener Discovery (MLD2) reports. It compares any MLD multicast group JOINs against the index it built on startup and finds matches for file (tree) and blocks. In this way, the server only sends data when at least one client is subscribed. If more clients want to download the data, the server need take no further action. Thus, the load on the server does not change at all, regardless of whether there is one client or a billion, nor is any additional bandwidth used.

Librecast Agent (lcagent)

Simple multicast listener and remote program execution.

lcagent is a small program that runs on a librecast node. It receives commands over multicast, performs tasks, and reports back information. Can be used for monitoring, server orchestration, configuration, continuous integration (CI) testing etc.

We are already using this program for our CI builds, but expect to find many more uses for it in future.

Librecast Studio (lcstudio) - Group collaboration and events.

Librecast Studio is the main target we are working towards in the Librecast Project. Our aim is to build a multipurpose collaboration environment based on Human Rights Values and using multicast design principles.

Librecast Studio is building on our multicast and network coding libraries to build an accessible, efficient, offline-first and user-centric group collaboration platform.

As we’ve discussed, human rights depend on effective human communication. Multicast is not just a network technology but also a design methodology where the recipient is in control of the data they receive and the medium in which they receive it. Multicast design is based on consent, and that consent can be revoked.

Librecast Studio uses multicast to deliver a multimedia collaboration platform enabling groups to work and play without compromising user autonomy.

Have you ever sat in a lecture or presentation (or watched the video afterwards) where you couldn’t read the presenter’s slides? Everyone’s eyes and tastes differ. By delivering the raw data and allowing the user to choose how that data is presented we allow presenters to deliver a media-rich presentation that is accessible to everyone. The recipient chooses which inputs to subscribe to, in which language, and how those inputs are rendered, choosing colours, fonts, sizes or using a screenreader, whether they are sitting in the lecture hall or watching the livestream or video.

Librecast Studio is under construction.