feat: Don't attach profile data in group leave messages

[iequidoo]

No description provided.

[r10s]

as there is no "why" explained in the PR description:

what is the gist of this change?

if Alice is in two groups with Bob, and Alice leaves one group - why should Bob not get the updated image for the other group? this is esp. useful if Alice does not write so often - or if Alice meanwhile hated the old profile image and wants it to be overwritten asap :)

[iequidoo]

I added the motivation to the commit message now:

I think we can't use group leave messages as a really useful transport of profile data, i.e. if the
user rarely send messages, sending their profile data in group leave messages doesn't solve the
problem of stale profile data completely, but that may create privacy issues, e.g. the user may want
to leave a group because it's not private enough and the user doesn't want to share their data with
some members whom they may not even know, the user might be added by mistake etc. In the end, if the
user really wants to share their data, they can send a farewell message.

I don't insist on this change though, the PR can be closed if doesn't look useful.

[r10s]

thanks for the detailed description!

i do not think, here is a privacy issue. even if the avatar/bio is not sent immediately on adding, it is communicated and expected behavior know from other apps that these profile data are shared with all contacts and groups

adding extra technical rules there makes things harder to explain - and maybe more rules would be needed for other cornercaes and future changes ... tbh, i would not like this discussion on avatar/bio all the time, who was first, slight, hard to get differences on adding etc.

for bigger groups one usually uses an invite link, and in that case we even consider to send profile on joining.
that way, others see your profile immediately - which is a critical thing for multi-transport, as a basic point to identify someone

it is a pretty much cornercase anyways - and i am always hesitant to add too much code and compexity (even if few it adds up in the future) for cornercaes unless really needed. and i do not see this here

but i do not die on that hill, maybe just wait a bit and see if other have different points

in any case, we can use the test to manifest what we really want eventually

[iequidoo]

even if the avatar/bio is not sent immediately on adding, it is communicated and expected behavior know from other apps that these profile data are shared with all contacts and groups

I think it's rather expected by users that their profile data isn't shared with all contacts, at least incoming contacts mustn't see profile data. For me it's strange that it may be shared with contacts i'm not possibly going to communicate with. Let's wait for more opinions here, maybe keep the code as is and just adapt the test.

[adbenitez]

+1 to @r10s I was also surprised by this PR when I got the email notification, I think it is good as it its with sending avatar etc. This is public data you share with your contacts

To have you in a group you had to be invited on the first place or have exchanged contact with the person, so there is no point in trying to protect theoretical situations that doesn't happen in the practice, Delta Chat is a private messenger, not to chat with people you then suddenly don't want to share your profile info with

If you share your invitation link publicly you will also automatically share your profile info with anyone that scan it. I think sending such info on leaving a group is more useful than not. Ex. The person may set the profile image to have a warning and the bio to say "I moved to another profile click here to contact me, don't write to this address anymore" and then leave the group

[r10s]

to amend, there are vcards, which encourage sending these information around - it is the way to identify user.

closing, for said reasons.

maybe keep the code as is and just adapt the test.

yip, that makes sense, to settle the findings of this discussion in a test. but that better goes to another PR then

[iequidoo]

so there is no point in trying to protect theoretical situations that doesn't happen in the practice, Delta Chat is a private messenger, not to chat with people you then suddenly don't want to share your profile info with

For me this is a real case: i have big groups where i haven't written for some time, and i don't know who new members are, they can't see my profile, but if i leave the group, they will. IMO data privacy isn't a transitive thing, it's ok if my profile is shared via a vcard, that's a manual action, but i'd avoid auto-sharing profiles if it's not strictly necessary.

Secondly, currently if the user is added to a group or joined via an invite link, nobody (except the inviter) sees their profile until the user leaves the group (or writes smth). I don't think this can be explained as expected behavior, rather the inviter should broadcast the user's profile in the Chat-Group-Member-Added message then.

[link2xt]

Re discussion in #7007 (comment)
I'm fine with reviving this PR and merging.

We don't have clear rules regarding what is "profile data" as opposed to e.g. Signal where profile is a single structure uploaded to servers and whether you can see it or not is explicitly managed by giving some decryption key to contacts. But it's fine to handle this case with a test and forget about it until something breaks the test and we look at the test description.

[iequidoo]

We don't have clear rules regarding what is "profile data" as opposed to e.g. Signal where profile is a single structure uploaded to servers

It's not stated officially, but technically it's data which is started being shared with contacts when they become verified. The whole logic is in mimefactory. Currently "profile data" is displayname, self-avatar and self-status. If we plan to merge #7007, i'll revive this PR, it will simplify the logic in #7007 (no need to make difference between accepted and "contact request" chats). Otherwise this PR remains closed as discussed above.

[link2xt]

It's not stated officially, but technically it's data which is started being shared with contacts when they become verified.

Some contacts never become verified, you may get in contact via unverified group or vCard. We still want to share avatar to such contacts. Generally the plan is to reduce the distinction between verified and non-verified chats and contacts: #7080
Just like in Signal, you share avatar to accepted contact regardless of whether you have verified out of band or not.

[iequidoo]

Some contacts never become verified

True. My previous message is about automatic messages like SecureJoin ones. The idea is that there should be no automatic messages revealing your name/status/etc. to unverified contacts (e.g. vg-request and vg-auth-required are sent to not yet verified contacts). But if a message is sent manually by the user, it's expected that everything is shared, even in unencrypted emails. But as for group/broadcast leave messages, they also should be considered "automatic" because actually the user just doesn't want to receive/store messages related to the chat, i.e. it may be unclear to the user that smth is sent to the group or the broadcast owner to actually unsubscribe them.
...
It's indeed better to talk about accepted contacts. Verified contacts are just a subset of them.

[hpk42]

On Fri, Aug 08, 2025 at 12:00 -0700, iequidoo wrote: iequidoo left a comment (chatmail/core#6813) > Some contacts never become verified True. My previous message is about automatic messages like SecureJoin ones. The idea is that there should be no automatic messages revealing your name/status/etc. to unverified contacts (e.g. `vg-request` and `vg-auth-required` are sent to not yet verified contacts).

i don't see why it would be neccessary to make distinctions. If i show or publish an invite link, i can not expect my profile data to not leak to joiners. IOW, we can send "profile data" within any encrypted message, no matter if verified or automatic.

[iequidoo]

IOW, we can send "profile data" within any encrypted message, no matter if verified or automatic.

Maybe my explanation wasn't clear enough. But v*-request isn't encrypted, that's why we don't send our name/avatar in it. v*-auth-required is encrypted though, but at this moment we don't know yet whether it's encrypted to the true joiner or MITM. In the latter case SecureJoin fails, but we don't want attackers to collect user's data. All this is test-covered in securejoin_tests.rs.

Anyway, AFAIU SecureJoin will be reworked completely soon, so we will get rid of this logic.