# 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