JSON --format type?

[hunterunger]

I think the most useful export format would be json for automation tasks.
Would this be possible to add easily? Even a very basic version?

[ReagentX]

I'm happy to work on this if there's enough interest, but we must think about what a feature-complete JSON export would look like. Can you provide some examples?

[ReagentX]

I can of course just serialize the data in each message struct, but that doesn't account for replies/threads, attachments, sticker types, edits, and many other standard iMessage features.

[hunterunger]

Even that would be very useful to me.

What about just including the relevant keys to each message. Would that generally cover replies, attachments, and stickers? Like so:

"messages": [
   {
      ...
      "guid": "8E1628CD-C7E9-455D-A401-4493B4D86C0F",
      "associated_message_guid": null,
      "text": "Can you pick up decaf beans while you're there?",
      "attachment": null,
      "subject":  null
   },
   {
      ...
      "guid": "3E1628CD-C7E9-455D-A401-4493B4D86C0B",
      "associated_message_guid": "8E1628CD-C7E9-455D-A401-4493B4D86C0F",
      "text": "",
      "attachment": "attachments/abc.heic",
   },
]

[ReagentX]

If you want to do that, you could just use serde on the Message struct. That said, I'm not sure what value JSON export provides at all.

I only want imessage-exporter to provide exporters that contain human readable, full featured data. I wrote this project with the library as a separate crate so people could leverage it the way you describe.

[hunterunger]

Ok. I'll try that.
I'll also look around the docs and learn about identifying chatrooms names and participant addresses/phone numbers.

[ReagentX]

FYI, see #62.

[tewe]

I'm not planning on automating anything and will probably never look at the export (as a human). I just want a lossless backup, in case those assumptions are wrong.

iMazing cannot provide that (local time, no addressee, ...). I did not try RSMF as that would require paying for a full year.

I used PhoneView for ten years, but that stopped working with the wonderful iOS 26. Its format was XML. That would map straight to JSON.

<SMSMessage>
  <Kind>Sent</Kind>
  <DateTime>2021-04-27 22:39:18 +0000</DateTime>
  <Name>Some Person</Name>
  <Number>that.person@gmail.com</Number>
  <Type>iMessage</Type>
  <Message>Hi</Message>  # XOR
  <Message File="Attached April 2021.pdf"></Message>
</SMSMessage>

It doesn't seem to cover all the features imessages-exporter supports. But then I never use threads or even groups.

[ReagentX]

If you want a lossless backup, it's best to just keep the original files around (macOS Messages directory, iOS backups, etc).

[tewe]

For some apps I just use their internal SQLite. But I don't want to rely on still being able to decrypt that in ten years. I'll try crabapple.

Sometimes the SQLite schema is also so complex that I don't expect to understand it in ten years. Especially if the code that created it is no longer available to test against. Then a simpler export format is great.

Please note that this is a discussion, not a GitHub issue. Thanks a lot for publishing imessage-exporter as it is!

[hellodigua]

Hi ReagentX,

I've been following the discussion about JSON support. I'm the developer of ChatLab (https://github.com/hellodigua/chatlab), which is an open-source tool for analyzing personal chat history. We've managed to reach over 5k stars in less than 3 months since we launched, and adding iMessage support is a feature requested by some of our users. I think your project is the most robust extraction tool available for this.

I understand your preference for keeping the CLI focused on human-readable formats while letting devs use the library for data tasks. The catch is that many of our users aren't developers—they can run a command, but they aren't going to write a wrapper. Without a structured CLI output, every downstream tool has to either re-parse HTML/txt or re-implement the extraction logic.

Would you be open to a basic JSON option? Even just a stable schema for fields like guid, timestamp, sender, and text would be a huge help for the community. I'd be happy to list your tool as the recommended data source in our documentation if we can make this work.

What do you think?

[hellodigua]

To be honest, I was mainly hoping for a standardized output because I'm just a bit lazy, but I totally get where you're coming from. I'll probably look into building a small JSON exporter based on your library crate instead, provided it's fairly straightforward.🤣
Appreciate the suggestion!

[ReagentX]

What does a feature-complete JSON export look like?

[hellodigua]

That’s a tough one to answer. From the ChatLab side, I’m always leaning towards a universal format, but I totally see the hard —iMessage has so many unique features that keep changing, so a "perfect" format is basically not exist.

But I really think "perfect" is the enemy of the good here. TXT loses all the structure, and HTML is just too hard for other apps to read reliably. To be honest, I was mainly hoping for a standardized output because I'm just a bit lazy lol, but I get where you're coming from. In my view, even a very simple JSON that misses some complex features would be a massive upgrade over what's currently available.

I've actually been drafting a spec for a standard chat format myself (v0.0.1) to handle imports from multiple platforms: https://chatlab.fun/en/docs/chatlab-format.md.

If we could just get those core fields into a stable JSON output, it would solve 90% of the friction for anyone wanting to build on top of your extraction work.

I'm not exactly a professional developer, so the spec might not be industry standard or have much reference value, but it's what's driving my project. I figured it's better than nothing to show you what we're aiming for.

[ReagentX]

My issue with that spec is the same issue I have with trying to build a JSON schema for imessage-exporter, message content in general is dangerously underspecified; heterogeneous message content is the hard problem. In practice, every implementer will invent their own convention and interoperability collapses.

Further, JSON assumes flat message sequences; without a thread/channel model, you cannot actually represent most types of conversations.

[hellodigua]

Fine. I think the root of it is just that you’re a perfectionist pursuing best practices, while I’m more inclined to get something basic working first and then iterate based on user feedback.

Anyway, thanks for the chat. I'll probably try to build a small wrapper with your library crate.