Add initial outline and thesis structure for decentralized music streaming platform

outline.md

@@ -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