Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MMS table to XML export #67

Open
rkr8 opened this issue May 6, 2022 · 5 comments
Open

MMS table to XML export #67

rkr8 opened this issue May 6, 2022 · 5 comments

Comments

@rkr8
Copy link

rkr8 commented May 6, 2022

Hey there,

I'm currently trying to figure out how i can convert all the text messages from a Signal backup into a xml file (which should be imported in the default SMS app later). In https://github.com/bepaald/signalbackup-tools#export-xml it says that currently only the SMS table is supported, which excludes sent group messages and media. However, in the code i found:

if (!sb->exportXml(arg.exportxml(), arg.overwrite(), false /*include mms*/, SignalBackup::DROPATTACHMENTDATA))

Enabling this flag and running --exportxml gave me the error message ERROR Failed to retrieve required field 'address' (mms database, type = 10485783) and a corrupted XML file. Thus I was wondering if there is any possibility to get this feature working?

Thanks in advance!

@bepaald
Copy link
Owner

bepaald commented May 7, 2022

Yes, that would be expected, that functionality is not there (yet?).

The 'address' ( = phone number) field is a required field for the sms xml spec, but messages sent to a group, do not have an address as they are not sent to any single phone number. And in sms, there is no such thing as a 'group'.

I could just duplicate all outgoing group messages as if having been sent to each group member individually. Would you be OK with that? It seems a bit messy to me. Although, with the current behavior (which was a re-implementation of the official xml export) this is already the case with incoming messages: there is no indication that an incoming message from any person was sent to you personally or to you as a member of some group.

Alternatively, I suppose I could just assign some fake phone number (maybe an invalid one to guarantee it will never clash, though invalid phone numbers might be rejected by an importing application), and have all group messages use that number as 'address'. In that case, the group messages aren't mixed with individual messages, but I don't think there will be any way to distinguish between the authors of incoming messages.

Let me know what you think. It might take a little while to implement. Some bugs will also probably come up, so testing will be required.

As for media messages, I think I actually implemented including those, but I could easily just leave them out and just include the message body in the export.

Note also there are many other features that may not be supported by sms (multiple attachments, quotes, emoji reactions), so no xml export will ever be complete.

@rkr8
Copy link
Author

rkr8 commented May 9, 2022

Hi,

thanks for your quick response and effort! I think the option to just duplicate all outgoing messages (as if they have been sent to each group member individually) would be very convenient. For me personally, it would be more important to distinguish between the author of the group messages than to distinguish between personal and group message. But others might have different priorities. Maybe having a command-line flag for choosing one of the options would be a good compromise?

If you choose to implement any of that, I could test the feature with my signal DB on Windows and WSL :)

Slightly off-topic, but the whole signal to XML thing is mostly a workaround for me to somehow get the signal text messages from Android to iOS :D I know it's quite cumbersome, but i don't see any other option than:

  • exporting signal messages to XML
  • importing messages in pre-installed SMS app
  • using "Move to iOS" app to import the messages into iMessage on iOS

@bepaald
Copy link
Owner

bepaald commented May 10, 2022

Hi! Well, scratch most of what I said in my previous message. Seems like MMS does support actual groups, so maybe I can get a much more accurate XML file out of the backup. I need to do some research though, the only specification I have seems somewhat incomplete or under defined (at least as far as I understand it). (ref: https://synctech.com.au/sms-backup-restore/fields-in-xml-backup-files/ and https://synctech.com.au/wp-content/uploads/2018/01/sms.xsd_.txt). This will probably take a while to implement properly. Is there any particular program you are using to import the XML file?

Slightly off-topic, but the whole signal to XML thing is mostly a workaround for me to somehow get the signal text messages from Android to iOS

Right. That seems like a good reason to want this option. I think I've had messages from other people doing this same procedure (losing some messages due to the limitations obviously).

EDIT
I thought I'd just send myself some group mms and multi-attachment mms to see what they look like in an exported xml file. Unfortunately, as it turns out, the last provider to support mms in my country stopped supporting it in 2019. Never noticed that 😀. It'll make research a bit more time consuming though. Luckily, I did have some normal (single attachment, single receiver) mms messages from years ago already on my phone, so I can at least check those out.

@rkr8
Copy link
Author

rkr8 commented Jun 1, 2022

Hi! Sorry for my very late reply! Thank you so much for the research! So far I've only tested this app https://play.google.com/store/apps/details?id=com.riteshsahu.SMSBackupRestore&hl=en&gl=US which worked very well, but I'm not sure if it supports group MMS messages. Probably this feature is not really a priority for most people, so whenever you find time I could test it on Windows + WSL :)

@jbaker6953
Copy link

This functionality is available from https://github.com/alexlance/signal-message-exporter

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants