explaingit

racuna/filepodsyc

Analysis updated 2026-05-18

0PythonAudience · developerLicense

TLDR

A serverless protocol for syncing podcast subscriptions and playback across devices using a shared folder instead of a server.

Mindmap

mindmap
  root((FilePodSync))
    What it does
      Serverless podcast sync
      Folder-based protocol
    Tech stack
      JSON files
      Dropbox
      Syncthing
    Use cases
      Cross-device podcast sync
      Client implementations
    Audience
      Developers
      Podcast app builders

Code map

Detail Auto

An interactive map of this repo's files and how they connect — its source is parsed live in your browser. Click Visualize to build it.

filefunction / class

What do people build with it?

USE CASE 1

Sync podcast subscriptions and listening progress across devices without running a server.

USE CASE 2

Use an existing file-sync tool like Dropbox or Syncthing as the backend for podcast sync.

USE CASE 3

Build a podcast app client that implements the FilePodSync protocol.

What is it built with?

JSONDropboxSyncthing

How does it compare?

racuna/filepodsyc0xhassaan/nn-from-scratch3ks/embedoc
Stars00
LanguagePythonPythonPython
Last pushed2023-06-08
MaintenanceDormant
Setup difficultymoderatehard
Complexity4/51/5
Audiencedeveloperdeveloperdeveloper

Figures from each repo's GitHub metadata at analysis time.

In plain English

FilePodSync (FPS) is a protocol specification and reference implementation for syncing podcast subscriptions and playback state across multiple devices, without needing a server. The problem it solves is that existing podcast sync tools like gPodder.net, Nextcloud-gPodder, and oPodSync all depend on a running server somewhere, which is fragile to maintain and requires technical expertise to self-host. FilePodSync replaces the server with a plain folder that any file-syncing service can replicate: Dropbox, Syncthing, Google Drive, Filen, iCloud, or a NAS (a personal home file server). The sync state lives entirely in a set of JSON files inside that shared folder. There is no API, no OAuth login, and no server software to run. Each device writes only to its own files and reads from all devices' files when merging. For subscriptions and episode states (like play position or "played" status), the protocol uses a strategy called Last-Write-Wins at Element Level: each record carries a timestamp, and the most recent change to any individual episode wins when two devices disagree. For the playback queue, the list of episodes you plan to listen to next, it uses an operation log instead, because "last write wins" would silently drop episodes added offline on one device. To handle offline edits safely, the sync cycle tracks three states: the last version written to disk, a merged version combining that with any changes from other devices, and a final version that layers the user's own unsaved actions on top. This ensures that a pause or subscription made while offline is not overwritten when the device reconnects. The full README is longer than what was provided.

Copy-paste prompts

Prompt 1
Explain how FilePodSync avoids needing a server for podcast synchronization.
Prompt 2
What is Last-Write-Wins at Element Level and why does the playback queue use something different?
Prompt 3
Walk me through how offline edits are merged when a device reconnects.
Prompt 4
How would I implement a client that supports the FilePodSync v1.3 spec?

Frequently asked questions

What is filepodsyc?

A serverless protocol for syncing podcast subscriptions and playback across devices using a shared folder instead of a server.

What language is filepodsyc written in?

Mainly Python. The stack also includes JSON, Dropbox, Syncthing.

Who is filepodsyc for?

Mainly developer.

Open on GitHub → Explain another repo

This repo across BitVibe Labs

Verify against the repo before relying on details.