[Progress on Feature] Export Chat to zip

This is a note about the progress on the current plan of implementing Exporting Chats to an universal format for use for archival or as proof of something.
This is just meant as a todo-list/issue and not as an open feature discussion, if you want to propose an better idea please do so in a new or existing Feature Proposal topic.
You may post small improvement ideas here as long as they don’t blow up the scope like “re-importing the exported chat”.

The current idea is just to have something little more than the barebone text, irc-like thing that whatsapp has, so more in the direction of telegrams html exporter.

Current PR

-> https://github.com/deltachat/deltachat-core-rust/pull/1601
Left todo:

  • error handling (get rid of most unwrap)
  • ffi interface
  • json scheme that describes chat.json
  • test if files are there in archive (python?)


  • Export Locations
    • KML
    • GeoJSON
  • HTML Viewer
  • More Advanced Testing
    • Check validity and document json files with json schema
  • Report a progress like backup export (mainly write to zip step)


  • api to only export a specific range (start date, end date)
  • option to delete exported messages
1 Like

(Good master Simon, just some thoughts of someone not much in particular technics: To get not troubled by personal data issues, and since it’s possible thought to be a “death” end, archive, publication…and as seen that original email datas are desired to save: maybe good to cut away most of the background datas (thinking on yahoo lists, where one does not see email address, in certain setings) or at least make certain store dependend on agreements. As for the case this growing intentions becames a tool in larger use, certain laws should be considered, yet again the pointing on current lack of missing origin, when foward a message otherwhere, on the other side of this small path. So maybe 2 or 3 kinds of storage are good considered: privat, public, privat-public)

Would like to export directly to html too (first approach of PR).

I tested that approach (output format) locally and it looks nice and very handy. IMHO ideal for end user?

IMHO ideal for end user?

yes, even though with json we have a format third parties could use to provide users with even more possibilities. (such as maybe importing messages from deltachat into other messengers)

The main reason I decided to go for json first is that I can easily test it (adding ci tests for it) and I did feel like I was stuck in constructing the html manually, so I came to the conclusion that it’s probably easier to construct json and then have the html be a generic viewer app (in javascript) that consumes the json and is just shipped along side it in the output zip file.

I’m currently rather busy so I can’t do much on it right now.
If you do have time for it feel free to code an html export, I can then help you making it ready to be merged into the core if you need my help (doing ffi for it and maybe other things like api design).
But considering all cases and make it look exactly like desktop could be a tricky thing also I don’t know how tests for it would look like.

Don’t worry. You did the most work for html export and your work looks great!
IMHO anyway I would not have the expectation to let it look exactly as desktop version.
More I think it should be as simple as possible but should contain all informations in a transparent way for user.
If html structure is simple then anyway it’s no problem to use it for a future import again.

Based on your work and your css I did an example html file and was impressed how good you meet the desktop look and feel :+1:

Within next week hopefully I will get the time to start including the export into my fork :slight_smile:

But for extending ffi definitely I need some assistance how to do that.

My plan is

  1. get it run by core
  2. define and include an ffi interface
  3. add a ui control(s)