[BLIP-7] OrgRegistry Clarification

[humbitious]

OrgRegistry Clarification

It is not obvious to a new developer what to do with (or do about) the OrgRegistry in this file: https://github.com/eea-oasis/baseline/blob/master/core/contracts/contracts/registry/OrgRegistry.sol

During the BLIP-6 coding session, four competent and experienced developers (@ognjenkurtic and team) were confused during initial develop/design of the application when considering whether and how Alice and Bob had to be added to an OrgRegistry, whether that process was deprecated (code looked old), or whether one in this simple localhost demo case of the battleship game could simply start with Alice setting up a workgroup and inviting Bob to it.

This requires a) a review of that code; b) MUCH better documentation to ensure that new developers don't stumble here.

---

Copyright Copyright and related rights waived via CC0-Universal.

(This template adapted from the EIP template at https://github.com/ethereum/EIPs/

[GoldenBit0]

Notes from 11/15/2021 Core Devs Session:

• Core Devs to comment with thoughts on this issue
• Once team assesses, someone can use the comment to improve docs

@kthomas @skarred14

[skarred14]

OrgRegistry.sol is used as a registry of registries. It is meant to register unique identifiable identifiers for an organization (name or ENS domain, eth address, signing key, etc.) for discoverability. In addition, as an extension of ERC1820, the OrgRegistry also serves as a way to register the standard interfaces that ought to be used for a given set of organizations. This is done so, by registering a group of interfaces and the orgs leveraging such interfaces as a workgroup. Test cases for these are located in: https://github.com/eea-oasis/baseline/blob/master/core/contracts/test/OrgRegistry.test.js.

Creation of a workgroup is done at the app/service level and is a ts interface method in https://github.com/eea-oasis/baseline/blob/master/core/api/src/index.ts. Corresponding implementation w.r.t provide @kthomas is here: https://github.com/eea-oasis/baseline/blob/master/core/api/src/providers/provide/service.ts

Would be good to specify the list of additions or approach necessary for a simpler usage of the interface implementation to create a workgroup and any associated documentation related updates. @humbitious @ognjenkurtic

[ognjenkurtic]

@skarred14 Thanks. For me to understand completely:

If Alice wants to setup a workgroup and invite Bob, she would:

1. Query the OrgRegistry for Bob's contact details
2. Setup a workgroup in its local BPI with Bob contact details
3. Send an invite to Bob via contact details from the OrgRegistry

Bob would:

1. Accept the invitation from Alice
2. Create a workgroup replica in its local BPI with Alice's contact details

If this is the right approach, Is the OrgRegistry part of the protocol or it can be any third party baseline-compliant source of contact information? Why is it not defined in the standard document?

[GoldenBit0]

Notes from 11/29/21 Core Devs Session:

• @Therecanbeonlyone1969: Addressing question, not specified in standard because it is an implementation detail. No synchronization between the two because implementations are separate, always 1 participant that is offering the service. In current implementations org registry is implemented in shield contract because shield contract manages access control to smart contract, so that not just anyone can write to the contract/s. Nothing in spec requires how to do it, or concept of org registry or shield contract, entirely implementation dependent.

• @ognjenkurtic & working team to review where they got stuck regarding org registry, and make comments here on where / what should be updated.

[GoldenBit0]

@ognjenkurtic Hi Ognjen, can you see the comment above and add additional comments on what/where your team got stuck, prior to the 12/13 Core Devs session.

[GoldenBit0]

12/13/21 Core Devs Session:

• BLIP-6 team will comment here with where they got stuck and what would be needed.

[ognjenkurtic]

This issue arose from our understanding that OrgRegistry is part of the protocol based on the previous example implementations and documentation. We resolved the issue during a Core Devs meeting noted above - in short, OrgRegistry is just an implementation detail which is left for the BPI implementing team to resolve in the manner they see fit, and is not part of the standard specification. I checked the docs and i think there are no subsequent actions needed. The BLIP can be closed.