123 lines
4.1 KiB
Markdown
123 lines
4.1 KiB
Markdown
# 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
|