master-thesis/outline.md

Design and Implementation of a Decentralized Music Streaming Platform Using ActivityPub and Peer-to-Peer Content Distribution

Proposed Outline

---

1. Introduction

• Motivation — limitations of centralized music platforms (Spotify, Apple Music): single points of failure, vendor lock-in, artist revenue issues
• Problem statement — can a federated, decentralized platform provide acceptable availability without central storage?
• Thesis goals and scope
• Overview of contributions

2. Background and Related Work

2.1 The Fediverse and ActivityPub

• History of federated social networks (GNU Social, Mastodon, Pleroma)
• ActivityPub protocol overview (W3C recommendation)
• ActivityStreams 2.0 vocabulary
• Existing implementations (Mastodon, Pixelfed, Peertube, Funkwhale)

2.2 Peer-to-Peer Content Distribution

• Overview of P2P network topologies
• BitTorrent protocol
• WebTorrent (BitTorrent over WebRTC)
• IPFS and content-addressed storage
• Comparison of approaches and rationale for chosen solution

2.3 Decentralized Systems Architecture

• Hexagonal architecture (Ports and Adapters)
• Domain-Driven Design
• Federation replication patterns

3. System Design

3.1 Requirements

• Functional requirements
• Non-functional requirements (availability, scalability, interoperability)

3.2 Representing Music in ActivityPub

• Limitations of existing ActivityPub vocabulary for audio content
• Extending ActivityStreams 2.0 with a custom JSON-LD namespace
• Audio object design (metadata fields, duration, attribution)
• Album as OrderedCollection
• Embedding content addresses (magnet URI / CID) in AP objects
• Interoperability considerations with generic AP clients

3.3 Federation Model

• Actor model — artists, listeners, instances
• Content discovery via federation (Create, Announce activities)
• Follow/unfollow across instances
• WebFinger and NodeInfo

3.4 Content Distribution Model

• Replication policies: eager vs on-demand
• Instance as a stable seeding node
• HTTP streaming proxy for browser and mobile clients
• Native desktop/TUI clients as full P2P peers
• Storage policy configuration

3.5 Architecture

• Hexagonal architecture overview
• Domain layer — pure types, port trait definitions
• Application layer — use cases, event processing
• Adapter layer — ActivityPub, P2P transport, PostgreSQL, NATS
• Rationale for architectural decisions and tradeoffs

4. Implementation

4.1 Technology Stack

• Rust backend (Axum, SQLx, activitypub_federation crate)
• PostgreSQL
• NATS for async event fan-out
• Next.js web client
• TUI client (ratatui + symphonia/rodio)
• P2P library choice and rationale

4.2 Backend

• k-ap crate (reusable federation layer)
• Music-specific AP adapter
• P2P transport adapter
• Federation worker

4.3 Web Client

• Core user flows (upload, discover, follow, play)
• HTTP streaming from instance proxy

4.4 TUI Client

• ratatui interface
• Audio playback pipeline
• Direct P2P swarm participation

5. Evaluation

5.1 Correctness

• Federation interoperability (does it federate with Mastodon, Funkwhale?)
• ActivityPub conformance

5.2 Availability Analysis

• Simulated network with varying node counts
• Eager vs on-demand replication policy mix
• Content popularity distribution (popular vs cold content)
• Node churn (instances going offline)
• Results and observations

5.3 Architectural Evaluation

• Did hexagonal architecture deliver on its promises?
• Concrete example: swapping P2P transport adapter
• Test coverage enabled by the domain/adapter split

6. Known Problems and Limitations

• Cold content availability — obscure tracks may disappear
• Storage economics and lack of seeding incentives
• Bootstrap problem for new instances
• Content moderation and copyright in a decentralized network
• No central takedown mechanism

7. Conclusions and Future Work

• Summary of contributions
• Lessons learned
• Future directions:
  • Formal availability model
  • Incentive mechanisms for seeding
  • Integration with existing Fediverse platforms
  • PhD research direction: availability degradation in federated networks under heterogeneous replication policies

References