Inbox-style PKM app — input funnel + iOS sync challenge (2026-05-10, 14:07)

Same-session follow-up to 2026-05-10-Voice memo workflow frustration - Monologue, Shortcuts, Working Copy, Zettel (~7 min earlier): rant about the current rig turns into a product-idea outline. The app is framed as a Zettel-style funnel (voice / photo / text in) → AI processing in the user’s existing Obsidian vault style → second-tier chat over the data → exposed as skills to outside agents (e.g. Claude). Cross-platform with iOS/macOS preferred. Open data-format question: pure markdown files don’t survive iOS file-handling well, so the document might be markdown structured but stored differently and synced through a custom engine. Sits with the standalone-PKM-app trio of 5/6 (cons, Cursor SDK, yjs stack) — same project track, different angle.


Voice Transcript

Recorded: May 10, 2026 at 2:07 PM


Like maybe one app idea that I could build would be to create my a a an app that’s basically an inbox like settle where you can type or where you can speak, should be easy to input anything really, kind of like a funnel. And then you have AI let it process it like it’s currently being done with my obsidian vault. So yeah, it would be an app basically working as my tool for thought and the main feature or well the most important thing is getting information in and you can do that by talking or by doing making a making a photo or by just writing really anything. that’s also kind of the main UI. I think that would be useful. And then the second level is that you can interact with that data and well ask questions, make it write reports and stuff. And then also have it basically expose all of that functionality that you would get via the in app chat, I guess to other services. So, for example, can connected to clode or stuff, so you have these skills that get exposed, so you can use it with your AI of choice and the data is not locked away. And well, the app basically is crossplatform, I think it should be, even though I would prefer iOS, MacOS native. And then about the data format that one is kind of hard because like just simple text markdown files would be great for data conversion, basically keeping things into eternity, but I guess this app just wouldn’t work that well with that format because on iOS and well, on iOS file handling is really bad, so it couldn’t be real actual markdown files. I mean the documents themselves could be structured in markdown, I guess that makes sense, but they should not be actual markdown files in the iOS app, I guess. Does that make sense? Not sure. Because yeah, I feel like sync would be hard, but you could do that if yeah. Yeah, synchronization would be hard, I guess. would have to roll your own sync engine. Even then it would be kind of a bad experience. I guess.

Oh man, it’s just so annoying. Come on.


How this fits the standalone-PKM-app track

Maps neatly onto the six challenges named in the 5/6 parent memo (2026-05-06-Standalone PKM app - cons of Obsidian setup, sync, UI focus):

Challenge (5/6)Position taken here (5/10)
#1 CostOut of scope in this memo — the “expose skills to your AI of choice” line suggests the user still pays for inference upstream.
#2 SyncAcknowledged as the hard problem: “synchronization would be hard, I guess. would have to roll your own sync engine. Even then it would be kind of a bad experience.” Doesn’t pick a stack, but 6 is the standing candidate.
#3 Local-first markdown vs. databasesExplicit pivot: “documents themselves could be structured in markdown, I guess that makes sense, but they should not be actual markdown files in the iOS app, I guess.” Markdown as format, not as on-disk file.
#4 UI”the main feature or well the most important thing is getting information in” — UI is the funnel; chat is “the second level.” First memo in this track to give the UI a clear shape.
#5 Core loopImplicit: capture → AI process (mirroring the current Obsidian vault loop) → query (chat over the data) → reports.
#6 Cloud routinesNot addressed — same gap 6 memo also left open.

New axis not in the 5/6 trio: skills as the public API — “expose all of that functionality that you would get via the in app chat … to other services. So for example, can connected to clode or stuff, so you have these skills that get exposed, so you can use it with your AI of choice.” The app’s value moves out of the app over MCP/skills; data isn’t locked away.

Open questions

  • Storage format if not .md on disk — SQLite-with-markdown-column? An opaque blob with markdown payload? CRDT doc with markdown serialization?
  • “Expose skills to your AI of choice” — does this mean MCP server, a plugin protocol, or both? The MCP-server framing aligns with Kumo’s “filesystem-like tools” surface, and could be a clean overlap.
  • iOS file-handling — concretely which limitations push away from real .md? (Background access, multi-app sandbox handoff, Files-app reliability — would help to enumerate.)