March 2019 - delta - lists.codespeak.net

by Marko Hehl

Hi, I'm Marko from Germany. Just trying the DeltaChat Client with SailfishX and elementary OS 5.0 On elementary I get a error message after the npm start. Anyone the same problem here? --M. -- Gesendet mit SailfishX

4 years, 10 months

7
6
0 0

[delta-chat] new android releases / switch to RSA2048 keys

by holger krekel

Hi all, there is a new android release out on gplay and f-droid: https://delta.chat/en/2019-03-14-oauth2release one thing that we missed to announce is the default for encryption keys has changed and is now RSA2048 instead of the previous RSA3072. This improves the setup time (often taking 60 seconds, now 10) and also reduces message size. We are aiming to support ECC/ED25519 keys which will much reduce key sizes. If you are wondering if RSA2048 i safe enough you may consider: - gpg (the command line tool) defaults to RSA2048 - Autocrypt setup messages (transfering your secret key) are not safer than RSA2048 encryption keys. - general advise still is that RSA2048 is enough https://paragonie.com/blog/2019/03/definitive-2019-guide-cryptographic-key-… cheers, holger

5 years

3
2
0 0

[delta-chat] Support normal mails in DCC for hybrid clients

by Viktor Pracht

Hello all, I have started this discussion in the forum[1], but apparently this mailing list is more appropriate. So, below is my original post, followed by Holger's reply with my answers to that inline. > > As a pre-requisite for "Make DC a replacement for MUAs?"[2] and hybrid > > chat/mail clients in general, the DeltaChat Core library should support > > sending and receiving arbitrary MIME mails. > > > > I see several ways to add the API to DCC, in order from least to most > > abstraction: > > > > 1. Send/receive raw bytes. Not stored in DCC database. > > Folders are simply strings representing the full path, i.e. starting > > with “INBOX/”. > > - pro: least effort for DCC > > - con: most effort for DCC clients, duplicate DCC functionality > > - con: need to expose more internals to access e2ee keys, etc. > > 2. New class allowing direct access to libetpan. Optionally stored in DCC > > database. > > Folders have their own class. > > - pro: reduced effort to implement now > > - con: more effort for clients on migration away from libetpan > > 3. New class with all necessary methods, abstracting libetpan. Optionally > > stored in DCC database. > > Folders have their own class. > > - pro: reduced efforts for clients > > - con: more effort to implement now > > - con: more effort for DCC to migrate away from libetpan > > 4. Extend the existing message class (dc_msg_t). Stored in DCC database. > > Folders can use either their own class or extend the existing chat > > class (dc_chat_t). > > - con: big change to existing APIs, code and DB > > - con: gets in the way / increases the learning curve for pure chat > > clients > > > > Just counting the pros and cons, options 2 seems the best so far. But > > before we start thinking about implementation detail, what are your > > thoughts and ideas about it? Maybe some completely different > > implementation ideas? > > Not sure this is a good forum for discussing what are rather implementation APIs and architecture questions. I’d rather suggest the mailing list. Let me still say a few things :) > > I suggest to think more about the needed API and not too much about how it’s implemented. There is a lot of tentative/incremental flux that could happen in the next months, regarding moving code from C to Rust etc. And let’s maybe first talk about sending/receiving semi-arbitrary mime-mails, not about new/added IMAP handling. Which C-API would be needed and how would it work/be specified? There might be a misunderstanding. My list does not contain any implementation details. Quite the opposite: before taking the first incremental step, we should first decide on the direction in which we want to go. And that's where the 4 approaches come in. Except for maybe approaches 3 and 4, the different approaches are not incremental extensions of each other. So we will probably need to decide which way to go, and discuss enough details to make the decision. For example, the sending half of approach 1 is a single trivial function, because most of the work for that was part of the "early MIME generation" issue. It already technically accomplishes the goal of sending arbitrary MIME mails, except that accomplishing the goal this way is almost useless because it forces clients to do everything on their own, from MIME generation to crypto (see also the cons in the list). "Semi-arbitrary mime-mails" sounds to me like approach 4: adding functionality to the Message class to send more and more types of mails until it's flexible enough to send any MIME mail. So yes, that's one approach which would make sense. But before we start discussing the implementation, I would like to discuss the pros and cons relative to the other approaches. And maybe somebody can come up with yet another completely different approach. > How does Autocrypt-handling happen including encryption and decryption? If mime-mails are not tied to a chat at sending time, but to a caller-specified list of recipients, then how are they accessed on the receiving side? I'm not sure I understand the question. Mails are accessed using a mail client, aka MUA (mail user agent). Why should anything be different if the sender's MUA is using DCC instead of e.g. MailCore 2? Regarding Autocrypt, that should not be any different than people accessing their Autocrypt-encrypted mails on multiple devices/clients. The beauty of chatting over email is that for the purpose of most standards (here: Autocrypt), DeltaChat is just another MUA. Regards, Viktor Pracht [1] https://support.delta.chat/t/support-normal-mails-in-dcc-for-hybrid-clients… [2] https://support.delta.chat/t/discussion-make-dc-a-replacement-for-muas/253 -- Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe AG Siegen, HRB 8718 Geschäftsführer: Frank Hoberg

5 years

3
4
0 0

[delta-chat] Python unit tests for adapted Delta Chat core code

by deltachatmailinglist＠netc.fr

I have added a new feature to Delta Chat core, namely the [detection and removal of subject prefixes]. I prefer to have unit tests early during the development and I didn't find any existing ones in the repository. So I used [MinUnit] as a basis to quickly set up a C test framework and wrote my tests with that. In the meantime, I have asked around and have been pointed to the Python tests where I've been told that the C methods would automatically be available via `deltachat.capi.lib`. I ported my tests to Python, but they don't work because I can only access the existing C methods, not my added ones. I think it's because I followed the Readme which instructs to install the bindings via Pip so they can't possibly contain my code. But also when I analyse the symbols in the generated `python/src/deltachat/capi.*.so` files, my methods are missing. I should note that I added my new files to the Ninja build, the methods are contained in the compiled `build/src/libdeltachat.so` and I called `sudo ninja install` as mentioned in the Readme. My two questions therefore are: 1. How to make the compiled `capi*.so` files reflect the current C code in the repository? 2. How to use these bindings in the tests? [detection and removal of subject prefixes]: https://github.com/deltachat/deltachat-core/issues/126 [MinUnit]: http://www.jera.com/techinfo/jtns/jtn002.html

5 years

3
3
0 0

[delta-chat] new project tracker / early april stabilization releases

by holger krekel

Hi all, in particular devs and testers, going to kyiv end april is approaching and thus i suggest to go for a new set of stabilized releases. I'd kindly ask everyone to focus mostly on stabilizing and merging work and to suspend feature development until releases are out. We have a couple of build issues, with lots of progress lately there, on almost all platforms. I started a cross-repo project for the stabilization releases here: https://github.com/orgs/deltachat/projects/9?add_cards_query=is%3Aopen Please add to/update this project, and perform issue guardening on the respective github issue trackers. Please don't do additional "nice to have" features to the early-april releases. Also please try to be pingable/available on #deltachat freenode the next week to help others who want to move things. Finally two notes regarding development on two major features: - If location streaming is enabled as an opt-in "advanced/experimental labs feature" depends now on stabilizing it. Otherwise it can be disabled before and re-enabled after release. - If RPGP (Rust in PGP) can be switched on by default in the releases will be finally determined soon. Currently netpgp fails sometimes to decrypt messages which were encrypted with RPGP. As gpg can decrypt those failing messages just fine it's probably a problem of netpgp. Still would be good to know more precisely. thanks and best, holger

5 years

1
0
0 0

[delta-chat] [coi] Release of OX Talk technical preview 0.3.0 (Android)

by Florian Haar

Hello everybody, the Open-Xchange team just released another technical preview version. Version 0.3.0 is a feature / bug fix release for the Android platform. It's downloadable via our GitHub repository. Download link + full release notes: https://github.com/open-xchange/ox-talk/releases/tag/0.3.0 Repository link: https://github.com/open-xchange/ox-talk New features: * Send attachments * Applying account settings now reconfigures the app settings * User visible error handling for the login screen * Show only invites created by other chat clients * Show an indicator for new invites Fixes: * Invites are not removed after accepting or blocking requests * Sorting issues Known issues: https://github.com/open-xchange/ox-talk/issues Regards, Florian -- kind regards, Florian Haar Software Developer Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 Email: florian.haar(a)open-xchange.com mailto:florian.haar@open-xchange.com Twitter: @openexchange http://twitter.com/openexchange - Facebook: OpenXchange https://www.facebook.com/OpenXchange - Web: www.open-xchange.com http://www.open-xchange.com Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Uwe Reumuth Chairman of the Board: Richard Seibt European Office: Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718 Managing Directors: Frank Hoberg, Martin Kauss US Office: Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system.

5 years

1
0
0 0

[delta-chat] The state of building deltachat

by Floris Bruynooghe

Hi all, On IRC I was told the current build situation is unclear (no surprise!) and an attempt to sketch out the current and desired next state would be useful. Here's my attempt, it's only partial obviously and I probably missed many things, got many wrong and many will have changed within a few days (e.g. we're about to add a Rust dependency so who knows how that'll look). Anyway, currently deltachat-core ships with a bunch of (outdated and limited) dependencies bundled in the libs directory. Other than netpgp you should try to avoid to need these when building. However they are used for the android build which is why they can't be simply removed. I'll come back to fixing the android situation later. If you continue on unix it's probably because you want a deltachat-desktop install. The recommended way to install on linux is to use the flatpak: https://flathub.org/apps/details/chat.delta.desktop it works correctly on all linuxes right now. I'll continue the journey into how we produce said flatpak, which will bear many similarities with how to build on other unixes. Next you need to build the deltachat-node bindings. This currently builds libdeltachat.a itself rather than using the system installed version. Likewise it uses the bundled libetpan. The next improvement to make here is to change the build to use a system-installed libdeltachat.so and thus giving control to packagers to decide which dependencies are used. It means that downstream users no longer depend on the git subproject of deltachat-core which happens to be in deltachat-node, thus taking deltachat-node out of release work (unless it needs code changes itself). This is also a desired step to support packaging on linux distros who will otherwise never package deltachat-node. As a result of this we also want to stop posting prebuilt binaries of deltachat-node to npm. This will break some CIs in deltachat-desktop which will have to start building their own dependencies. Further possible scope creep here is whether to also support several variations of building, e.g. against a static libdeltachat.a? Against a non-installed version? But it seems this is not needed initially due to the slow rate of changes in deltachat-node. Next up is deltachat-desktop, like deltachat-core this does see a lot of changes for each release. This simply depends on deltachat-node, so once dc-node is updated to depend on the system libdeltachat.so everyone building this will need to build and install libdeltachat.so first. Finally the actual packaging work happens, e.g. in the flatpak repo. These need to build all dependencies, dc-core and then npm install dc-dekstop (which will pull in dc-node via npm and build it against system dc-core). This currently does not install dc-core or all of it's dependencies because dc-node currently uses a weird mix. Now to get back to Android. This currently uses all the bundled dependencies in the dc-core libs directory, it does however not use the meson build definitions instead lists all the .c and .h files in it's own build system. These bundled dependencies still are too outdated and hard to upgrade though. There are two choices here (well, maybe more - tell me!): - Do the same as on other unixes and build all the dependencies externally, pointing the android build to the ready .a files. We'd probably want to do this on a CI system. We can create a docker image which builds all these dependencies and can build dc-core & dc-android using them. - Still bundle the dependencies but make it easier to upgrade them by splitting them into their own repos, tying them in via meson subprojects. This would then also allow to cross-build each project using meson and producing the necessary .a files which then again get used in the android build. The advantage of this is that these subprojects would also give us identical builds on all unixes if we wanted. Hope this is somewhat helpful. Feel free to comment. Cheers, Floris

5 years, 1 month

4
6
0 0

[delta-chat] Algorithm of delivery of messages

by Евгений Кабанов

Dear friends! Please explain the algorithm of delivery of messages: sometimes they go in one direction for a few seconds, and sometimes this time is from 5 to 10 minutes. Moreover, the rapid exchange of messages (question-answer) does not work, or there or back (quickly). I want to understand the algorithm in order to communicate the order of correspondence to their correspondents. -- Евгений Кабанов http://kabanov.tel

5 years, 1 month

3
3
0 0

[delta-chat] Wanted: Delta Chat Core Developers

by Robert Virkus

Hi everyone, as you might have heard, Open-Xchange is working on a new emerging standard for messaging on top of email - we call our variant "Chat Over IMAP" or "COI" in short. We collaborate with Delta Chat in various ways: * We contribute to the Android client. * We cooperate on interoperability between COI and Delta Chat. * We develop our own Flutter.io-based messaging client that uses Delta Chat Core: https://github.com/open-xchange/ox-talk and https://github.com/open-xchange/flutter-deltachat-core (both MPL-licensed). You will find our current specification draft here: https://github.com/coi-dev/coi-specs/blob/master/coi-client-spec.md Note that server side specs will follow, as we plan to extend IMAP and SMTP for easing messaging over email. Generally, you will find more information at https://coi-dev.org and you can subscribe the COI developer mailing list by sending a mail to dev-join(a)coi-dev.org mailto:dev-join@coi-dev.org . Now, to the actual topic of this message: we are hiring! We search for capable C and Rust developers who are willing to work fulltime on future Delta Chat Core topics. Please find attached the job details. If you have any questions or feedback, please let me know! Many thanks in advance, yours Robert -- Robert Virkus Product Manager Apps Open-Xchange GmbH Stavendamm 22 28195 Bremen Germany Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 Cell: +49 160 77 88 203 robert.virkus(a)open-xchange.com

5 years, 1 month

1
0
0 0

[delta-chat] Chat: Hola, quiero darles las gracias al ...

by El Pupa

Hola, quiero darles las gracias al grupo de trabajo de Delta Chat porque es la única aplicación que me funciona bastante bien con el correo ya que mi móvil presenta algún tipo de incompatibilidad con el servidor smtp.nauta.cu, parece que hace un timeout después de un tiempo con la pantalla apagada, es un Xiaomi Redmi Note 6 Pro y gracias a esta app me funciona al 50%. -- Envía y edita fotos y envía audios sin problemas

5 years, 1 month

1
2
0 0

2024

2023

2022

2021

2020

2019

2018

delta March 2019