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

Discuss Credential groups #342

Closed
vplasencia opened this issue Dec 6, 2023 · 8 comments
Closed

Discuss Credential groups #342

vplasencia opened this issue Dec 6, 2023 · 8 comments
Assignees
Labels
refactoring ♻️ A code change that neither fixes a bug nor adds a feature
Milestone

Comments

@vplasencia
Copy link
Member

vplasencia commented Dec 6, 2023

Right now you can join different credential groups using the same credential, for example using GitHub you can join a group for people that have more than 2 followers and another group for people that have more than 3 followers. But if you join one of these groups, and then you are removed from that group, you can't join that group again, is this behavior fine, or it is better to remove people from these groups and then let them prove that they meet the criteria and join again? Or is it better to prevent group admins from removing people from the groups?

Other issues related to credential groups:

@vplasencia vplasencia added the refactoring ♻️ A code change that neither fixes a bug nor adds a feature label Dec 6, 2023
@vplasencia vplasencia added this to the 4. Dione milestone Dec 6, 2023
@0xjei
Copy link
Collaborator

0xjei commented Feb 16, 2024

Right now you can join different credential groups using the same credential, for example using GitHub you can join a group for people that have more than 2 followers and another group for people that have more than 3 followers. But if you join one of these groups, and then you are removed from that group, you can't join that group again.

Thank you for the explanation! Very well stated 😊

is this behavior fine, or it is better to remove people from these groups and then let them prove that they meet the criteria and join again?

The nature of the use case strongly influences the approach. It is best to limit the scope to necessary interactions and delegate choices to the end-users / admin. We can consider to add a flag during the group creation phase to allow or disallow rejoining after removal.

Or is it better to prevent group admins from removing people from the groups?

My previous proposal included a flagging system for groups. These settings should be visible to participants to ensure they are aware of the group's rules before joining. This will prevent users from being arbitrarily removed and unable to re-enter.

Other issues related to credential groups:

This is incorrect. The admin should be able to delete the group only when there are no members. Need to be fixed.

Agree, this is very cool. We can think to provide a sort of search engine with a bar, filters, and ordering!

@aguzmant103 @vplasencia

@aguzmant103
Copy link
Collaborator

Thank you @vplasencia for summarizing the problem very well
Agree with @0xjei i think the flag during group-creation would be the best path forward

Client apps then should alert users they're joining a "they can kick me out" group


Last question: is this architecture / feature possible when we go onchain?
I would imagine yes, it should be a simple boolean field that controls what admins can or can't do

@0xjei
Copy link
Collaborator

0xjei commented Mar 29, 2024

Thank you @vplasencia for summarizing the problem very well Agree with @0xjei i think the flag during group-creation would be the best path forward

Client apps then should alert users they're joining a "they can kick me out" group

Last question: is this architecture / feature possible when we go onchain? I would imagine yes, it should be a simple boolean field that controls what admins can or can't do

Thank you @aguzmant103 for going through everything so well!

Yes, absolutely! You are right! They can be one or more boolean values or whatever data structure best optimises the gas consumption on-chain.

@0xjei
Copy link
Collaborator

0xjei commented Apr 12, 2024

@aguzmant103 @vplasencia should we move this to Github discussions?

@aguzmant103
Copy link
Collaborator

Agree it's best suited there @0xjei

Idk though if we need to discuss it further or if it's a "decision taken" and we need to create new issues based on this decision

@0xjei
Copy link
Collaborator

0xjei commented Apr 17, 2024

Agree it's best suited there @0xjei

Idk though if we need to discuss it further or if it's a "decision taken" and we need to create new issues based on this decision

Agreed, feel free to post your feedback here (and @vplasencia too) to get a consensus on the relevant issues. My views:

  • define settings / rules per group at creation time (e.g. "The admin can delete the group if there are no members", "The admin can decide to arbitrarily remove you from the group", etc.)
  • create a search engine for groups on the home page of the dashboard (filters, labels, other features)

@aguzmant103
Copy link
Collaborator

Agree @0xjei

@0xjei
Copy link
Collaborator

0xjei commented May 2, 2024

Agree @0xjei

Brilliant, I proceed to create the issues and consider this closed.

See #495 & #496

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactoring ♻️ A code change that neither fixes a bug nor adds a feature
Projects
Status: ✅ Done
Development

No branches or pull requests

3 participants