There's a "type" field in the spec, defined as: "The UTI of the text.* file. E.g. set to net.daringfireball.markdown for Markdown. This field should default to net.daringfireball.markdown to be backwards-compatible with version 1."
So it's whatever you care to specify. Doesn't have to be Markdown at all. It looks like it'd be completely valid to use this as a way to bundle up a webpage with all associated images and scripts, for instance.
It just means "the description written by Gruber at his domain." The Perl script is just a convenience (if one can call Perl convenient...) for the curious.
Anyone else's flavor of Markdown can be used by specifying its identifier, e.g. "com.github.markdown.v3" (I made that up, it's not a real thing AFAIK)
It seems fine to me. If your app is using weird edge cases of markdown syntax, or extensions, it should probably specify a different UTI. If you’re pretty much just doing the level of markdown in the average rich-notes app, that’s pretty interoperable.
Spread the word. Unfortunately Obsidian and Devonthink (and many other apps) don’t yet support this format. But it solves a really important problem: How to exchange markdown documents that include attachments like images, video etc. in a standard way?
> But it solves a really important problem: How to exchange markdown documents that include attachments like images, video etc. in a standard way?
Oddly enough, I was recently thinking of using RFC 822 messages with CommonMark bodies and MIME attachments as a way to store blog entries on disk, so I was considering this exact problem earlier this week (small world!). RFC 2046 specifies multipart messages, RFC 2392 specifies URI schemes for linking from the body of the message to other parts; and RFC 7763 specifies the text/markdown MIME type. There’s already a ton of tooling out there which deals with MIME, so one needn’t reinvent the wheel.
Coming from Linux where your Filesystem is your database and I use obsidian because I can pop it over a file tree and have my vault integrated into the rest of my system, something like textbundle seems like alien and missing the point.
I like the general concept of sandboxing applications, but if it leads to this, it's more hindering than helping.
Reading the site and spec, it sounds like TextBundle is specifically for exporting and importing your Markdown (or other documents) to and from various apps or other users. In particular, it's needed for software in the Apple ecosystem because there are (apparently) strict rules on how applications can communicate with each other.
Personally, I was hoping TextBundle would be something like a standard format for inserting binary content into Markdown files. (Something better than just base64, anywho.) I could use such a thing for my home-grown wiki.
Relying on markdown links to local images works well on my machine, but breaks as soon as I'd like to share that markdown file with someone else.
Sure, I can zip everything and send them over, but it's not as friendly for recepient as receiving a document handled by popular viewers, specially if they have to modify it and send it back.
With wide adoption of something like TextBundle, we get to have our cake (keep using plain text) and eat it too (send, view, and edit richer files).
I've never had the usecase of sending markdown with images attached.
I use markdown for personal notes and in the rare case I shared them in the past, either there were no (relevant) links or I shared with e.g. confluence and I could just add the image.
My other usecase for markdown is Readmes and those are shared in git including the files.
I understood this spec mostly for sharing with local apps. Is that a missed usecase by me? Markdown documents instead of word/pdf/powerpoint/whatnot?
That's what I meant. My experience is that if I link notes in obsidian I can't read it in any other text editor. And the opposite.
Most recently I tested this with obsidian, ia writer, obsidian.nvim, fsnotes, and a few others I forget the name of.
Especially if you want to access your notes on mobile and have a good syncing experience... you're out of luck if you want a non-proprietary format. Only notion and apple notes had reliable syncing.
Obsidian may avoid the problem well enough, but it’s been my experience that connected pieces of information that aren’t coupled very tightly indeed have a way of eventually becoming separated and never re-united. Goes for information in computer systems and for physical records/photos/objects.
I spent a lot of time investigating all the editors on this list because I want a rich text editor that works with single files and is as clean powerful as VS Code (or sublime, emacs, whatever you prefer). Didn't end up using any of them since nobody else uses this format. Went back to .docx. Sad.
I am hungry for something new, but Word is probably the most popular text editor in the world. If I am writing just for myself, I will most likely use markdown or maybe Typst. If I am to collaborate on it with others, it will probably be .docx or Google Docs.
TextBundle brings convenience back - by bundling the Markdown text and all referenced images into a single file
... So basically a markdown version of the ePub format?
Slightly related, but Typora offers an option that handles inlined media for a markdown note in a pretty sleek way. It creates a folder in the same location as the markdown note with following syntax (markdown-file-name.assets). Any time you drag/copy/etc a image/video/etc into the markdown editor it copies the file into the asset folder.
I don't have a MacBook or know anything about how their packaging works, but it seems like it's pretty well documented, maybe even better than a lot of package formats
It doesn't seem like it would be that preferable to other package formats given how platform specific it is. The ZIP-based version of the TextBundle spec (aka TextPack) seems far more generally useful to me given the ubiquity of ZIP as a cross-platform package format.
I was under the impression that the Gruber original at https://daringfireball.net/projects/markdown/ wasn’t well enough specified (unless you want to treat a 20 year old Perl script as a specification) to be interoperable - hence efforts like https://commonmark.org/