As we can see here, Librem 5’s chatty may have a COI plugin.
Are you guys working with purism?
Maybe a dev can tell them more about that error they reported after compiling:
INFO: Trying: abc@abc.de haeckse:***:imap.xxx.de:143 haeckse:***:smtp.xxx.de:587 AUTH_NORMAL IMAP_STARTTLS SMTP_STARTTLS
GnuTLS error: The operation timed out
my_delta_handler(mailbox, 100, 0, 140643200438528)
INFO: IMAP stream lost; we'll reconnect soon.
my_delta_handler(mailbox, 401, 0, 140643200413872)
ERROR: 0: Could not connect to IMAP-server imap.xxx.de:143 using STARTTLS. (Error #4)
my_delta_handler(mailbox, 100, 0, 140643200437696)
INFO: IMAP disconnected.hello @luisfsr, why would be Delta Chat working with purism because they will have a COI plugin??? COI is not the same as Delta Chat, Delta Chat may implement COI in a future, but atm Delta Chat don’t even implement COI, AFIK
The libpurple plugin has not much to do with COI, its based on deltachat-core. Same with the COI project, they seem to base their product on deltachat-core and will hopefully submit patches.
3 Likes
Yup! My understanding on the subject is as @testbird 's. Unless we are mistaken, COI uses the DC defaults / protocol, as they use DC-core.
1 Like
everyone can use DC core, I could use DC core and put it in project “X” but that doesn’t mean that the Delta Chat team have something to do with the project “X” that is what I was trying to explain to your initial question:
and as far as I know COI use their own fork of Delta Chat core, maybe atm it is exactly the same but that doesn’t mean they can’t just take dc core and modify it, so purism will be using not exactly the Delta Chat core
1 Like
As far as I understood, COI is to be a “standard” used by DC and other compliant clients. So say COI’s FAQ:
- OX - the initiator of the COI initiative - is working on its own COI compatible client. This one is MPL licensed and available at GitHub - coi-dev/ox-coi: OX COI Messenger - a Flutter app for the COI (Chat Over IMAP) standard.
- We are cooperating with Delta.Chat for it to also use COI to provide more features, we are contributing to the C-Kernel of it.
- We are cooperating withother client developers such as Thunderbird or Spike to get more clients use COI, and invite all ISV’s to join in. There are soooo many variants of Chat / Slack / Social Clients out there. Let’s put them on COI and make them interoperable and give users control over where all that data sits!
So COI and DC are related and work together to maintain interoperability, so the idea is not to make a fork and modify it at a point they can’t recognize each other, but the opposite.
did you remember your initial question???
anyway, that question should be answered by some core developer, I am just guessing here 
And still, my initial question can be interpreted as I was implying something or just asking 
There are two things here. COI is a spec by OpenXChange that leans on Delta Chat’s specifications but adds various bits and pieces – without implementation so far, though.
Then there is OpenXChange as a whole (who are promoting COI) who are developing OX talk and other apps, and for chatting they use deltachat-core. There is a longer ongoing collaboration on evolving deltachat-core, including potentially supporting some COI features. Some OX developers are also involved in helping with the Delta Chat Android app.
Note that several COI features require an updated IMAP server and that will take quite a while to appear in the wild. Delta Chat will for the foreseeable future not require any special IMAP servers but aims to be happy with “plain” already-existing IMAP servers for all its base features.
The “Chat over Email” effort is just starting to roll and we expect more groups and people to join the fun. This is why we re-licensed from GPL to MPL for core which makes it easier for OpenXChange and others to use it in their offerings.
3 Likes
…and back handled then it was handled as:
@testbird an honest question: you are very present in several channels in Delta Chat, for a longer time already. You appear to be often (and increasingly?) unhappy and to think we are making many wrong decisions. If you dislike happenings so much why keep busying yourself with it? Aren’t there many other software projects that maybe are more in line with your thinking?
You seem to continuously think different things then communicated or talked about, and push replies and (shown to be very suboptimal) technical detail decisions, based on management rules without thinking much about any three of them.
Considering the deltachat problems, solutions, and comparing their consequences, will be less work than not liking your critics, to learn avoiding mistakes, and unnecessary back-and-forth implementation work. (learning from the group of users that care)
What about the deltachat-core errors reported at the link in the original post? No idea, anybody?
this doesn’t answer my question of why you keep busying yourself with DC if you think most of what is happening is wrong or bad or sub-optimal … After >1y of your giving advise, often in strong terms and combined with accusations, on many issues and channels, i’d really like to understand why. To take this off-forum you can mail me at holger deltachat de.
Regarding the lib-purple error – the fact it is using “gnutls” springs up – that’s not common i think to compile libetpan with gnutls support. deltachat-core libetpan builds typically use openssl. but i think it’s better to discuss this on github, and more from the original libpurple/deltachat-plugin folks.
I am glad if you’re asking sincerely.
It is because, the Email-chat standard is the only chatting alternative with the potential to communicate seamlessly with billions of existing email accounts.
I keep looking at deltachat because I currently don’t know another freely available “reference implementation”, because the seamless interaction with the email world is a crucial feature, and the early versions clearly realized this and development followed this direction.
I know that implementing seamless fully compatible email interaction and adaption options may seem not that easy, not immediately necessary, or even unfamiliar (NIH), e.g. if looking with a “messenger developing driven focus” rather than at the larger picture.
I also know that solving the seamless-interaction problem isn’t the most straight-forward kind of thing possible to solve in a single iteration for every use-case. But I am sure it is possible, with a moderate amount of work in the wiki, the design, and implementation, it will bring very fruitful results. For that I had started the use-case and imap wiki pages, a place to condense requirements and options into a coherent solution, adding to it whenever a new aspect come up. By now the wki pages provide a really good basis to discuss questions, and come up with simplifications and roadmaps. With the multi IMAP-push already implemented there are actually only a few aspects missing, to have a solution that already covers all the stated requirements.
Wanting to cut down and concentrating efforts is also understandable for the project lead, but a bad thing if this means basic fundamentals are not solved properly. Not really solved fundamental problems and errors behind imagined lines and workarounds will always come up again, just that later-on these type of things tend to get harder to solve and grasp, not only because users don’t see the whole picture if pressed into workaround implementations (missing full email-compatibility, and the smallest optimal set of use-case adaption preferences).
The natural absence of the focus on the code and coding work is why regular users sometimes see problematic consequences of some of the development decisions faster than those that have already thought more about it. In the case of the removal of the “invite friends” feature, I only filed the re-enablement issue on github after seening responses in the thread here. I considered the re-enablement a non-controversal issue, a trivial and logical decision to just revert the removal. IMHO the usefulness of the feature simply got overlooked when removing it (better template can help users in reaching out e.g. to existing groups). Who would remove a feature that is of help to users. It actually looks as if it somehow only got removed by mistake, due to a bug report that was actually about deltachat not yet allowing to pass message-sending-intents to new (to-be-created) contacts (https://github.com/deltachat/deltachat-android/issues/429).
You’re right on another thing as well. For everybody that is interested in backwards compatible Email-chat, the current “streamlined contact requests” seems “wrong” (suboptimal). Because having a default max. length value instead, should enable a much better default chatting experience (see this comment). While it also provides full compatibility to receive new short-message chat attempts from known contacts with standard email clients, and reduces the amount of prompts shown to the user. So it is certainly another good small step worth to implement.
@luisfsr to get back to your one question: no, we are not working with purism but are open to it. Purism certainly appears to be interesting as a privacy focused platform and i’d think that Delta Chat would fit in. Maybe there are opportunities to engage with them, at best meet some folks in person … i’ve pinged folks who i think were/are involved with libpurple. no idea what dcc (delta chat core) version was tried etc.
1 Like
@testbird not sure i fully understand your e-mail, thanks for getting back. As this is going ever more off-topic i’d suggest to switch to mail or even chat! – you can contact me at holger @ deltachat de.