NomDeNet - General Note

# NomDeNet - General Note ###### tags: `Technical Specification` <style> .ui-infobar, #doc.markdown-body { max-width: 1000px; } </style> #### Reference - Art's document of [Namesake/Rival](https://hackmd.io/LrHhgaXIQCCOQS0nGxtR9w#Phase-1-Scope-Register-Names-amp-Namespaces) - [First Phase Technical Documentation](https://hackmd.io/OWmXgf-vTz68o7t4K1U7iQ) #### Glossaries - Client Happ: Any happ (clutter, junto, kizuna, hrea, etc) that will include the 3 namesake dnas as part of their happ bundle. - orgs/organization: The organization that wishes to register a namespace in the Namesake/Rival Happ. Most of the time the Client Happ distributor as well. - Namespace: Kind of like a mini bubble where different nametypes can be registered which then can house unique names under them. Registered by the organizations. - Nametype: A mini-mini bubble inside the mini bubble of namespace where unique names can be registered. One namespace can have multiple nametypes. - Names: A unique name that can be registered under a nametype. ## Components of the First Phase ### 3 DNAs #### Name and Namespace Registry DNA - handles name and namespace registration - to create a name in the client hApp, check first if you own the name in the Rival/Namesake hApp (make sure that agent keys match) - name registration will need a light consensus based on majority countersining (Holochain's M of N - [to be implemented by Holochain](https://github.com/holochain/holochain/pull/1394)) - name uniqueness will be done through paths and LinkTypes. The same name entry will be committed both on the client Happ DNA as well as in the name registry DNA. - hashes across hApps and Rival/Namesake should match: `Rival.[Namespace].[Type].[Name]` - make LinkType indices match between Client Happ and Namesake/Rival Happ. #### Payment data and processing DNA - any action in the Registry DNA that needs payment related information will bridge call to this DNA - coupons are the main currency for the First Phase (Pre-sale) - three types of coupons with their allowed statuses - Name coupons redeemed in payment portal (only status: redeemed). FIXED number. - Namespace coupons redeemed in payment portal (only status: redeemed). FIXED number. - Free name coupons given out in the Namesake/Rival Happ interface (status: Not redeemed/Given out/Redeemed). Coupons can be replenished. - counterchecks a supplied coupon code with an existing list in DHT to check validity of code - code is valid => operation in Registry DNA can proceed - this DNAs DHT will be populated with a set number of pre-generated coupon codes - coupon codes are simply random hash strings (derived from? just needs to be unique) - coupons can be purchased from a separate payment interface (centralized) - depending on the bundle purchased, an x number of free names can be given out with every purchase of a Namespace - One easy way to do this is to just give x number of coupon codes to the namespace org owner when they apply for namespace and have different coupon types for easy counting (as stated above) #### KYC & Identity verification (done indirectly through the payment portal for now) - coupons purchased will be sent to a registered email address ### Interfaces - **Payment Portal:** for purchasing coupons - Any individual who wishes to register a unique name under a specific nametype defined in a namespace should pay here to receive the coupon they can use to register a unique name in the client Happ. - Orgs who want to register a Namespace should pay up first outside of the Namesake Happ during presale. They receive a coupon which they can later on use to register a namespace. - **Namesake/Rival Happ Interface:** for orgs to use the coupon and register namespace and define nametypes ### Pluggable Zome - will be plugged into client DNAs that wish to make a bridge call to the Namesake DNAs - operates alongside the name registry DNA to make sure that the name hashes are equivalent between the client hApp and Rival/Namesake - implement a mechanism to make LinkType indices match (check Integrity Zome) ### Tech Stack - Interface for Orgs to register namespace/name types (Frontend) - Vue.js - Data Layer - Holochain - Deployment - Holochain Launcher - CI/CD - Github actions - Backend Testing (DNAs) - Tryorama/Sweettest - Frontend Testing - *TBD* ## Actors ### Organizations - organizations who want to implement some sort of name uniqueness within their hApp ### Witnesses - a dynamic set of agents that countersign the creation of a name - the set of agents can be changed and maintain continuity through key management with DeepKey (DPKI). Keys can be passed and source chains copied from old to new witnesses - gets paid for performing the role - selection and proof of identity as witness (?) - witness performance can be done by checking the chain activity of each witness and if one witness falls behind the chain link significantly, then we can do something about it. - If the countersigned name entry's signatures need to be validated by the public key of the witnesses, we need a way for validators to know the AgentPubKey of the witnesses - one way to do this is by having the witness install the namesake Happ with a property (can be coupon code for witness). And in init() we check whether the agent has the coupon and if it does, we commit its AgentPubKey to the DHT with a known path. The only caveat here is that these witnesses must run the agents in the namesake happ before any other agents do (so that validations work properly). - We have to make sure there are strong mechanism in place to prevent bad actors to claim that they are witnesses when they are actually not. ## Products ### Names #### Names under a Namespace - defined by a path starting from the general space to more specific - i.e. Rival.[Namespace].[Type].[Name] #### Global Names - an opt-in system where Orgs can choose to participate whether their names' uniqueness should be checked against a global set of unique names - opt-in - their names should be unique within their namespace and within the global space - orgs get a share of the profit from the global names' pre-sale #### Namespace(?) ## Outstanding Questions to Answer - **[Design/Business]** Are namespaces unique as well? (can be a bunch more presale as mentioned in Art's hackmd.) - **[Design]** Can Orgs update the name types? They should probably be able to add more name types but not remove name types since that can cause problems with name registered under that name types? - **[Design]** Can orgs opt in to the global name registry in the future if they choose to opt out in the registration? Probably not since that would mean that names that aren't globally unique will be rivalrous and have to be dealt with. But possible if we figure this part out. - **[Design]** We have to figure out how to commit the prepaid coupon code in the DHT before presale. Membrane proof? probably not. in the init() call? maybe. [link to possible implementation - put link here later]() - **[Design]** How do we identify a particular Agent as Witness when that agent installs the Namesake Happ? Probably not membrane proof. Probably in init() call? but what do we check against in init() call when there is nothing on DHT yet? - **[Design]** Guillem's question: "should I use the entry hash or the header hash to refer back to things in the rival dna during my happ's validation? If it is headerhash to check the author of the entry, there might be problems when the DNA hash changes (udpate) since headers are lost" - **[Design]** Updating the integrity zome in the future will require us to migrate all entries to a new DHT with new DNA hash. Does this mean we cannot rely on the Headers (since they are not migrated with Entries) to know the author of the unique name entry? This is probably a yes. If so, we should probably have another countersigned (maybe not required) entry that contains the agent_pub_key and the entryHash of the unique name entry committed in the source chain of the witnesses. Then these witnesses can migrate all these entries to the new DHT and we will not lose the author of unique name entries provided that AgentPubKeys stays the same across multiple happ versions? - **[Business]** How should we pay the witnesses? Since we are going for simplicity in the first phase, we should probably do something similar to what Holo is doing in HoloPort Alpha Program and just manually pay them or issue IOUs for now? - **[Design]** Are unique names renewable? is this part of the first phase architecture? (we probably dont have to yet since this is something that can be done in coordination zome and DNA hash wont be affected... hopefully) - **[Business/Design]** It was suggested in the Google slides that global names will go up in value every 3 years. What can we implement/not implement in the first phase of the Namesake so that we can scale to meet this requirement in the future with less friction - **[Design]** Can we have a walkthrough again on the process of countersigning with Enzymes? ## Progression to Further Phases ### 3 DNAs #### Name and Namespace Registry DNA - Connection to the RoughTime Server (not yet included in the first phase) #### Payment data and processing DNA - On chain payment (???) - Handling of sales/payment outside of the presale window #### KYC & Identity verification DNA - adds business proposition value in case of competitors - bank payment acts as a light KYC already - will be implemented after the first phase of the project ### Interfaces - for orgs to use coupon and register namespace and nametypes - for payment of namespace (implemented later phase)