"Send" and "Really send"

Feature Proposal
1

Often I find myself after having “sent” my message I need to correct a typo or the like. I understand that the underlying protocol does not allow corrections of already sent stuff. Most often I see my typo immediately after sending, because the text appears properly formatted as a message proper.

If instead I had the option that sending acted like a preview I could correct my typo because the message had not already left the device. So the first “send” gives me a preview and the “really send” would put it on the wire.

If you make this behavior optional no current user will be upset by the “requirement” to press send twice.

1 Like
2

You can remove a message and resend it again. I think it will be removed at both sides.

3

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.

4

“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
5

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.

6

“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.

7

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…)

8

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.

9

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
10

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.

11

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.

12

For long messages you can open email client and write normal email.

13

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.

14

“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.

15

And Delta Chat is dead? Or it is not COI (chat over IMAP)?

16

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
17

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.

image

18

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

19

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”

20

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.