# Rival -- Name Service hApp Spec
###### tags: `spec` `hApp` `design doc`

## Assumptions & Requirements
- **Purpose:** This app serves to create namespaces for other Holochain apps and guarantee uniqueness of name registration within a namespace on a first-come/first-served basis. It manages rivalrous data.
- **Light Consensus confirmed by 3rd party timestamping:** We identify "first-come" based on a lightweight consensus built into countersigning, verified by independent signed timestamping of the hash of a name record. That hash gets sent via RoughTime protocol to (maybe 3?) roughtime servers who report their time and sign their response including a nonce from the request (which happens to be the DHT hash of the name record). We consider the "official" time to be the *average* time of the time servers who signed it.
- **Easy Interoperability with other DNAs:** The app should maximize ease of interoperatiblity for Holochain apps that don't want to deal with the issues around enforcing uniqueness of rival data.
- **Non-rival namespaces for rivalrous names:** A namespace is identified by: DNAhash and can be subdivided into NameTypes.... for which unique names will be be ensured (maybe name def must provde a regex for allowed characters and structure?)
- **Matching hashes across apps:** This app will ensure name uniqueness of Rival ***path entries,*** and co-function with a plug-in zome in other DNAs that store identically structured path entries and rely on this app for their registration and processing.
- For determinism, this design relies on "majority countersigning" (which is being added to Holochain countersigning and will initially have a max of 15 signing counterparties) in both the Service DNA and client namespace zomes.

## hApp name: Rival (for consensus on rivalrous data)
Eventually, this app will have three different DNAs. We may also need some helper zomes to interact with personas/profiles or such things.

### The Three DNAs / Sub-apps
1. **Name and Namespace Registry:** This is the main app which defines namespaces, registers names, and manages hard consensus on both.
2. **Payment data and processing:** This app handles any payments associated with names or name spaces
3. **KYC & Identity verification:** [later] Some orgs may have some KYC or identity requirements in order to register certain names. It would be great if this app could accomplish those things for them (probably via 3rd party providers), so their apps could not need to focus on these issues.

## Phase 1 Scope: Register Names & Namespaces
This is the scope needed to launch the system after a presale of names. The presale will have already collected payments so we can launch without many payment processing methods, with just the name registration / light consensus engine and one simple method of payment (prepaid coupon) and one simple method of KYC (email verification by sending the pre-paid coupon to their email address).

Note: Pre-paid coupons could also allow Junto to make good on its past names sold by issuing a coupon.

## DNA 1: Names and Namespaces
The purpose of this stage:
1. Create namespaces.
2. Register names.
3. Guaranty uniqueness of both.
4. Guaranty exclusive control by only the registrant.

### Workflow 1: Register (& Define) a Namespace
Registering a new Namespace involves defining all the operating parameters of names, payments and interfacing with the organization accountable for that namespace.

#### Data to collect:
**Accountable Org**
- Org Name
- Name of Primary Contact
- Email Address
- Postal Address ??
- Phone ??

**Payment Methods**
- National Currencies accepted: USD, EUR, ??
- Credit card?
- Bank Transfer?
- Crypto: HOT, ETH?
-
- NamespaceID: DNAhash

This involves defining the name types. For example, Holochain's DevHub app has usernames & orgnames. The hAppStore has appnames & publishers.

Namespace: DevHub
  Accountable Org: Holochain
  Hashes:
      # list of DNA hashes for app versions that are all in the space>
  Name Type: User
    Duration: 1 year
    Price: 5 USD
    Structure: [regex]
  Name Type: Org
    Duration: 1 year
    Price: 10 USD
    Structure: [regex]
  Payment Methods: 
    USD:
      Routing_Num
      Account_Num
    HOT: Eth_addr
    HoloFuel: Acct_Pub_key

### Workflow 2: Name Registration

1. Call (bridged from another DNA) to register fn with full name to register, payment method, and payment credentials
2. Compute the hash for the name's path entry and check to see if it exists ([more notes on existence check])
3. If it's available

#### Structure of a Name
Entry def must produce the same hash in each application for identical names. So... does that mean the zomeid and entrydefid need to match? (I think so.). Or... We can use the path type predefined by the system to produce something like "Rival".[Namespace].[Type].[Name]

struct UniqueName {
	Rival.Namespace.Type.Name: 
}

enum Payment {
}
struct Payment {
	Method: e
}

**Existence check for a name:**

**Validation for path entries which start with "Rival" (or "Unique"?)**

### Bridging Nodes
Basically this follows our normal kind of bridging pattern for DNAs where some nodes run an additional DNA. (similar to index nodes, app store + devhub nodes, etc.). Nodes in anction with a plug-in zome in other DNAs that store identically structured path entries and rely on this app for their registration and processing.
- For determinism, this design relies on "majority countersigning" (which still needs to be added to Holochain core and will initially have a max of 8 signing counterparties) in both the Service DNA and client namespace zomes.

## Balance of Powers

### Witnesses of Naming

#### Responsible for:
Majority Counter-signing name registrations
#### Benefits from:
Small portion of revenue from naming payments

### Financial / Payment Processing

#### Responsible for:
Processing payments for name registrations and namespace registrations, pro-rating the accounting of who should receive revenue from a registration, and making monthly payments to appropriate parties per the pro-rated accounting.

#### Benefits from:
Small portion of revenue from naming payments

### Software Provider

#### Responsible for:

1. DNA & UI Development
2. DNA & UI Maintenance
3. Tech Support

#### Benefits from:

Large Portion of revenue from naming payments, up until some threshold of recouping capital where splits could/should rebalance some and price could drop.

### Client App(s)

#### Responsible for:
- registering a name space (and paying for it)
- bringing the "audience" i.e. people who need names in that space, to the table

#### Benefits from:
- Potentially the largest Portion of revenue from name registrations.

## Outstanding Issues to Resolve

### Namespaces
Should we have a human friendly namespace of namespaces for Rival?
- Pros: a bunch more pre-sales?
- Cons: a pseudo global top for namespace names?

What official Holochain Foundation namespaces will be a part of this offering and managed by Rival?
- HOW / Alignment: users, orgs, proposals?
- DevHub: users, orgs (not app names?)
- AppStore: app names (plus users & orgs from devhub?)

What official HOLO namespaces should be part of this offering and/or managed by Rival?
- HoloFuel account names?
- HoloHosting app names (distinct from domain names)
- .holo domain name TLD pre-registrations?
-

### Finances

### Operations

### Tech