Live data from Hacker News

It's virtually impossible to read old iMessages and they take up tons of storage

keydiscussions.com

151–160 of 276 posts

Re: It's virtually impossible to read old iMessages and they take up tons of storage

#151

On a similar note, deleting old photos to save space on iCloud is very hard. I could mass-delete photos older than a certain date in the Mac Photos app (or whatever its called these days) using a smart album, but then that mass deletion would not sync to iCloud. Or, I could log into iCloud via a web page and select a load of photos (but not more than 1000 at a time) and delete them - but then it takes ages - like abo…

Sync for some reason hasn't been working for a decade. It never gets fixed - very weird for a trillion dollar company.

Take a photo on you iPhone and it take days for i to show up in the photos app, it instantly shows up in iCloud accessed through the browser.

Same thing in various other directions, delete on web, and it takes days to disappear from other places. Makes zero sense.

Often if i just took some pictures i have to send them via airdrop instead of just opening Photos. Come on Apple!

Re: It's virtually impossible to read old iMessages and they take up tons of storage

#153

I want a chat app that is: E2EE and allows me to change phone numbers. I started migrating people to Signal when that whole WhatsApp ToS hullaballoo happened, but now I need to change my phone number and apparently this is not supported in Signal, which is just crazy to me.

Signal is also guilty of the huge-and-useless database of old messages. Turning your chat history into text is not easy.

Re: It's virtually impossible to read old iMessages and they take up tons of storage

#154

Apple's chat.db has an esoteric schema owing to the fact they never designed it from the ground up and instead kept adding new columns and tables with each macOS release. This makes their queries super complicated with multiple joins. Once you have the schema figured out, it's dead easy to build a third-party client that works better than the official one. Even search works great with a simple LIKE query but Apple re…

I don't mean to be pessimistic , but I wonder how you're going to be anything but reactionary to apples changes to the database. I've written a similar (much simpler) version of what you're proposing to sell- the database queries are hysterical.

I've been thinking about using the accessibility I framework to ETL the messages into Kinesis to facilitate event driven architecture. 'archived' Messages and attachments are stored as bsob.

Hell, I've even experimented with some goofy stuff, like FaceTime to VOIP- asterisk is just so flexible

Re: It's virtually impossible to read old iMessages and they take up tons of storage

#155

Apple's chat.db has an esoteric schema owing to the fact they never designed it from the ground up and instead kept adding new columns and tables with each macOS release. This makes their queries super complicated with multiple joins. Once you have the schema figured out, it's dead easy to build a third-party client that works better than the official one. Even search works great with a simple LIKE query but Apple re…

A piece of feedback: it would be nice to know what the price is on your site. You say "We make money by charging you a monthly subscription," but there's no pricing.

Re: It's virtually impossible to read old iMessages and they take up tons of storage

#156

Apple's chat.db has an esoteric schema owing to the fact they never designed it from the ground up and instead kept adding new columns and tables with each macOS release. This makes their queries super complicated with multiple joins. Once you have the schema figured out, it's dead easy to build a third-party client that works better than the official one. Even search works great with a simple LIKE query but Apple re…

I modified this script to pull my entire db into a text file.

https://github.com/michael-danello/iMessageWrapped

EDIT: It is absurd Apple doesn't provide better message organization and UX/UI.

Re: It's virtually impossible to read old iMessages and they take up tons of storage

#157

Apple's chat.db has an esoteric schema owing to the fact they never designed it from the ground up and instead kept adding new columns and tables with each macOS release. This makes their queries super complicated with multiple joins. Once you have the schema figured out, it's dead easy to build a third-party client that works better than the official one. Even search works great with a simple LIKE query but Apple re…

I've built an iMessage chat.db reader as well. To me the most astounding thing is that chat.db is unencrypted sqlite. Anyone who can see your home folder can read all your private chats or upload the chat.db to be read somewhere else.

It's impressively insecure.

Re: It's virtually impossible to read old iMessages and they take up tons of storage

#159
post #138

Earlier quoted context omitted.

I was under the impression that Steve Jobs’ was sjobs@apple.com

"steve" was a collision from the start.

I could imagine Steve Wozniak offering to use surnames only as a joke - because that wouldn't work either.

Re: It's virtually impossible to read old iMessages and they take up tons of storage

#160
post #130

Earlier quoted context omitted.

I had done something too, but I also needed a Manifest.mbdb parser to reconstruct backup to disk, then process the messages and copy all the images around to make it work. I did it mostly to make a simple-to-read archive of chats before deleting them.

Did your work turn into some potentially sharable shell scripts, perhaps? Would be a useful tool to avoid having to store messages in iCloud.

I have not used it for a very long time, so I can't comment to how well it works.

That said, this is it: https://gist.github.com/brianv0/35f36a32366a2c34be8d

(You need an unencrypted backup directory to run it over)

Note: It looks like the flat directory structure of the backup is now 256 dirs prefixed by first two characters of file name. I'm not sure, but a small change to the name "sha_file" may be needed to just path.join that with the first two chars of the sha.

Post reply on HN