Thank you for the link !
It looks to me, like “read receipt status icon” are still the same on github - it is double checkmark in repository that barely recognizable between single checkmark and double checkmark.
If any developer reading this thread, let me know please if you need better recognizable icon, so I will find designer who will do that.
well, of course we’re reading this 
first of all thank you for your thoughts and the idea to bring this forward.
to the symbol as such - afaik, the one/two checkmarks are rather well-known in the messenger-world. in general, i would suggest to stay which such well-known elements - or change them only for very good reasons
but i am pretty sure, the concrete implementation can be improved - although the android-dev symbols are a bit clearer than the old f-droid ones, to be honest i created them without much knowledge of svg or inkscape and without much love …
The checkmarks may be common for the messenger world, however the meaning may not be equal as one checkmark does not mean received by the device, only sent (to the outgoing smtp relay, and “on the way”), and isn’t self explaining.
If we look for better visibility and meaning.
These should be recognizable and be reasonably self-explaining for all.
Would the shape difference between a full colored airplane and an outlined eye with a checkmark be better visible for you AlexJ?
Thank you r10 for looking on my request ! I truly appreciate it !
I completely agree with you that any project should use commonly accepted things to prevent inventing a wheel and force users to re-learning something, but AFAIK this symbol is common for particular app - WhatsApp and there plenty questions online from users, -what double ticks means. As I wrote before, other apps using different icon for such events, IMHO, a double checkmark isn’t a standard.
Facebook messenger for example, it use icon I proposed, it just use differently painted background for different events…
Well, I think that better recognizable and intuitively understandable icon is a good reason
Unfortunately any1 who passed 40-45 age barrier will step on this vision issue, when close small details isn’t recognizable without reading glasses 
I still can read messages without glasses, but small details are really an issue. Without glasses, double checkmark barely loos like a bold single checkmark, so the whole purpose of icon is lost for old farts
IMHO, your idea with eye with check mark inside is most compatible with facebooks icons and much better recognizable and understandable for displaying purpose of “message seen”
I think that eye is the best for the purpose to indicate that message have been seen
Why not a eye whitout a checkmark (as Threema do).
It looks nicer and is also simple to design. 
Or a open envelope as known from Email clients?
An eye with checkmark inside informs that message have been sent (checkmark) and seen (combination of checkmark and oval looks like an eye where is a good correlation between meaning of word “seen” )
In this case, sent message icon (checkmark) might be replace too to closed envelope and there might be the same problem that exist now - close and open envelope when it fits in 27x18 pixels would be barely recognizable (open vs close envelope)
If it’s marked as seen it’s sendet.
There is nothing other thinkable 
I’m also not particularly fond of the checkmark in the eye, and think the “backwards compatibility” may be dropped here. A classic eye should do it as well, and may even have more beauty. 
Rethinking the checkmark for the “submitted, in transmission, on the way, and sitting in the inbox” status, on the other hand… It may be as good as it gets to avoid the icon to raise more questions than answers, and not making it look as messags are always delayed sitting in an unsure “flying”, “queued” , “incomplete” or “waiting” state for too long. Additional reception receipts may be possible to avoid this, but may just create too much unnecessary traffic.
I think there are 3 or 4 state icons useful:
Recived by server
Received by receivers device
Readed
Maybe still a clock while sending is in progress (especially by sending big attachments)
However the icon looks like (eye, check mark or whatever)
If it “readed” then logically it is “Received by receivers device”. I think it would be over-complication to get status “Received by receivers device”.
Current icons do its job well, the only “seen” icon is barely differentiate from “sent” icon, that’s why I suggested to change just “read/seen” icon by accenting it in a round circle or oval as testbird suggested, so it would looks like an eye. I think there’re a lot of more important stuff to do besides of icons, so the easiest fix I think it is just to change “seen” icon.
It seems you misunderstood me
So let me explain:
Why: Leave your device online
Why: If you like, you can switch off your device or cut the connection.
Why: Pushmessage is sendet and shown on receivers device. But the message or DC was not opend yet.
And now, switcht off your devices.
It’s Christmas time 
Merry Christmas to all 
Shortly, DC using email protocols and there no standard mechanism that can utilize this feature.
If sender wants to get status you talking, then receiver device (receiving DC, - to be more precise) must send to sender info that device picked email from receiver’s IMAP folder.
TL;DR
When sender delivering message to sender’s MTA, this MTA either confirms that message accepted for delivery (stage where timer clock turns to single checkmark) or it can send non-delivery notification (It isn’t a fact that sender’s MTA would be able to deliver message to receiver’s MTA. In cases for example when recipient’s email address is malformed or filter on sender’s MTA reject to send to some destination or MTA can’t find receiver’s MX server from DNS and bunch of other cases when delivery on this stage may fail ).
Now let see what is going on receiver’s MTA. Receiver’s MTA is most weak part where a bunch of filters working to prevent spam, forging, abuse and etc. Receiver’s MTA may easily, silently reject reception or politely send back reason for rejection (4xx, 5xx errors).
Let see what’s going next, - if receivers’ MTA accepted email, it isn’t means that it passed to recipient’s INBOX 100% percents. Receiver’s MTA may mark accepted email as a SPAM/FORGED/INFECTED for example when it passing internally message to IMAP server and sieve(RFC5228) may reroute message to a different folder instead of INBOX. IMAP’s sieve may also apply additional filters that can reroute/discard accepted message and it won’t notify sender because IMAP don’t sending messages back to senders.
Ok, let say, we succeed and our message delivered to recipient’s INBOX. If there is connected devices to recipient’s IMAP server, then email client will pick received message (downloads to final recipient’s device) and on the server side message will be moved from “new” to “cur” folder.
That’s it. At this stage delivering email protocols have been done its job. Sender can’t know if receipient’s device downloaded or not yet a message you sent. To get a signal back that this stage was passed on recipient’s side, email client on recipient device should send CUSTOM email back, confirming what you want because there no such feature in email protocols by default. The only standardized related message - is MDN (message delivery notification) that generated by recipient’s email client and also known as delivery confirmation or “message read receipt” or in our case - message seen.
So, what I wanted to say previously, - I don’t want to overload developers to implementing custom signal you want. When you sent email message and you see single checkmark, you can turn off your device at this stage, all steps to delivery your message to final recipient - it is job of receiver’s MTA and their IMAP servers as well recipient’s willing to turn on their devices to grab messages from their IMAP server. IMAP’s can’t send PUSH notification to a client if device isn’t connected, so there also no 100% guarantee that IMAP will tell clients to grab new messages.
IMHO it is more than enough to get standard MDN message (“seen”) to be sure that content of sender’s message was really exposed to recipient. I can’t see any profit form getting status you described - “message is delivered to receivers device but not readed”. May be it helpful for debugging, but have no points in real communication I think. Also, I saw a thread that people who using weak/expensive communication channels
don’t want to overload such channels and notification you want obviously would be extra bytes for them.
Unfortunately, can’t switch off my devices even on holidays, must be available 24/7
Happy Christmas and coming New Year holidays !
You write too much text for my bad english. Still I think I understood what you mean 
Still I think this Markers I mentioned have to be implemented (in later versions) if DC want to be a great messenger. Of course, there are many other things to do first.
This markers are known from all other messengers. And this markers are really usefull for many people.
I’m sorry for too many characters
I just tried to explain that email protocols doesn’t support such marker.
Now as DC is in Play store I got more really DC users in my buddy list.
And now I understand why the second Chekmark should be replaced by a other icon. E.g. a eye or a open envelope.
In other messengers (e.g. WhatsApp) the second checkmark means “delivered” not readed.
So my friends often think my phone is offline because there is only one checkmark. For WhatsApp it means “not delivered yet”.
So a eye or open envelope would be more clear it means seen or readed.
webratte I complained about this time ago at github, check this interesting discussion about the double mark vs eye icon:
https://github.com/deltachat/deltachat-android/issues/485
I think that at least in groups an eye icon with number of views would make much more sense than a fuzzy double mark
The problem is that icons are almost always ambiguous and unintelligible to many people.
Really, the read receipt indicator should be a small readable text-based note in the thread that says “Delivered” or “Seen by Name on Date Time”.
Here are some references & studies about icon usability:
https://blogs.msdn.microsoft.com/jensenh/2005/11/01/the-importance-of-labels/