93 lines
6.0 KiB
Typst
93 lines
6.0 KiB
Typst
#let title = [
|
|
Design and implementation of a decentralized music streaming platform using ActivityPub and peer-to-peer content distribution
|
|
]
|
|
|
|
#set page(
|
|
paper: "a4",
|
|
margin: (x: 2.5cm, y: 2.5cm),
|
|
number-align: center,
|
|
numbering: "1",
|
|
)
|
|
|
|
#set text(
|
|
font: "New Computer Modern",
|
|
size: 12pt,
|
|
lang: "en",
|
|
)
|
|
|
|
#set par(
|
|
justify: true,
|
|
leading: 0.65em,
|
|
first-line-indent: 1.25cm,
|
|
)
|
|
|
|
|
|
#align(center, text(16pt)[
|
|
*#title*
|
|
])
|
|
|
|
#align(center, text(14pt)[
|
|
Gabriel Kaszewski
|
|
])
|
|
|
|
#set heading(numbering: "1.")
|
|
|
|
#pagebreak()
|
|
|
|
#outline()
|
|
|
|
#pagebreak()
|
|
|
|
= Introduction
|
|
|
|
Music streaming has become the dominant mode of recorded music consumption worldwide. Services such as Spotify, Apple Music, and YouTube Music collectively serve hundreds of millions of listeners, providing convenient access to vast catalogues of audio content. Despite their commercial success, these platforms share a set of structural properties that give rise to recurring concerns.
|
|
|
|
First, they are architecturally centralised: all audio content is stored on infrastructure controlled by a single corporate entity, creating single points of failure and placing the availability of the entire catalogue at the discretion of the platform operator. Second, they impose vendor lock-in on both listeners and artists: playlists, listening history, follower relationships, and catalogue presence are tied to a specific service and cannot be migrated.
|
|
|
|
An alternative architectural paradigm exists in the form of federated and decentralised systems. The Fediverse, a constellation of interoperable social platforms communicating via the W3C ActivityPub protocol @w3c-activitypub, has demonstrated that it is possible to build large-scale, user-facing applications without central ownership of data or infrastructure. Platforms such as Mastodon for microblogging, PeerTube for video, and Funkwhale for audio have shown that federation can provide practical alternatives to centralised services. However, the specific problem of music streaming in a federated context remains underexplored. Existing solutions such as Funkwhale store audio on individual server instances, meaning that content availability depends entirely on the continued operation of the hosting instance. If an instance goes offline, all content it exclusively hosts becomes unavailable.
|
|
|
|
Peer-to-peer content distribution offers a complementary approach. Protocols such as BitTorrent and systems such as IPFS distribute data across multiple participating nodes, so that content remains available as long as at least one node in the network holds a copy. Combining federation for social interactions and discovery with peer-to-peer transport for audio content could, in principle, yield a system where music remains available even when individual instances experience downtime.
|
|
|
|
This thesis investigates whether such a combination is feasible in practice. Specifically, it poses the following research question: _can a federated music streaming platform, built on ActivityPub for social interaction and peer-to-peer protocols for content distribution, provide acceptable content availability without relying on centralised storage?_
|
|
|
|
To answer this question, this work makes the following contributions:
|
|
|
|
+ *A reusable ActivityPub federation library.* The k-ap library, implemented in Rust, provides a domain-agnostic layer for ActivityPub federation, including inbox and outbox handling, WebFinger, NodeInfo, follower management, and activity broadcasting, that can be integrated into any application through a trait-based plugin architecture. The library has been validated in two prior applications: a microblogging platform and a movie diary service.
|
|
|
|
+ *An extension of the ActivityPub vocabulary for music.* The standard ActivityStreams 2.0 vocabulary lacks constructs for representing albums, tracks with duration and attribution metadata, and content-addressed audio references. This thesis defines a custom JSON-LD namespace that extends ActivityPub to model these concepts while preserving interoperability with generic ActivityPub clients.
|
|
|
|
+ *A hybrid federation and peer-to-peer architecture for music streaming.* The system design combines ActivityPub for content discovery and social interaction with a peer-to-peer transport layer for audio delivery. Server instances act as stable seeding nodes, while native desktop clients participate directly in the peer-to-peer swarm, reducing dependence on any single instance.
|
|
|
|
+ *A native desktop client.* In contrast to the browser-based clients typical of Fediverse applications, this work includes a native desktop client implemented in Rust, capable of direct peer-to-peer participation without the constraints of browser sandboxing.
|
|
|
|
+ *An empirical evaluation of content availability.* The system is evaluated through simulated network scenarios examining the effects of varying node counts, replication policies, content popularity distributions, and node churn on content availability.
|
|
|
|
The remainder of this thesis is structured as follows. Chapter 2 reviews the relevant background on ActivityPub, peer-to-peer content distribution, and decentralised systems architecture. Chapter 3 presents the system design, including the ActivityPub vocabulary extensions, federation model, content distribution model, and overall architecture. Chapter 4 describes the implementation, covering the technology stack, backend, and client applications. Chapter 5 evaluates the system against its stated requirements. Chapter 6 discusses known problems and limitations. Finally, Chapter 7 presents conclusions and directions for future work.
|
|
|
|
= Background and related work
|
|
== The Fediverse and ActivityPub
|
|
== Peer-to-peer content distribution
|
|
== Decentralized systems architecture
|
|
|
|
= System design
|
|
== Requirements
|
|
== Representing music in ActivityPub
|
|
== Federation model
|
|
== Content distribution model
|
|
== Architecture
|
|
|
|
= Implementation
|
|
== Technology stack
|
|
== Backend
|
|
== Desktop client
|
|
|
|
= Evaluation
|
|
== Correctness
|
|
== Availability analysis
|
|
== Architectural evaluation
|
|
|
|
= Known problems and limitations
|
|
|
|
= Conclusions and future work
|
|
|
|
#bibliography("references.bib", style: "ieee") |