You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, imessage-exporter exports every conversation it can see. It could be useful to specify specific conversation(s).
The easiest way to accomplish this is to know the chat's ID in the table, but even that may not be correct due to the duplication problem. We can of course show this to the user, but selecting from a list in a reasonable manner is an interesting UX problem.
I don't want to emit a huge list and expect the user to read through it, there must be a way to live-search it.
The text was updated successfully, but these errors were encountered:
I would think that a CLI option along the lines of --people=first_last,first1_last1 would be dirty but get the job done. One library that might come in handy is Rust Fuzzy Matcher though exact implementation would fall to you.
Maybe to make everyone's life easier, using the address book sources stored in /Library/Application Support/AddressBook/Sources would be the best bet. This directory has other subdirectories in it, the largest one contains all the contacts in .abcdp format which is just a database file. From here each chat could be labelled with contact names rather than the raw phone number.
For iOS backups (which I plan on making a larger issue report on) the contacts should be stored in $iPhone_Backup/ '31' / '31bb7ba8914766d4ba40d6dfb6113c8b614be442'. Again not the cleanest solution to hardcode it in but this is the equivalent to a "contacts.db" (Source: iMessageBackup (python))
Hope some of this additional research could help, I know you did a lot already so apologies if I'm retreading ground.
This came from feature request #51.
Right now,
imessage-exporter
exports every conversation it can see. It could be useful to specify specific conversation(s).The easiest way to accomplish this is to know the
chat
's ID in the table, but even that may not be correct due to the duplication problem. We can of course show this to the user, but selecting from a list in a reasonable manner is an interesting UX problem.I don't want to emit a huge list and expect the user to read through it, there must be a way to live-search it.
The text was updated successfully, but these errors were encountered: