Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Profile showcase data sharing #4143

Closed
MishkaRogachev opened this issue Oct 11, 2023 · 2 comments · Fixed by #4209
Closed

Profile showcase data sharing #4143

MishkaRogachev opened this issue Oct 11, 2023 · 2 comments · Fixed by #4209
Assignees

Comments

@MishkaRogachev
Copy link
Contributor

Problem

Screenshot 2023-10-10 at 19 32 37

A user can present communities, wallet accounts, assets and collectibles in profile showcase. Those preferences can have four levels of visibility:

  • NoOne
  • IDVerifiedContacts
  • Contacts
  • Everyone

Profile preferences should be available to other users based on their level of visibility. For example, mutual contacts can see the Contacts and Everyone groups, but not IDVerifiedContacts.

Implementation

I propose to discuss the implementation of access levels in the commentary. We have previously discussed two approaches:

  • Send broadcast messages encrypting Contacts and IDVerifiedContacts for mutual contacts and for id verified contacts. (Will probably need to add two key pairs here).
  • Send Contacts and IDVerifiedContacts levels in 1-to-1 mode, running through the contacts list.

Acceptance Criteria

  1. Add broadcasting message for profile showcase preferences
  2. Send messages after showcase preferences were changed, contact added or id verified
  3. Add table with latests obtained showcase preferences for each known user
  4. Add endpoint for getting showcase preferences by contactID
@MishkaRogachev
Copy link
Contributor Author

@osmaczko @cammellos @jrainville call for discussion :)

@jrainville
Copy link
Member

While Send Contacts and IDVerifiedContacts levels in 1-to-1 mode, running through the contacts list is the simplest way in terms of implementation, it will end up being very bad for the network as it does not scale, since we will send a message to all of our contacts or ID verified contacts each time.
It might be valid in the short term though if we want to iterate fast.

The other option of sending the message to a specific topic but where only the users with the permission can unencrypt it is way better, but it poses a problem in terms of key management.
We'd now have two places where it can fail instead of one, it can fail at receiving the message per se and it can fail receiving the key, making the message useless.

One way that we could mitigate that is by making it that contacts can ask directly for the key when they receive a profile showcase message they do not understand. There is still the chance that the original account will miss that request, so we need to have some retry mechanism.

All in all, this is way more complex than using the 1-1 mechanism. Unless the community and/or group chat key distribution mechanism can be reused? I'm curious to hear for others.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants