Pandoc but extra AI steps.
This isn’t about replacing power-user workflows, it’s about giving anyone on your team the ability to reshape data and documents without ever opening a terminal. You getflexibility with the simple UX of renaming a file. Calling it “Pandoc plus AI” misses the fact that 90 percent of users neither know nor care about Pandoc’s internals. They just want “I have a file, make it look like this, or formatted with these sections to share with X person who works in X field...” and that’s exactly what our natural-language, filesystem-driven approach delivers.
I’ve definitely felt the pain of file formats in some unexpected ways recently.
Like airdropping a photo from iPhone only to discover a .HEIC file, which nothing will accept.
I’ve previously used “what ever turns up first on google”, but I now won’t for anything of significance (privacy)
I’ve recently discovered Automator (on Mac) and the quick actions menu. Which can achieve a lot of image and pdf related conversions, but takes some setup (not a mass market solution)
I like the idea of this product. But I think the challenge will be: - reaching the user at the moment they have this problem
- making your solution frictionless to solve their immediate problem, while also bootstrapping to solve it next time around (without them forgetting it exists)
If you can nail that experience for a single use case, I think this will be a winner.
I hate it if it's built with "AI". Can't imagine a use case for this apart from just shit you don't care about. Why would I be hoarding data I don't care about?
You’re using AI to create a transpilation of whatever modality. It’s a wasted step if the purpose is to feed back into AI.
What Im saying: If the point is to "convert this csv to markdown so i can feed the markdown to a LLM to ask questions about it" etc... it is a completely unnecessary step.
Your service is nothing more than:
1. augmented metadata for files; btw if that requires a whole new drive-oriented solution then you're doing too much.
2. llm api wrapper for a commoditized capability (custom format/or transpilation)
open it in a tool that understands the format,
export / paste the part I care about,
phrase an LLM prompt,
paste the result back,
do this all again if i want the data formatted differently for different use cases.
adding the ability to format your data and view/download that natively, fast is like giving python scripting capabilities to normal users. You're thinking like a dev not like a business owner who may want to take a picture of a timesheet and have that immediately become a CSV then have it reformatted for a management system they use, all on the fly through natural language... there's so many ways that normal people navigate files and formats and I want to give these people some superpowers that they won't seek out themselves.
the gpt-wrapper argument is so played out. just like you’d say “my app is a GPT-wrapper” (it wraps the OpenAI API in a file-centric UX), you could say “Google Drive is a distributed-storage-wrapper” or “a cloud-storage-and-sync wrapper.” It’s the polished frontend and glue that makes the raw backend useful to end users.
Basically treating one file type as if it were any arbitrary other file type
[0] https://en.wikipedia.org/wiki/Don_LaFontaine .. wow, dead for 17 years!
Am I missing something?
You could imagine something like `any2zip`, or `any2tgz` or `iso2mp4` or something.
It seems like there could/should be some sort of virtual filesystem where you could say "cat inventory.xls.csv", or "wine.exe excel.exe inventory.csv.xls" (please bear with me on these examples). Effectively "$BLOB.format.format", where "." becomes a sort of "convert to this $TYPE".
Imagine being able to say:
`echo "# Hello\n\n * World" > README.md ; cat README.md.html"`
(effectively invoking `md2html`)
`printer README.md.html.pdf`
(eg: `cat README.md | md2html | html2pdf | printer`)
...if you requested `README.md.pdf`, maybe it could intuit the intermediate `md2html2pdf` (HTML) portion?I really wish local linux filesystems (for end-users) would at least match Apple's capabilities. eg: `$RECENT`, spotlight, auto-OCR. We've really regressed since the era of `locate`, but I'd _LOVE_ some sort of modern equivalent.
Imagine: `inotify`, `auditd`, just anything that can avoid full-disk scans during "normal end user" daily operation... wired up to `llm-summary $FILE >> sqlite.db ; `llava-describe $IMAGE >> sqlite.db ; etc...`
For bonus points, catch anything missed with some sort of full daily/weekly backup operation. We're on the cusp of a much more intimate "partnership" with the compute boxes underneath our desks, but so much is getting sucked into the void of "the network is the computer".
[1]: compgen -c | grep 2 | grep -v '2$' | grep -v '\.2' | grep -v '2\.'
They're still around. A problem is loss of information on each conversion. For example, wav->mp3 loses info. Converting back (mp3->wav) won't get you the exact .wav you started with. Similar thing with file types supporting different resolution graphics, vector vs. bitmap, metadata being stripped, features in format A not supported in format B, etc.
Another problem is the explosion of M:N file format combinations. A possible fix would be a universal (?) in-between format, functioning as a container for [portions of a file] + whatever metadata was extracted from original. That way you can at least do conversions along the lines of video container formats, where container type is changed but video inside does not get decompressed/re-encoded. Or simular operations like extracting/shuffling pages in a pdf document.
All in all this is not an easy problem & therefore unlikely to be solved anytime soon.
edit: /s
I vibe-coded a demo of such a thing, with the idea of making game assets like textures/outdoor/wall.jpg etc. You can do it easily enough, but you need to be patient, and not particularly discerning.
"Files as Directories: Some Thoughts on Accessing Structured Data within Files"
Is this paper freely available somewhere?
Link found here: https://scholar.google.com/scholar?cluster=14832107127874645...
I want iTunes and Audiobookshelf and beets and Jellyfin, etc to all work on the same filesystem and media archive.
There are challenges.
That said, the website doesn't seem to work anymore. It just errors out.
♪ It's easy if you try No hell below us Above us only sky Imagine all the people Visualize whirled peas Ah ah ah oooo!
You may say I'm a dreamer...
gus_massa•1mo ago
I tried with a text file
and for some reason the convert version has 1 2 3 4 in the same row.gus_massa•1mo ago
alentred•1mo ago
grandslammer•1mo ago