Properly name privacy settings for display name and avatar

[MorrisJobke]

This setting was introduced with f489fd9 in #1946. I could not find any hint that this was ever working local only. Thus this should be changed to "private" to properly reflect what it is doing.

Background is that the properties aren't synced to the system address book if the setting is "private".

Fixes #10317

[nickvergessen]

Yeah the thing is your displayname and avatar are still shared in the instance (search on the share API, talk, etc.)
So it's never private in terms of "no one sees this". That's why it is called local instead of private.

[MorrisJobke]

So it's never private in terms of "no one sees this". That's why it is called local instead of private.

We just received complains, that the contacts menu does not show the user name in those cases. That is because there the system address book is used instead of the local user backend. :/

[schiessle]

I think @nickvergessen is right. Avatars and Display names are always internally visible

[MariusBluem]

Not really private ... in some places not really local as expected - what do you think about restricted as term 🤔

[schiessle]

We just received complains, that the contacts menu does not show the user name in those cases. That is because there the system address book is used instead of the local user backend. :/

Yes, but I think this is a "bug" of the contacts menu. It should work like for example the share dialog which can also find and show the display name and avatar, even if it is set to private. Changing the label of the settings doesn't solve the problem.

[MorrisJobke]

Yes, but I think this is a "bug" of the contacts menu. It should work like for example the share dialog which can also find and show the display name and avatar, even if it is set to private. Changing the label of the settings doesn't solve the problem.

The problem here is that the contacts menu uses the system address book and we need to find a way to determine which of the users are local ones and that then the user backend needs to be checked for further details. So this is more an issue of a proper integration of the many different backends into each other: Something like #4493

We also discussed about this at the conf - cc @jancborchardt @daita @skjnldsv @rullzer

[schiessle]

The problem here is, that the system address book was never meant to be used internally but only to sync between trusted servers. That's why it doesn't contain the display name / avatar when it is set to private, otherwise we would sync it to the trusted servers. All internal operations should always talk directly to the user management. That's why I believe that it is a bug in how the contacts menu was implemented and it should use the internal user management instead, like any other functionality in Nextcloud.

[MorrisJobke]

The problem here is, that the system address book was never meant to be used internally but only to sync between trusted servers. That's why it doesn't contain the display name / avatar when it is set to private, otherwise we would sync it to the trusted servers

I know - but it is also queried by the contact menu to show exactly those users as well: the ones from another system. 🤔

Because otherwise the menu would only show internal users and the sync of address books doesn't make any sense at all.

[schiessle]

Yes, the menu needs to query multiple sources. The local user management, address books of the user, the address books synced from trusted servers,... etc. But the local users should be looked up in the internal user management. Basically exactly how the share API does it. There we also find local users over the local user managements, find users from trusted servers over synced global address books and personal users over the user specific address books.

I don't know the exact implementation details out of my head. But looking at the sharing code should give an idea how it should be implemented for the contact menu as well

[MorrisJobke]

Yes, the menu needs to query multiple sources. The local user management, address books of the user, the address books synced from trusted servers,... etc. But the local users should be looked up in the internal user management. Basically exactly how the share API does it. There we also find local users over the local user managements, find users from trusted servers over synced global address books and personal users over the user specific address books.

But aren't then local users shown twice because they are also in the system address book or is there one for local users and one per trusted server?

[schiessle]

in the share dialog it works without showing users twice, so it should also work here. As said, for details we need to check how it is implemented in the share API

[jancborchardt]

Important is that we don’t design it based on the technical difficulties we have right now, but on what it ideally should be. That’s why we have the 3 settings.

One issue from the UX point is that profile picture and full name have a slightly different first setting, being "Local" instead of "Private" as email and all the others use:

Considering there is already a "Contacts" option which includes local users, I see 2 ways we move forward:

• We change the first setting of full name and avatar to really be "Private", excluding local users. I don’t really see this making sense though.
• We simply remove the first setting "Local" from full name and avatar and set default to "Contacts".

What do you think? Is there another way?

[schiessle]

We simply remove the first setting "Local" from full name and avatar and set default to "Contacts".

This doesn't work because as you can see at the description "contacts" includes trusted servers and I think there should be a difference between going full public (trusted servers and lookup server) and only make it visible to "trusted contacts".