commit 6cac5e7c288100b143334ca9a8b5a1225515e857
Author: Gabriel Kaszewski <gabrielkaszewski@gmail.com>
Date:   Wed Jul 22 00:51:04 2026 +0200

    Add initial outline and thesis structure for decentralized music streaming platform

diff --git a/outline.md b/outline.md
new file mode 100644
index 0000000..adce38e
--- /dev/null
+++ b/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
diff --git a/thesis.typ b/thesis.typ
new file mode 100644
index 0000000..1555396
--- /dev/null
+++ b/thesis.typ
@@ -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
\ No newline at end of file