Add initial outline and thesis structure for decentralized music streaming platform
This commit is contained in:
122
outline.md
Normal file
122
outline.md
Normal file
@@ -0,0 +1,122 @@
|
|||||||
|
# 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
|
||||||
71
thesis.typ
Normal file
71
thesis.typ
Normal file
@@ -0,0 +1,71 @@
|
|||||||
|
#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
|
||||||
|
#lorem(512)
|
||||||
|
|
||||||
|
= 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
|
||||||
|
== Web client
|
||||||
|
== TUI client
|
||||||
|
|
||||||
|
= Evaluation
|
||||||
|
== Correctness
|
||||||
|
== Availability analysis
|
||||||
|
== Architectural evaluation
|
||||||
|
|
||||||
|
= Known problems and limitations
|
||||||
|
|
||||||
|
= Conclusions and future work
|
||||||
|
|
||||||
|
= References
|
||||||
Reference in New Issue
Block a user