Skip to content

Roadmap: Go-first Modular Media Downloader (Cross-platform Binary) #18

New issue
New issue
Open
Open
Roadmap: Go-first Modular Media Downloader (Cross-platform Binary)#18
@ddmoney420

Description

@ddmoney420
ddmoney420
opened on Jan 7, 2026

Roadmap: Go-first Modular Media Downloader (Cross-platform Binary)

Problem Statement

The current stack is Docker-first, requiring Docker Desktop/Engine on all platforms. While functional, this approach:

  • Adds complexity for end users (Docker dependency)
  • Increases resource overhead (Docker daemon + containers)
  • Limits deployment flexibility (requires container runtime)
  • Makes VPN integration opaque (abstracted through Gluetun)

Goal: Evolve toward a Go-native cross-platform binary that can run standalone (no Docker required), with containers as an optional deployment path.

Non-Goals

This roadmap explicitly does not include:

  • Illegal content guidance or piracy automation
  • Bypassing paywalls, DRM, or copyright restrictions
  • Hard-coded secrets or insecure defaults

Findings from Repository Analysis

Current Architecture Summary

Tech Stack:

  • VPN: Gluetun (containerized VPN client)
  • Download Client: qBittorrent (containerized torrent client)
  • Orchestration: Docker Compose
  • Monitoring: Prometheus + Grafana (optional profile)
  • Port Sync: gluetun-qbittorrent-port-manager

Strengths:
✅ Security-first design (kill switch via network namespace sharing)
✅ Cross-platform (Windows, Linux, macOS via Docker)
✅ Comprehensive documentation
✅ Package manager distribution (Homebrew, AUR, Chocolatey)
✅ Automated backups, monitoring, leak protection
✅ All 8 GitHub issues closed (project execution: excellent)

Constraints:
❌ Docker dependency (not everyone wants containers)
❌ Resource overhead (Docker daemon ~500MB+ RAM)
❌ VPN control abstracted (limited programmatic access)
❌ Torrent-only (no pluggable acquisition backends)

Community & Ecosystem Research

Comparable Projects

Project Language VPN Backends Architecture Notes
Sonarr/Radarr/*arr C# ❌ External Usenet, Torrents Standalone binaries Industry standard for media automation
autobrr Go ❌ External Torrents, Usenet Standalone binary Modern, updated Jan 2026
Gopeed Go + Flutter ❌ No HTTP, BitTorrent, Magnet Cross-platform GUI/CLI Modern download manager
Rain Go ❌ No BitTorrent Library + standalone Production-ready (put.io)
Bobarr Node.js ✅ Built-in Torrents Docker-only All-in-one with VPN

Key Insight: Most modern media automation tools are standalone binaries with external VPN integration, not Docker-first.

"Are Torrents Dead?" - Reality Check

Finding: Torrents are alive and growing in 2026:

  • ✅ 28 million daily users (source)
  • ✅ P2P market growing 8.24% YoY through 2030 (source)
  • ✅ Resurgence due to streaming fragmentation (source)
  • ✅ All major tracker sites still active in 2026 (source)

Alternatives Exist But Serve Different Niches:

  1. Usenet - Faster, more secure, paid (~$10-20/mo), better for automation (comparison)
  2. Private Trackers - Higher quality, exclusive content, invite-only, often torrents
  3. Debrid Services (Real-Debrid, Premiumize, AllDebrid) - Cloud-based, paid (~$3-15/mo), legal uncertainty (comparison)
  4. Direct Downloads (DDL) - File hosters, often lower quality/completeness

Verdict: Torrents remain the free, open, and most accessible method for P2P file sharing. Claim is false.

Go Library & Approach Report

A) Embed VPN Capabilities in Go

WireGuard in Go (Userspace)

Libraries:

  • wireguard-go - Official userspace WireGuard implementation by WireGuard LLC
  • wgctrl - WireGuard configuration protocol library

Feasibility by OS:

OS Feasibility Approach Privileges Notes
Linux ✅ High TUN device via /dev/net/tun CAP_NET_ADMIN Native support, best performance
macOS ⚠️ Medium Network Extension or utun Root or entitlements Requires system extension approval
Windows ⚠️ Medium Wintun driver Administrator Requires driver installation

Kill-Switch Strategy:

  • Create TUN interface (tutorial)
  • Use netns for network namespace isolation (Linux-only)
  • Routing table manipulation via netlink (Linux) or platform syscalls

Pros:
✅ Full control over VPN lifecycle
✅ No external dependencies
✅ Tighter integration with download logic

Cons:
❌ High complexity (crypto, key exchange, routing)
❌ Platform-specific code (macOS/Windows differ significantly)
❌ Privilege escalation required (root/admin)
❌ Maintenance burden (security patches)

Risk: High

OpenVPN in Go

Status: ❌ Not viable

No mature OpenVPN implementation exists in pure Go. Would require wrapping C libraries or spawning openvpn binary.

B) Delegate VPN to OS / External Process (Recommended)

Approach: Manage WireGuard/OpenVPN installed at OS level via Go process control.

Implementation:

  1. Detect existing VPN installation:

    • Linux: wg, openvpn binaries
    • macOS: /usr/local/bin/wg-quick, WireGuard.app
    • Windows: WireGuard service, OpenVPN GUI

  2. Control VPN lifecycle:

    // Example: Start WireGuard tunnel
cmd := exec.Command("wg-quick", "up", "wg0.conf")
cmd.Start()

  3. Health checks:

  4. Kill-switch via routing:

    // Linux: Block non-VPN traffic
exec.Command("iptables", "-A", "OUTPUT", "!", "-o", "wg0", "-j", "DROP").Run()

// macOS: pf rules
// Windows: Windows Firewall rules

OS-Specific Integration:

OS VPN Tool Control Method Kill-Switch
Linux wg-quick, systemd-networkd exec commands, D-Bus iptables/nftables
macOS WireGuard.app, wg-quick launchctl, exec pf (packet filter)
Windows WireGuard service Windows Service API Windows Firewall API

Pros:
✅ Lower complexity (leverage battle-tested VPN clients)
✅ Platform maintainers handle security patches
✅ User familiarity (same tools they already use)
✅ Easier debugging (standard VPN troubleshooting applies)

Cons:
⚠️ Requires VPN client pre-installed
⚠️ Platform-specific control logic
⚠️ Less control over VPN internals

Risk: Medium

C) Containerized Distribution (Optional Path)

Approach: Keep Docker/Compose support but make it optional.

Architecture:

Go Binary (daemon + CLI)
   ├─ Native mode: Direct VPN + download management
   └─ Container mode: Orchestrate Docker containers (current stack)

Implementation:

  • Detect Docker availability
  • If present: Offer "quick start" via docker compose up
  • If absent: Run in native mode

Parity Strategy:

  • Single config.yaml consumed by both native + container modes
  • CI tests both paths
  • Feature parity enforced via integration tests

Pros:
✅ Backward compatibility (existing users unaffected)
✅ Easy onboarding (Docker users get instant setup)
✅ Flexibility (user choice)

Cons:
⚠️ Dual maintenance burden
⚠️ Potential feature drift between modes

Recommended Architecture

Component Overview

┌─────────────────────────────────────────────────────────────────┐
│                     Go Binary Daemon                             │
│  ┌───────────────────────────────────────────────────────────┐  │
│  │                   API Layer (REST / gRPC)                  │  │
│  │  /health, /status, /jobs, /providers, /vpn                │  │
│  └───────────────────────────────────────────────────────────┘  │
│                             ▲                                    │
│  ┌──────────────────────────┴──────────────────────────────┐   │
│  │              Core Services                               │   │
│  │                                                          │   │
│  │  ┌───────────────┐  ┌─────────────────┐  ┌───────────┐  │   │
│  │  │  Job Queue    │  │   VPN Module    │  │  Notifier │  │   │
│  │  │  (Scheduler)  │  │  (Controller)   │  │ (Webhook) │  │   │
│  │  └───────────────┘  └─────────────────┘  └───────────┘  │   │
│  │                                                          │   │
│  │  ┌──────────────────────────────────────────────────┐   │   │
│  │  │        Provider Plugin Interface                 │   │   │
│  │  │  RegisterProvider(name, impl)                    │   │   │
│  │  │  GetProvider(name) Provider                      │   │   │
│  │  └──────────────────────────────────────────────────┘   │   │
│  │         │                  │                 │           │   │
│  │         ▼                  ▼                 ▼           │   │
│  │  ┌──────────┐      ┌────────────┐    ┌──────────┐      │   │
│  │  │  HTTP    │      │  BitTorrent│    │  Usenet  │      │   │
│  │  │ Provider │      │  Provider  │    │ Provider │      │   │
│  │  └──────────┘      └────────────┘    └──────────┘      │   │
│  │                                                          │   │
│  │  ┌──────────────────────────────────────────────────┐   │   │
│  │  │          State Store (SQLite / bbolt)            │   │   │
│  │  │  Jobs, Config, Metadata, Download State          │   │   │
│  │  └──────────────────────────────────────────────────┘   │   │
│  └──────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────┘
            │                              │
            ▼                              ▼
    ┌───────────────┐            ┌──────────────────┐
    │  VPN Client   │            │  Download Storage│
    │  (External)   │            │  /downloads      │
    └───────────────┘            └──────────────────┘

Provider Interface (Pluggable Backends)

package providers

type Provider interface {
    Name() string
    Download(ctx context.Context, req *DownloadRequest) (*DownloadJob, error)
    GetStatus(jobID string) (*JobStatus, error)
    Cancel(jobID string) error
}

type DownloadRequest struct {
    URL          string
    Destination  string
    Metadata     map[string]string
    Priority     int
    RetryPolicy  *RetryPolicy
}

type JobStatus struct {
    ID            string
    State         JobState // pending, downloading, completed, failed
    Progress      float64  // 0.0 to 1.0
    BytesDownloaded int64
    BytesTotal    int64
    Error         error
}

Built-in Providers:

  1. HTTP Provider (core, always available):

    • Resumable downloads
    • Checksum verification (MD5, SHA256)
    • Retry with exponential backoff
    • Multi-part downloads

  2. BitTorrent Provider (optional plugin):

  3. Usenet Provider (optional plugin, future):

    • NZB file handling
    • NNTP client

VPN Module Interface

package vpn

type Controller interface {
    Start(ctx context.Context, cfg *Config) error
    Stop(ctx context.Context) error
    Status() (*Status, error)
    HealthCheck() error
}

type Config struct {
    Provider   string // wireguard, openvpn
    ConfigPath string // /etc/wireguard/wg0.conf
    KillSwitch bool
}

type Status struct {
    Connected   bool
    PublicIP    string
    ServerIP    string
    UptimeS     int64
}

Implementations:

  1. EmbeddedWireGuard (uses wireguard-go):

    • For users who want pure-Go solution
    • Higher privilege requirements

  2. ExternalWireGuard (execs wg-quick):

    • For users with WireGuard already installed
    • Lower complexity

  3. Passthrough (no VPN, direct connection):

    • For testing or when VPN is managed externally

Configuration Strategy

Single source of truth: ~/.config/mediadownloader/config.yaml

server:
  host: 127.0.0.1
  port: 8080
  
vpn:
  enabled: true
  provider: wireguard
  config_path: /etc/wireguard/wg0.conf
  kill_switch: true
  health_check_interval: 60s
  
downloads:
  path: /downloads
  temp_path: /downloads/.tmp
  concurrent_jobs: 3
  
providers:
  http:
    enabled: true
    max_retries: 5
    chunk_size: 10MB
  
  bittorrent:
    enabled: false  # Optional
    port: 6881
    dht: true
    max_upload_rate: 1MB
  
  usenet:
    enabled: false  # Optional, future
    server: news.example.com
    port: 563
    username: ""
    password: ""
    
notifications:
  webhooks:
    - url: https://example.com/webhook
      events: [download_complete, download_failed]

No secrets in config file - Use:

  • Environment variables (WIREGUARD_PRIVATE_KEY)
  • OS keyring integration (Linux: Secret Service, macOS: Keychain, Windows: Credential Manager)

Data Flow

Scenario: User adds HTTP download via CLI

1. User: mediadownloader add --url https://example.com/file.zip

2. CLI → API: POST /api/v1/jobs
   {
     "provider": "http",
     "url": "https://example.com/file.zip",
     "destination": "/downloads/file.zip"
   }

3. API → JobQueue: Enqueue job

4. JobQueue → VPN Module: Check VPN status
   ├─ If not connected → Start VPN
   └─ If connected → Proceed

5. JobQueue → HTTPProvider: Download(req)

6. HTTPProvider:
   ├─ Create temp file: /downloads/.tmp/file.zip.part
   ├─ HTTP GET with Range headers (resumable)
   ├─ Write chunks → disk
   ├─ Update job status in StateStore
   └─ On complete: Move to /downloads/file.zip

7. JobQueue → Notifier: Send webhook (download_complete)

8. User: mediadownloader status
   → CLI → API: GET /api/v1/jobs
   → Display: [✓] file.zip (100%)

Threat Model & Security

Threat Mitigation
IP Leak (VPN drop) Kill-switch via firewall rules; downloads pause until VPN reconnects
DNS Leak Force DNS through VPN tunnel; configure resolver to 1.1.1.1 over tunnel
Credential Theft OS keyring for secrets; config file permissions 0600
Malicious Downloads Checksum verification; optional: VirusTotal API integration
MITM HTTPS for HTTP downloads; encrypted protocols for torrents/usenet
Unauth API Access API key auth (JWT tokens); optional: mTLS

Logging & Metrics

Structured Logging (JSON):

{
  "timestamp": "2026-01-06T19:00:00Z",
  "level": "info",
  "component": "vpn.controller",
  "message": "VPN tunnel established",
  "public_ip": "185.65.xxx.xxx",
  "server": "nl-ams-wg-001"
}

Metrics (Prometheus format):

# HELP mediadownloader_downloads_total Total downloads processed
# TYPE mediadownloader_downloads_total counter
mediadownloader_downloads_total{provider="http",status="success"} 42

# HELP mediadownloader_download_bytes_total Total bytes downloaded
# TYPE mediadownloader_download_bytes_total counter
mediadownloader_download_bytes_total{provider="http"} 1073741824

# HELP mediadownloader_vpn_connected VPN connection status
# TYPE mediadownloader_vpn_connected gauge
mediadownloader_vpn_connected 1

Optional: Grafana dashboards (reuse Prometheus setup from current stack).

Phased Roadmap

Phase 0: Preparation & Decision (2 weeks)

Goals:

  • Finalize VPN approach (embedded vs external)
  • Set up Go project structure
  • Create ADR (Architecture Decision Record)
  • Define acceptance criteria for MVP

Tasks:

  • Create ADR: VPN Strategy (embedded wireguard-go vs external wg-quick)
  • Create ADR: Provider Plugin Architecture
  • Create ADR: State Store (SQLite vs bbolt vs JSON files)
  • Set up GitHub repository structure: 
    /cmd/daemon    - Daemon entrypoint
/cmd/cli       - CLI client
/internal/core - Job queue, state store
/internal/vpn  - VPN controller implementations
/internal/providers - Provider implementations
/pkg/api       - Public API types
/docs/adr      - Architecture decision records
  • Add Makefile with targets: build, test, lint, release
  • Add GitHub Actions: go test, golangci-lint, multi-platform build
  • Update CONTRIBUTING.md with Go development guidelines

Acceptance Criteria:

  • ✅ ADRs approved by maintainers
  • ✅ CI pipeline green
  • ✅ make build produces binaries for linux/amd64, darwin/amd64, darwin/arm64, windows/amd64

Risk Mitigation:

  • If VPN approach undecided, prototype both (wireguard-go vs wg-quick) for 2-day sprint

Phase 1: MVP - Go Daemon + CLI + HTTP Provider (4 weeks)

Goals:

  • Cross-platform Go binary (no Docker)
  • HTTP downloads with resume/retry/checksum
  • Basic job queueing
  • Health check endpoints
  • NO VPN integration yet (defer to Phase 3)

Tasks:

  • Implement HTTP Provider:
    • Resumable downloads (HTTP Range headers)
    • Checksum verification (SHA256, MD5)
    • Retry with exponential backoff
    • Multi-part downloads (optional)
    • Progress reporting
  • Implement Job Queue:
    • FIFO queue with priority
    • Concurrent job execution (configurable limit)
    • Persistence (survive daemon restarts)
    • Status polling
  • Implement State Store:
    • SQLite or bbolt
    • Schema: jobs, config, metadata
    • Atomic updates
  • Implement REST API:
    • POST /api/v1/jobs - Add download
    • GET /api/v1/jobs - List jobs
    • GET /api/v1/jobs/:id - Get job status
    • DELETE /api/v1/jobs/:id - Cancel job
    • GET /healthz - Health check
    • GET /version - Version info
  • Implement CLI:
    • mediadownloader daemon - Start daemon
    • mediadownloader add <url> - Add download
    • mediadownloader list - List jobs
    • mediadownloader status <id> - Show job details
    • mediadownloader cancel <id> - Cancel job
  • Configuration:
    • Load config.yaml from XDG dirs
    • Environment variable overrides
    • Default config generation
  • Cross-platform build:
    • make release - Build for all platforms
    • Release artifacts: tar.gz, zip with binaries

Testing Strategy:

  • Unit tests: 80%+ coverage for core packages
  • Integration tests: Full download lifecycle (HTTP server → job → disk)
  • End-to-end test: CLI → API → Download → Verify file

Acceptance Criteria:

  • ✅ mediadownloader add https://example.com/file.zip downloads file successfully on Linux, macOS, Windows
  • ✅ Downloads resume after daemon restart
  • ✅ Checksum failures abort download
  • ✅ API returns 200 OK on /healthz
  • ✅ make test passes 100%
  • ✅ CI builds for all platforms

Complexity: Medium

Risks:

  • Platform-specific file I/O issues → Test on all OSes early
  • Concurrency bugs in job queue → Thorough unit tests with race detector

Mitigation:

  • Run go test -race in CI
  • Manual testing on macOS, Linux (Ubuntu), Windows 11

Phase 2: Plugin Framework + Optional BitTorrent Provider (3 weeks)

Goals:

  • Formalize provider plugin interface
  • Optional BitTorrent support (pluggable)
  • Webhook notifications

Tasks:

  • Refactor providers to plugin architecture:
    • Define Provider interface (see architecture above)
    • Provider registration system
    • Provider discovery (scan /providers/ directory for .so files)
  • Implement BitTorrent Provider (optional plugin):
    • Wrap anacrolix/torrent
    • Support magnet links + .torrent files
    • Seeding policies (seed ratio, time limits)
    • DHT + PEX support
    • Port configuration
  • Webhook notifications:
    • POST /webhook on events: download_complete, download_failed, download_started
    • Configurable webhook URLs in config.yaml
    • Retry failed webhooks (3 attempts)
  • API extensions:
    • GET /api/v1/providers - List available providers
    • GET /api/v1/stats - Download statistics
  • CLI extensions:
    • mediadownloader providers - List providers
    • mediadownloader add --provider bittorrent magnet:?xt=...

Testing Strategy:

  • Plugin isolation tests (ensure HTTP provider works without BitTorrent)
  • BitTorrent integration test (seed test torrent, download, verify)
  • Webhook delivery tests (mock HTTP server)

Acceptance Criteria:

  • ✅ HTTP provider works without BitTorrent installed
  • ✅ BitTorrent provider downloads test torrent successfully
  • ✅ Webhook fires on download completion
  • ✅ mediadownloader providers lists: http, bittorrent
  • ✅ All tests pass

Complexity: Medium

Risks:

  • BitTorrent library complexity → Start with basic magnet support
  • Plugin interface too rigid → Design for future Usenet/DDL providers

Phase 3: VPN Module + Policy Controls (4 weeks)

Goals:

  • VPN lifecycle management (start, stop, health check)
  • Kill-switch implementation
  • Policy controls (VPN-only downloads)

Tasks:

  • Implement VPN Controller interface (see architecture above)
  • Implement ExternalWireGuard Controller:
    • Detect wg-quick binary (Linux/macOS/Windows)
    • Start tunnel: wg-quick up <config>
    • Stop tunnel: wg-quick down <config>
    • Health check: Ping gateway + check public IP
    • Auto-reconnect on failure
  • Implement Kill-Switch:
    • Linux: iptables rules 
      iptables -A OUTPUT ! -o wg0 -j DROP
iptables -A OUTPUT -o wg0 -j ACCEPT
    • macOS: pf rules
    • Windows: Windows Firewall API
  • VPN-aware download policies:
    • require_vpn: true in config → Block downloads if VPN down
    • Pause active downloads on VPN disconnect
    • Resume downloads on VPN reconnect
  • API extensions:
    • GET /api/v1/vpn/status - VPN connection status
    • POST /api/v1/vpn/start - Start VPN
    • POST /api/v1/vpn/stop - Stop VPN
  • CLI extensions:
    • mediadownloader vpn status
    • mediadownloader vpn start
    • mediadownloader vpn stop
  • (Optional) Embedded WireGuard Controller:
    • Use wireguard-go
    • TUN interface creation
    • Route manipulation
    • Platform-specific (start with Linux)

Testing Strategy:

  • Mock VPN tests (simulate wg-quick failures)
  • Integration test: Start VPN → Download → Stop VPN → Verify kill-switch
  • Platform-specific tests (Linux, macOS, Windows)

Acceptance Criteria:

  • ✅ mediadownloader vpn start brings up WireGuard tunnel
  • ✅ Downloads proceed only if VPN connected (when require_vpn: true)
  • ✅ Kill-switch prevents IP leak (verified via curl to ipify.org)
  • ✅ Downloads resume after VPN reconnects
  • ✅ Works on Linux, macOS, Windows

Complexity: Large

Risks:

  • Platform-specific firewall APIs diverge → Abstract behind interface
  • Privilege escalation issues → Document sudo requirements clearly
  • Kill-switch bypasses → Thorough security testing

Mitigation:

  • Security audit of kill-switch implementation
  • Penetration testing (try to leak IP)
  • Clear documentation on limitations per OS

Phase 4: Optional Features (Backlog, 2-4 weeks each)

These are future enhancements, not part of MVP:

A) Web UI Dashboard

  • React/Vue SPA
  • Real-time progress updates (WebSocket)
  • Drag-and-drop torrent/magnet links
  • Mobile-responsive

B) Usenet Provider

  • NZB file parsing
  • NNTP client implementation
  • Par2 verification + repair
  • Integration with indexers (NZBgeek, etc.)

C) Debrid Service Integration

  • Real-Debrid API client
  • Cached torrent instant downloads
  • Premium link generator

D) Enhanced Automation

  • RSS feed monitoring (like Sonarr/Radarr)
  • Torrent indexer integration (Prowlarr-compatible API)
  • Auto-organize downloads (TV shows, movies)

Container Support Strategy

Option 1: Hybrid Binary (Recommended)

The Go binary detects Docker and offers both modes:

# Native mode (no Docker)
mediadownloader daemon

# Container mode (uses current Docker stack)
mediadownloader daemon --mode=docker

Implementation:

  • Check for Docker socket: /var/run/docker.sock
  • If present: Offer quick-start with docker compose up
  • If absent: Run in native mode

Option 2: Separate Distributions

  • Standalone binary: For users who want Go-native
  • Docker Compose: For users who prefer containers

Both consume same config.yaml format.

Open Questions (Requires User Input)

Before proceeding, clarify:

  1. VPN Approach Decision:

    • ⚠️ Embedded WireGuard (wireguard-go) - Full control, higher complexity
    • ✅ External WireGuard (wg-quick) - Lower complexity, requires pre-install (RECOMMENDED)
    • ❓ Your preference?

  2. BitTorrent Priority:

    • High priority (Phase 2) or defer to later?
    • Torrent-only or also support HTTP/DDL?

  3. Container Backward Compatibility:

    • Must maintain Docker stack forever?
    • Or deprecate after Go binary matures (with migration guide)?

  4. Release Timeline:

    • Aggressive (MVP in 2 months)?
    • Conservative (MVP in 4 months with more polish)?

  5. Testing Requirements:

    • CI must pass before ANY merge (strict)?
    • Manual QA acceptable for platform-specific features?

Deliverables Summary

Phase 0 Outputs:

  • ADRs (VPN, plugins, state store)
  • Go project structure
  • CI/CD pipeline
  • Cross-platform build system

Phase 1 Outputs:

  • Go binary (daemon + CLI)
  • HTTP provider with resume/retry/checksum
  • Job queue + state store
  • REST API + health endpoints
  • Binaries for Linux, macOS (Intel/ARM), Windows

Phase 2 Outputs:

  • Provider plugin interface
  • Optional BitTorrent provider
  • Webhook notifications
  • mediadownloader providers CLI

Phase 3 Outputs:

  • VPN controller (external WireGuard)
  • Kill-switch (per OS)
  • VPN-aware download policies
  • mediadownloader vpn CLI

Phase 4 Outputs (Future):

  • Web UI dashboard
  • Usenet provider
  • Debrid integration
  • RSS automation

Success Metrics

  • ✅ Binary runs on 3 platforms (Linux, macOS, Windows) without Docker
  • ✅ Zero IP leaks in kill-switch tests (verified with ipify.org checks)
  • ✅ 80%+ test coverage on core packages
  • ✅ CI green for all commits to main
  • ✅ Migration guide for existing Docker users
  • ✅ 100% API parity between native and container modes (if hybrid approach)

Competitive Analysis: Why This Matters

Gap in Market: No mature, Go-native, VPN-integrated download manager exists that combines:

  • ✅ Cross-platform single binary
  • ✅ Built-in VPN lifecycle management
  • ✅ Pluggable acquisition backends (HTTP, torrents, usenet, debrid)
  • ✅ Security-first defaults (kill-switch, no secrets in config)

Closest Competitors:

  • *arr stack (Sonarr/Radarr): No VPN management, media-focused
  • Gopeed: No VPN, no automation
  • autobrr: No VPN, IRC autodl focus
  • Bobarr: Docker-only, Node.js, limited adoption

This project fills the gap for users who want:

  • A self-hosted, lightweight, binary-first solution
  • VPN control without manual setup
  • Flexibility (torrents optional, not required)

Resources & References

Self-Hosted Ecosystem

Torrent/Usenet Landscape

Go Libraries

VPN Implementation

Debrid Services

Next Steps

  1. Review & Feedback: Maintainer review of this roadmap (1 week)
  2. Decision on Open Questions: VPN approach, priorities, timeline
  3. Phase 0 Kickoff: ADRs, project structure, CI setup (2 weeks)
  4. Ongoing: Execute phases sequentially with milestone releases

Labels: roadmap, enhancement, architecture, go, discussion

Assignee: TBD

Milestone: v2.0.0 - Go-Native Rewrite

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions