show group with only SELF as "encrypted" if smtp is skipped as bcc_self is disabled?

[Simon-Laux]

• Operating System (Linux/Mac/Windows/iOS/Android): MacOS
• Delta Chat Version: Desktop 1.30.1, core v1.84.0
• Expected behavior: messages sent in chat are encrypted, encryption info show stuff
• Actual behavior: messages sent in chat are not encrypted, encryption info shows "Fetching...."
• Steps to reproduce the problem:

1. create a new group chat with only yourself as member
2. send a message

[r10s]

at least in recent tests on devices lying around here, groups are encrypted when only SELF is member. so, can you please double-check, maybe it happens only under special circumstances or so.

for the encryption info: the "Fetching..." message probably comes from desktop. core returns an empty string in case only SELF is group member, this does not look good on android as well, would be better if we always return sth.

[Simon-Laux]

so on linux it works with the encryption... strange, but all accounts I tested are older than the accounts i had the issue with, so it still needs testing with a fresh account

[r10s]

needs testing with a fresh account

indeed that may have make a difference, however:

i just tested a fresh installation of an existing account in the repl-tool and a fresh installation with completely unused account (testrun invitation) in ios - both are fine, groups with only SELF are encrypted.

(all with core86)

[Simon-Laux]

[i]core/event: 19 DC_EVENT_INFO 0 src/chat.rs:2060: message Msg#65608 has no recipient, skipping smtp-send

So it's actually the "send copy to self" setting that is what affects it, makes some sense, though when message is not send out and its only sent to self the messages could/should still show the padlock so users feel safe, even if those messages are only local not sent anywhere

[r10s]

ftr, by the recent change to enable bcc_self by default, this issue is becoming more rare.

as one can argue somehow for both - (a) padlock should be shown to let ppl feel safe vs. (b) padlock should not be shown as nothing is actually encrypted - it seems reasonable to go the easier way and just close this issue :)