Add JSON-RPC API to list past members

[link2xt]

Past members are now sent around even though we are going to expire them after 60 days with #6430.
To make users aware of this we need to display them somewhere, naturally at the end of the member list after all the current members.

There is a Rust get_past_chat_contacts API, but we also need a JSON-RPC API to display this list at least on Desktop.

[hpk42]

On Thu, Jan 16, 2025 at 02:53 -0800, l wrote: Past members are now sent around even though we are going to expire them after 60 days with #6430. To make users aware of this we need to display them somewhere, naturally at the end of the member list after all the current members.

Could you provide a rationale for why past members need to get displayed? (Just because core has some info does not imply it needs to be displayed.) If delta does not expose past members in UI, then someone who seizes the phone can not directly find out who was part of a group but needs to deploy some extra software and extraction. So it's rather not desirable this real-world scenario to have any past member show up in a UI. It's better to rather update/add our FAQ entries then around metadata questions.

[r10s]

showing that in the UI might also frighten ppl unnecessarily and create an incentive to have an option to get removed even from there -- where in reality, it is not an secret that one was in a group at all, providing these information some more days, does not add much -- a new member could also just ask another member if XY was in the group, having in mind, we do not see group members as enemies. for ppl watching network traffic or owning the server, the information are anyway not visible as usually e2ee

[link2xt]

This information is sent in the network and past members are even added to the contact list of new members joining the group, so it is better if users are aware why this happens.

If delta does not expose past members in UI, then someone who seizes the phone can not
directly find out who was part of a group but needs to deploy some extra software
and extraction.

I think it is better if users know this information is there and can be extracted. If they need security in such scenarios, they need to create a new group or maybe even new burner profiles.

I can think of some scenarios when my non-public account was added to groups that are meant as somewhat public groups. I then added my other profile and left the group. Since past members are sent, now in such case I need to clone group and say "use this to onboard people, the original group has wrong profile of mine" instead of adding public profile and leaving.