CallmeT-ty
commented
3 months ago - Architectural decision for Renown we should make early:
- Do we base the identity on an ‘aggregated (web3) identity’ that exists across chains addresses, organisations, badges, nft’s and credentials.
- Do we approach identity as a ‘Organisation specific’ identity, based on the customised reputation system by the organisation. (Arb vs. Maker vs. Lido)
- Most likely scenario: We allow the ‘Aggregated Web3 identity’ to be able to influence the ‘Organisation specific identity’ based on the settings of the organisation. Identity is in the eye of the beholder, in PH’s case the organisation is the beholder.
- Professional persona’s: A document model that represent the professional persona of the user. Needs avater, usersnames etc. It will create an embed of your profile inside messages. In the document we’ll store a reference from your eth identity. Cached pieces of data. How can we include some type of cryptographic proof this is the actual ENS data? e.g. Twitter profile type blue check mark (verifiable credentials?). ENS profiles aren’t required. This is the profile you would be pushing to the different reactors/drives to the different organisations.
- A copy of your profiles lives on the Maker platform, you get the chance to link your renown profile.
- Do you establish a sync link between the two? (Maker Identity vs Renown Identity)
- Branch of your Renown profile and apply some customisation for specific organisations.
- Renown is the repository of all the active profiles. The active directory of the decentralised organisation. [Renown.id](http://renown.id/) as your identity provider. Maybe some organisations will want to create their own ID provider. eg. makerID, using the same software components. SSO & active directory equivalent for DAO’s.