Page Comparison

# Namespaces

## Theory

### Names

In the rho calculus, names are quoted processes:

    P is a process ⇒ @P is a name.

Rholang allows not only quoted processes but also private names†.  All values are processes, and [Uniform Resource Identifiers](https://tools.ietf.org/html/rfc3986) (URIs) are one kind of value.  Since URIs can contain parentheses, Rholang delineates URI names with backticks.  We could, for instance, request a session with an HTTP server as follows:

    `https@`https://rchain.coop`!*ret | for (([send, rcv], fail) <- ret) { ... }

#### URIs, URLs, URNs

[Uniform Resource Locators](https://www.ietf.org/rfc/rfc1738.txt) (URLs) are a special kind of URI; they have enough information for a resolver to locate the resource rather than merely identify it.  [Uniform Resource Names](https://tools.ietf.org/html/rfc8141) (URNs) are a method of naming a resource.  In the context of Rholang, a name is sufficient to locate a channel, but not necessarily to connect that channel to some resource external to the node or the blockchain.  The IANA maintains a [list of organizations](https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml) that manage specific URN namespaces.  The RChain cooperative should register to manage the `rholang` URN namespace.

### Rholang Namespaces

A namespace is an expression in some language that denotes a set of names.  Rholang has keywords for describing sets of terms (`true, false, &&, ||, ~, =>, exists, forall`) as well as type expressions denoting built-in Java types.  Rather than try to adapt this language to URNs, Rholang uses [Express-style path expressions](https://github.com/pillarjs/path-to-regexp) to denote sets of URNsURIs.  We will discuss the use of variables in path expressions below.

## RChain Namespace Registry

### Overview

An RChain node obeys the relevant standards for resolving URLs and exposes the corresponding protocols on those channels.  URNs, on the other hand, are used exclusively for communicating within the RChain node or on the blockchain.

As manager of the `urn:rholang:` URN namespace (hereafter "RNS") and as the author of the RChain platform, RChain is in a position to set policy around names in that namespace.  Rholang treats all URNs outside the RNS as public bidirectional names.  Names in the RNS, on the other hand, are aliases for names in the registry.  Clients will typically generate a private name pair using the Rholang `new` keyword, and then register a public alias for the output name.

    // The iopair type implicitly creates a forwarder that listens
    // to output and sends on input. In all other processes,
    // input can only be listened to and output can only be sent to.
    new [(input, output]):iopair in {
        register![(*output, "urn:rholang:iana:example.com/:service_id/:data", payor]) |
		// If you don't own a domain, you can use a UUID
		// register![(output, "urn:rholang:uuid:d3749e6a-c6cc-4eec-9043-d4080e74bf60/:service_id/:data", payor]) |
        for ({msg(@msg, service@service_id, data}@data) <- input) {
            ...
        }
    }

Despite the fact that all information is stored publicly on the blockchain, no other process can listen on the name `input` because names created using the `new` keyword can be neither dereferenced nor constructed from a string.  The name `output`, on the other hand, is effectively made public with a memorable alias.

As illustrated in the example above, when a path contains a variable, the variable gets bound to the path component and sent as part of the request on the input channel.

The registry itself is a privileged Rholang contract like the Rev wallet.  All nodes keep a copy and use Casper to agree on what the current state of the registry is and who has the right to set the alias for which names.  The initial segment of a domain path must be a domain name and ownership of the domain must be demonstrated in one of the [usual ways](https://support.google.com/webmasters/answer/35179?hl=en#verification_details).  Allowing entities to register domain names that aren't the owners of the domain will inevitably lead to phishing attacks.  The coop should have discussions about what other formats they want to support and the policies around them.

Quoted processes get encoded as `urn:rholang:process:<percent-escaped source code>`, but can't be forged in Rholang; instead, only the `@P` syntax is allowed. 

### API

[[ todo.  Express path expressions pick the most specific path.  Do all blockchain contracts get access to the URN resolver and rev, or just some? ]]

# 　

† All names are forgeable in the rho calculus, so at best it is a ["cryptocaps" platform](http://www.erights.org/elib/capability/dist-confine.html).  With behavioral types, one can restrict the kind of channels a process can receive, but once a process knows a name, it can leak that name as bits.  It is very hard to show that those bits won't be reassembled elsewhere in a process that can send on an arbitrary name.  On the blockchain, however, all names are not only forgeable, but *public*.  We no longer have even unguessability to rely on.

Rholang, therefore, includes the `new` keyword from π-calculus and requires the authors of contracts running on the blockchain to submit sourcecode.  Each node compiles the source independently, and then the nodes come to consensus on the result.  The code author is free to check that the compilation process matches the output produced by his own compiler.  Names generated by the `new` keyword are created in a private namespace of the form `urn:rholang:private:<uuid>`.  Such names are opaque to processes; they can be neither dereferenced nor forged, only passed around on other channels and compared for equality.  With unforgeable names, Rholang becomes a true ocaps platform.