New function --importdesktopdb

[robertaramar]

I'm considering to implement an import to desktop DB functionality. I'm wondering if someone ever played with that thought and what you think about that.

My motivation is based out of the fact that I lost my Signal Desktop database due to some bug in a recent flatpak version of SignalDesktop and I'm pretty mad that this made me loose my whole history on my desktop. I have searched the net for an existing functionality of that, however, to no avail, hence, it's got to be done by someone.

If someone has thoughts about that, please make yourself heard.

Regards, Robert

[bepaald]

Apologies for the late reply (on #248), I do not always have time to immediately respond.

I'm considering to implement an import to desktop DB functionality. I'm wondering if someone ever played with that thought and what you think about that.

See #116 (and #134) for others who have interest in this. One person even mentioned starting to implement it, but it looks like they gave up quickly.

If someone has thoughts about that, please make yourself heard.

My thoughts:

I do not currently plan to implement this feature into this tool. This is just a result of my estimation of how difficult it will be to do and how much free time I have, while also maintaining the (many) existing functions of this tool. If I would attempt such a function I would make it a separate tool (that depends on this one).

Also, and this is important: Signal has for a long time been implementing a new backup format (v2), which is getting closer and closer to release. It is not exactly known what this backup will look like or when it will be released, but code in the various products suggests to me that the new backups will be able to be imported by any of Signal's products (Signal Android, Signal iOS and Signal Desktop). This would make the effort of writing such a function a waste of time, it may not even be finished before the new backups arrive. Even if the new backups do not support restoring on Signal Desktop, implementing the function will still have been for nothing, as this tool will not be able to read the Android backups to export the data from (it is expected this tool will need a major (if not complete) rewrite when the new backup format is released).

The upcoming backupv2 is also a major factor in me not currently picking up any (big) new functionality in this program.

---

If you, in spite of this, still plan to implement this:

First of all, this project does not accept outside code contributions at this time, so you have two options:

1. Fork it, and make any adjustments you need.
2. Or simply use this project as a dependency, use it to decrypt the Android backup to disk, and then use any programming language you want to read the necessary data and insert it into the Desktop database. (other projects have gone this route)

I would personally go with the second option (in fact, I still occasionally consider doing just that to attempt implementing this functionality). It would certainly get the process started a lot faster.

One important aspect about this function, would be that the Desktop database will need to be written. This tool currently does not support writing the sqlcipher database (I did not want to depend on sqlcipher, instead I've written my own implementation, but it's read-only).

When doing the actual translation from the Android database to Desktop, I suggest breaking the problem up into small pieces. To do a complete full export from Android to Desktop will be a huge and complicated project. However, you should be able to just import the message bodies fairly easily. Then you'll probably want to add message attachments (note these are encrypted outside of the SQL database). Then, one by one, deal with: calls, stickers, avatars, delivery/read receipts, quotes, mentions, emoji reactions, message ranges (text formatting), link previews, message edits, stories. And then there's is a whole web of status messages (profile changes, safety number changes, group updates, in-app payments, ...).

If you go with option (2), you could probably implement the entire program by just using this tool, sqlcipher, openssl (for encrypting attachments) and a bash script.

Obviously I will be available for any and all questions you might have (just like I was in #116), though I will occasionally need some time to reply and my knowledge (especially on the Desktop database) is limited.

---

Lastly, you seem to want to try to use this issue as a public forum, which I don't really mind. But I do not expect you to actually get more than one or two people to find this post. You are much better of starting a discussion on either reddit (r/Signal) or the Signal community forums. I'll leave this open for a week or so, but I don't think you'll get very much response, and if you do, the discussion should probably move to one of the forums I mentioned or your own project page.

Thanks!

[robertaramar]

Thanks for your comprehensive reply. I was actually using this "issue-way" because I wouldn't know how I could have contacted you otherwise :-D Is there a way in github to send you a message?

[bepaald]

Thanks for your comprehensive reply. I was actually using this "issue-way" because I wouldn't know how I could have contacted you otherwise :-D

Sorry, from the way your initial message was phrased I thought you expected other people to read it and give their opinion, not specifically me.

Is there a way in github to send you a message?

Not that I know of, my email is somewhere in the README, but this is perfectly fine. Sometimes direct email gets lost in my spam folder, while github notifications never do. I did of course get a notification from your last message in #248 as well, I just had not gotten around to replying yet.

[bepaald]

Ok, it's been a week, time to close this I think.

If I decide to start a project implementing this Android -> Desktop export, I will let you know with a link to that project here. I hope you will do the same if you start a project like that, because I would be interested and may attempt to contribute.

Thanks!