gnoland: team support

[moul]

Allow a registered user to transform into a team by publishing a contract that registers the members in a registry. This will involve creating a new r/sys/teams realm to manage the many-to-many relationship between teams and members.

New Realm: r/sys/teams

• Purpose: Keep track of the many-to-many relationship between teams and members.
• Authentication: Verify if the caller is r/<handle>/home to take <handle> as the team name.
• PR feat: add r/sys/teams #2184 implements this logic.

Next Steps

1. VMKeeper Logic:

   • Only allow adding a package under a specific handle (p/<handle>/* or r/<handle>/*) if the tx author is the user with that <handle> (1-1) or a member of the team (many-to-many).
   • Related with feat: add r/system/names #375, Namespace support for package paths #1107, ... (list is longer)

2. Demonstration of the flow to create a team

   1. Create a new private key.
   2. Register a user account on r/gnoland/users.
   3. Upload r/<handle>/home importing r/sys/teams and configuring it statically or dynamically.
   4. Register members via the contract.

3. Other considerations

   • Team to User Conversion: Block for now the option to convert back a team into a user for now.
   • Bonus: List team members and member’s teams in u/<handle> (see gnoweb: new u/<handle> page #2189).
   • Onchain keypair burning: Implement a way to "burn" a public key on-chain, making it unusable after team creation to ensure only team members can act on behalf of the team.

[zivkovicmilos]

We have added a large part of this issue in #2471

Closing this issue as completed, but will keep tracking the teams support elsewhere 🙏

[moul]

sequenceDiagram
    participant Alice
    participant r/users
    participant r/alice/foo
    participant r/alice/home
    participant r/alice/bar
    participant Bob
    rect red
        Alice->>r/alice/foo: addpkg=failure
    end
    rect green
        Alice->>r/users: Register("alice")
    end
    rect green
        Alice->>r/alice/foo: addpkg=success
    end
    rect red
        Bob->>r/alice/bar: addpkg=failure
    end
    rect green
        Alice->>r/alice/home: addpkg=success<br> (set Members=Alice+Bob)
    end
    rect green
        Bob->>r/alice/bar: addpkg=success
    end
    rect green
        Bob->>r/alice/home: addpkg --override<br> (update members or <br>remove them to come back to single user)
    end

Loading

Here is the flow I have in mind, which depends on the following:

• r/sys/teams to support registering members from a r/<handle>/home realm
• overrideable realms so that the home realm becomes a special realm that you can regularly update to fine-tune your personal or organizational presentation and configuration.

[moul]

Based on my review of #2957, let's add some details or clarify points that weren't obvious enough.

• Name management is handled by r/sys/users, not r/sys/teams. There is nothing related to names in r/sys/teams.
• Team creation cannot accept an address as an argument. It is not a user who calls the r/sys/teams realm to create a team or multiple teams; rather, it is a user account that initially uploads a new package in r/<handle>/home. This package will import and call r/sys/teams to configure itself, without passing an std.Address for the team. The address is determined by r/sys/teams, which looks at the parent realm in the realm caller stack.
• Members may eventually be users.User, but for performance, independence, and minimalism, let's use std.Address for members.
• As a suggestion, we could have AddMember and RemoveMember, but it might be better to implement a SetMember method. This usually provides a simpler API and better usability.
• There is no "team permission," only "member permission."
• Additionally, using an arbitrary string for member permissions does not seem ideal. I would recommend targeting p/acl or considering another mechanism.