- delta - lists.codespeak.net

[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, 8 months

3
2
0 0

[delta-chat] Leandro Marcelo te ha enviado una invitación en LinkedIn

by Leandro Marcelo Torres Silva

..................................... Leandro Marcelo quiere mantener el contacto en LinkedIn. Leandro Marcelo Torres Silva Android Developer en Avaits.com Cuba Ver perfil https://www.linkedin.com/comm/in/leandrotorressilva?trk=eml-guest-invite-pp… Confirma que conoces a Leandro Marcelo https://www.linkedin.com/comm/start/accept-invitation?sharedKey=VwyFoXy7&in… ..................................... Darse de baja: https://www.linkedin.com/e/v2?e=-fb1xm1-jtzxlbrk-f4&t=lun&midToken=AQFmrFVh… Ayuda: https://www.linkedin.com/e/v2?e=-fb1xm1-jtzxlbrk-f4&lipi=urn%3Ali%3Apage%3A… Recibes mensajes de correo electrónico sobre Invitación . LinkedIn utilizará tu dirección de correo electrónico para enviar sugerencias a nuestros miembros en funcionalidades como Gente que podrías conocer. Este mensaje se ha enviado a delta(a)codespeak.net. © 2019 LinkedIn Ireland Unlimited Company, Wilton Plaza, Wilton Place, Dublín 2. LinkedIn es un nombre comercial registrado de LinkedIn Ireland Unlimited Company. LinkedIn y el logotipo de LinkedIn son marcas registradas de LinkedIn.

5 years, 8 months

1
0
0 0

[delta-chat] Email notification unsubscribe

by Andreas Heidemann

Hello please unsubsribe me from all of your email lists Thanks! -- Andreas

5 years, 8 months

2
1
0 0

[delta-chat] UX offline/online issue, upcoming Kyiv gathering (was: Re: Delta Chat User Testing report now out!)

by holger krekel

Hi all, first of all, let me warmly recommend to read what Xenia and Vadym wrote in the UX testing report, also published on the blog now: https://delta.chat/en/2019-03-30-uxreport Its results and content already was discussed in longer sessions November 2018 at our in-person gathering in Kyiv. Several devs met and chatted with the participants after the more formal UX test sessions. Delta Chat is a deeply UX driven project. However, lots of deeper UX discussions happen in real life conversations and it's often hard to co-ordinate offline with online forum or github-issue discussions. This may be frustrating or irritating if you (can) only participate online but it's never quite possible to transfer all what's happening offline to the online world. It's not even possible that everyone from the developers knows about all UX considerations everywhere. Note that our wider "physical" gatherings are quite open, the next one is upcoming for end april (23-30th) in Kyiv again. We are working with several well-informed and networked locals and are of course aware of the currently happening presidential elections there ... with the final vote to happen just two days before our gatherings starts. We have a wide range of participants from different decentralization and e-mail projects, with several world-class dev and UX folks, mixed with the very interesting and complex evolving techno-social environment of Kyiv ... for some superficial info there is a new website now: https://xyiv.noblogs.org/ for more and organisational info, ask on the #deltachat IRC channel or mail xenia or me. IRC and E-Mail ... such retro much fun :) There are both travel and accomodation possibilities if you are short on money. FWIW, to me Kyiv feels a bit like the 90ties in Berlin btw. and it's interesting to note that Ukraine has a big internet provider scene -- just like in the 90ties in the West. So in retrospect, what could have gone differently, historically, if different developments evolved? How is it possible to preserve and multiply diversity and retain the ability to operate infrastructures regionally instead of depending on strong online pipes to California? cheers, holger On Thu, Mar 28, 2019 at 23:23 +0100, Xenia wrote: > Dear all, > > We are finally publishing our Delta Chat User-testing report based on > our usability tests with a dozen Ukrainian journalists and NGO > activists. Since then, many things have already been improved and > implemented while other are on the way! Some of our development > priorities - such as location streaming for example - are based on tests > and discussions with our active users and contributors. This report is > part of this iteration process that we try to engage with. > > I hope you will find some of the aspects of this report interesting for > your own projects, as we tried to write it in a reflexive way. We > questioned how habits related to popular secure messaging apps influence > usability expectations and create a sort of "inertia". In this regards, > in this report - and beyond - we look for ways to design better UX/UI > for decentralized messaging ecosystems and namely how to provide users > with better explanations, visualizations, phrasing of key concepts. We > hope this can be relevant for other projects seeking to convey some of > the aspects of decentralization to their users, while having to deal > with language / wording and UX "heritage" of centralized apps. > > We're now one month to go from our second Kyiv gathering - currently > under the code-name "Delta Xyiv" (April 23 to May 1st) - where we will > conduct a second round of user-testing - and a real-time > Game/Test/Scavenger Hunt in the city, as well as many other happenings. > In preparation to that, we welcome any feedback on this report, as well > as on the recent developments of Delta for Android, iOS and Desktop. > Thank you in advance for all your contributions and comments! > > All the best > > Xenia (and Vadym) > > pub rsa2048/B0C29AFD8B8DB519 2015-11-01 [expires: 2025-01-08] > uid Xenia <ksenia(a)radicalcinema.org> > uid Ksenia <ksenia(a)citizenlab.ca> > uid Xenia <ksenia(a)transcyberian.org> > sub rsa2048/7785EAC1EB8536A3 2015-11-01 [expires: 2025-01-08] > _______________________________________________ > delta mailing list -- delta(a)codespeak.net > To unsubscribe send an email to delta-leave(a)codespeak.net

5 years, 8 months

1
0
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, 8 months

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, 8 months

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, 8 months

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, 9 months

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, 9 months

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, 9 months

3
3
0 0

2024

2023

2022

2021

2020

2019

2018

delta