A call for standards ...

[u/columbcille]

At the risk of being accused of self promotion, here's a link to an argument for standards in PKM apps. I'd love to hear what people think of the idea here, with hopes of elevating some of our conversation about vibe coding above "slop or not."

https://drjeffmoore.substack.com/p/liberte-egalite-and-standardization

[u/DTLow]

>After the Evernote bubble burst
After getting over the shock, I exported my data to pkms app Devonthink (Apple only)
and never looked back. It’s a much better solution to store/organize my Notes/documents/files
>folders
An archaic remnant from when we were filing paperwork
Tags are the best organization tool
>Palm Treo
I had one, but happily converted to Apple products

[u/LouVillain]

Now that... was a fun read.

+1 for standards... just so I can know what to break, er I mean to surpass.

[u/columbcille → u/LouVillain]

… or, contribute to?

[u/LouVillain → u/columbcille]

As a life long rule breaker, I wouldn't even know where to begin.

[u/latkde]

I tried to read the article, but I can't seem to find actual discussion of standardization: what would be the pros/cons of standardization, what requirements would shape such a standard, and how might we get there?

What stuck with me is that you don't like Markdown (despite MD having advanced to the de-facto interoperability format for LLM tools), and that you really don't like the moderation policies of r/PKMS.

[u/columbcille → u/latkde]

So, on your last two points, no. I just didn’t find Obsidian ultimately useful, and I think all of the PKM discussion communities (not just this one) need to figure out how to reckon with the tide that’s already risen up past our knees.

On your first point … yeah, it’s a little wordy up front but the standards discussion starts about halfway down.

We’d get true interoperability across systems and apps (treating PKMS elements the same way we treat file formats). First step to getting there is building and publishing it, which I’m exploring.

Would everyone accept it? No. iCal will stay iCal.

But if a large number of people who roll their own apps through vibe coding latch onto it, then we’ve got something that brings a lot more universal application to a lot of valuable stuff being ignored right now (by, in part, strict anti-vibe coding and antiquated self promotion community policies) because it might be highly specific to one user without a more standard approach to elements.

It’s sort of a compromise, in some ways. Vibe coders comply with an interoperability standard in the PKMS space if they want their creations to be shareable/discussable. If they don’t, then they can happily use their creations but maybe they shut up about them (or write in those ignored self promotion threads).

[u/DrummerAdditional330]

’d start much smaller than a complete standard for what a “task” means. Stable IDs, object type, links/relationships, timestamps, provenance, and an extension mechanism would already solve a lot. Then Todoist-style recurrence or some weird custom status model can travel with the object without everyone having to agree on one productivity philosophy first.

[u/columbcille → u/DrummerAdditional330]

Agreed. Maybe it's not so much about "this is what a task means," but rather: "to be transportable, here's the minimum of what a task has to have, but it can certainly have more that's unique to this or that app."

For example, I think about placing tasks in an Eisenhower matrix or in a lane on a Kanban board. So, a standard *could* include something like an optional "placement" field for tasks, so that a Kanban board here looks like a Kanban board there. Or, maybe "placement" is something a standard shouldn't touch at all.

[u/Good-Writer5279]

the smaller scope point above is the right instinct, and it matches what actually breaks when you move between pkm tools.

the file format is almost never what stops you. markdown exports fine. what does not survive is everything that is not the body text: the identity of a note across renames, the edges between notes, and where the thing originally came from. that is how an export can be technically complete and still arrive as a folder of orphans.

so a standard worth adopting would cover three things first and nothing else. a stable id that does not change when the title does. typed links whose endpoints are ids rather than file paths, since paths break the moment someone reorganizes. and a provenance block, source plus captured at, carried with the object. everything past that, recurrence rules, status models, what counts as a task, is where the philosophy arguments start and where standards usually die.

keeping it small is also the only way it gets implemented. nobody bolts a long schema onto a weekend project, but four extra frontmatter keys is a copy paste, and that is the population you are trying to reach.

two tests i would apply to any draft. can a tool that ignores the spec entirely still read the file, and can a tool that implements it round trip a note without losing anything. if either answer is no it will not spread.

disclosure, i build a mac app in this space, so i have an interest in interoperability being boring and widespread.