Every idea raised for Stone Media Store, kept so none is forgotten, as the maintainer asked on 2026-11-04: "All of your suggestions should be in the backlog, not forgotten." Times are Detroit time. Each item says where it came from and whether the maintainer has said yes to it. An item here is an idea, not a decision.

The planning conversation is the thread of ocx-console run f0154f7c8b.

Sources

• The maintainer's note "Stone-Media: have a Gemini thread to capture some architecture ideas", in Backlog thoughts, Oct 1, 8:51 AM.
• That Gemini conversation, "Remote Media Serving, S3, WireGuard, and iOS Sync Architecture", posted whole in the planning thread as 3b6f5fc24c, Nov 4, 3:30 PM.
• Stone's own plan for media size, chronicle-readiness.md, "Repository growth discipline".

The goal, in the maintainer's words

From the Gemini conversation: "My goal was to use S3 to be able to synchronize media content to my phone, not necessarily stream. I'd seek to store it in the native applications and then reference, like Music, Photos, etc. I'd also seek to generate my own backups of things like Photos, pushing to my S3 server. Some content might live in cloud servers, whereas other content would just live on my home servers, available via local network when my phone is at home, and only via a tunnel when outside the home."

Nov 4, 3:33 PM: "On Stone, I think I'd want to play audio files from the Stone app. Ideally, I'd be able to add CarPlay to Stone to select those files for playing on the car UI."

Where the files live

• The files stay in S3; stone-media keeps one entry per file: its hash, size, type, date, which S3 store holds it and where in it. Fossil's sync keeps every copy of the entries current, and they can be searched as any Fossil repository. Proposed by the session, Nov 4; the maintainer hasn't said yes yet.
• Check each S3 file against its entry's hash. Session, Nov 4.
• Not chosen: the files as unversioned files in stone-media, with S3 as the server's disk. Every clone that syncs them would get every file, which is what Stone's plan warns of. Session, Nov 4.

First: the storage mechanism

The maintainer, Nov 4, 3:35 PM: "I'd think we'd get the storage mechanism working, before the presentation layer." Files go into an S3 store and get their entries in stone-media, shown working before anything shows them.

• The first real store is an AWS S3 bucket. The maintainer, Nov 4, 11:55 PM: "I'd start with an AWS S3 bucket." At 11:56 PM: "But, I'd eventually want to reach storage backed up on a home server." A home store comes later and speaks S3 the same way.
• Synchronize the stores, and know where each file has a copy. The maintainer, Nov 4, 11:56 PM: "And I'd want to synchronize them and keep track of where I have copies." So an entry is the file, and each copy (which store, where in it, when it was last checked against the hash) is a record of its own, added and never edited, so two places recording copies at once never overwrite each other. A sync step reads the entries, copies each file to the stores that lack it, and records each new copy. Session, Nov 4.
• Tests use a throwaway S3 server and a throwaway repository, so they need no real store. Session, Nov 4.
• Each entry as a tech-note, one per file, its id made from the file's hash, as Stone's journal keys its tech-notes (chronicle-readiness.md, contract 1). Proposed by the session, Nov 5; the maintainer hasn't said yes yet. The alternatives were one small file per entry in the tree, or one list file.
  • The maintainer, Nov 5, 2:55 PM: "1. maybe, but might want something a bit more custom. does it have the mimetype? searchable properly? taggable? extensible artifact cards?" Checked with Fossil 2.27: the note's mimetype is its text's format, so the file's type goes in a tag value; search covers title and text, not tags; tags can be added later, with values, without editing the note, so each copy can be a tag; unknown cards are refused. Stock Fossil can't choose a tech-note's id on creation (Stone patched its own), so a duplicate check is needed.
  • The "more custom" alternative: a ticket per file, with the repository's own fields; search covers them, and each change is a separate record (a value can be appended to a field, as copies would be).

Then: audio in Stone

The maintainer's choice of what Stone does first, Nov 4, 3:33 PM. Each step is to be shown working before the next.

1. stone-media lists the audio files, one entry each. The maintainer, 3:35 PM: "I need to dig them off a disk on an old computer."
2. Stone shows that list and plays a file: fetched from S3 when chosen, kept on the phone, playing with the screen locked, with the lock screen's play and pause. Stone plays no audio today; its Info.plist lets it run in the background only to fetch and process.
3. CarPlay shows the same list on the car's screen.
   • Apple shows an app in CarPlay only after granting it the CarPlay audio permission, which the holder of the Apple developer account requests from Apple. It can be requested while steps 1 and 2 are built.

Later

• Back up the phone's photos: Stone sends each new photo to an S3 store, adds its entry to stone-media, and it can be found by searching. The session's first recommendation, before the maintainer chose audio.
• Save downloaded photos back into Photos, which iOS allows. Gemini.
• Music: an app can't add songs to the Music app; audio plays in Stone, or goes to the Files app. Gemini.
• Bring files from home to the phone: an S3 store on a home server (MinIO, SeaweedFS or rclone serve s3), reached on home Wi-Fi first. Gemini; session.
• The way home from away: a WireGuard tunnel from home to a server on the internet, which passes requests through to the home store. Gemini.
  • The same address at home and away, the home network's DNS answering with the home store's local address. Gemini.
  • A proxy in front of S3 must pass the original Host header on, or S3's request signatures fail. Gemini.
  • WireGuard in Stone either as the phone's own VPN (Apple's Network Extension permission, and a prompt) or running inside the app alone, with no prompt. Gemini.
• Home and cloud stores under one set of names and one sign-in, some buckets on home disks and some passed through to a cloud provider. Gemini.
• Files app access through a WebDAV gateway to S3 (rclone serve webdav). Gemini.
• A cache on the internet server, keeping what was fetched from home. Gemini.
• Stone's own media: Stone's plan expects photos and audio to make up most of its journal repository; stone-media could hold them instead. From chronicle-readiness.md; not yet raised with the maintainer.