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?
Gesendet mit SailfishX
there is a new android release out on gplay and f-droid:
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
I have started this discussion in the forum, 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?" 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.
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe
AG Siegen, HRB 8718
Geschäftsführer: Frank Hoberg
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]:
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:
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,
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
* 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
* Invites are not removed after accepting or blocking requests
* Sorting issues
Phone: +49 2761 75252 00
Fax: +49 2761 75252 30
Email: florian.haar(a)open-xchange.com mailto:firstname.lastname@example.org
Twitter: @openexchange http://twitter.com/openexchange - Facebook: OpenXchange https://www.facebook.com/OpenXchange - Web: www.open-xchange.comhttp://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
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718
Managing Directors: Frank Hoberg, Martin Kauss
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.
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
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
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
- 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
Hope this is somewhat helpful. Feel free to comment.
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
I want to understand the algorithm in order to communicate the
order of correspondence to their correspondents.
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:
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:email@example.com .
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,
Product Manager Apps
Phone: +49 2761 75252 00
Fax: +49 2761 75252 30
Cell: +49 160 77 88 203
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