Thank, you for the answer, but this just does not work very well, well in our group it did not at all. This is why I made the feature request.
“You can remove a message and resend it again. I think it will be removed at both sides.”
No, I don’t think so. A message that left the sender’s server can’t removed. You can only remove it from you device and server. You can’t remove from the receivers device and server.
2 Likes
Unfortunately it is not possible to manually delete a message from the recipient,
but you can activate the Disappearing Messages function and select the period after which the message in the chat should be deleted. After the time has elapsed, the message will be deleted both locally and at the recipient. Of course, this only works if the receivers also use DC.
I think it would be nice if you could delete messages manually for a certain amount of time after they were sent. Similar to WhatsApp, DC could then point this out in chat with a info message.
“You can’t remove from the receivers device and server.” - but COI standard may support service syntax like “remove this message” and COI client can remove a message. Technically possible.
The function of disappearing messages is not intended to delete messages that contain one or more typos on both sides. Imagine to disable that function before you send messages without a typo. (Short explanation: You cannot estimate when you might send a typo-free message…)
The COI standard and it’s app are dead: coi-dev · GitHub
even if the project were still active, it would then only work on servers that implement the COI standard.
I am aware of that and was referring to this statement:
I wanted to point out that this feature allows you to delete emails from the recipient.
Of course, this is not good for correcting typos.
That’s why I suggested expanding this option:
1 Like
My idea is for client side feature for COI system message “remove message ID#”. For example in Skype you can edit message and it is changed on remote side as well.
this post/feature-request is a side effect of another missing feature:
possibility to edit sent messages
and maybe also a better “full screen” editor to preview/review long messages better before sending, currently with only like 3-4 lines of text in the composer it is hard to read long emails/messages before sending
about editing sent messages there are already these features requests:
with the ability to edit messages and/or better full screen composer to read the message before sending, the issue would be solved without needing less user-friendly approaches like “send” and “really send” options.
For long messages you can open email client and write normal email.
Why dead? Are there changes every year for SMTP or IMAP standards? It is normal to “invent” what is necessary and keep it unchanged 10+ years. Better than “new edition” every year.
“COI” was a marketing term and product of OpenXchange’'s chat project, as you can see from the link to the repo, it’s archived/dead.
And Delta Chat is dead? Or it is not COI (chat over IMAP)?
Delta Chat was there before “COI”, “COI” used a modified version of Delta Chat core and had a flutter based client. Deltachat is not the “COI” project or standard, It’s true that the name/description “Chat over IMAP” also fits Delta Chat, though.
1 Like
Before you send an message in gmail, the gmail gives time in 15 seconds. If within 15 seconds you do not cancel the message, the message is sent. I think we could have a delay to send the message, maybe 15 seconds or more.
why?
- usually to avoid spam there is the greylisting process, which is a delay in sending the message. “Graylist or gray list is an existing technology for email servers. In order to avoid receiving SPAM, this technology can be used in conjunction with other blocking technologies. It basically consists of a temporary block being transmitted to the email recipient for a period of time.”
- In my opinion, these two buttons: “Send” and “Really send” can appear as you hit the send key. This requires a response time. This response time is somewhat similar to greylisting, but serverless. Something on the client side.
most users would complain about the delay, so if we should ever add something like that it should be highly optional.
users already think deltachat could be faster than it is right now: Fastest server-side implementation to self-host Delta chat? - #6 by hossein
I was thinking about that when I wrote here. I thought this feature couldn’t be optional by the user himself in delta-chat.
Maybe you could set a response time to send or receive some message: “send”, “really send” or “send later” or “receive later”
A response time of 15 seconds might be too short to correct typos in a long message. The longer the message, the longer the response time duration would have to be. On the other hand, if we introduced “send and resend”, e.g. by tapping the send button twice, users might become used to it and no longer care. (Would some of them demand a “thricetap” then, like “Send”, “Really send”, “Really, really send”?)
My suggestion: Think twice and doublecheck every message before you send it.
On 29.03.23 um 12:01 wrote Gerry via Delta.Chat:
My suggestion: Think twice and doublecheck every message before you send it.
This is my current habbit when using email. Have you tried to do this
within the tiny edit box of delta chat?
Perhaps I should have started the thread with asking for a
preview feature since, as I can see now, what I have asked
for prompts only controversy.
Roland
I just wanted to explain that people easily get used to things they always do, like tapping the send button twice for every message in a hurry, and then find out that they missed something important to add or to correct, that is why this implementation would fail its mission in practice.
I welcome your idea to enlarge the text field and (maybe?) lay it over the rest of the screen while writing the message. I have heard that the devs are collecting ideas for an updated UI/UX, so your suggestion might suit pretty well to this project, and I am sure your voice will be heard among many others…
Edit: There is something wrong with quotes in here, I apologize…