Skip to content
This repository has been archived by the owner on Feb 18, 2021. It is now read-only.

Commit

Permalink
text tweaks
Browse files Browse the repository at this point in the history
  • Loading branch information
stpeter committed Apr 7, 2015
1 parent 8d44034 commit e716d81
Show file tree
Hide file tree
Showing 4 changed files with 8 additions and 8 deletions.
2 changes: 1 addition & 1 deletion v3/base32.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,5 +4,5 @@ All base 32 encoding used in this document is defined by [RFC 4648](http://tools

It is used frequently to encode binary 32 byte [SHA-256](http://en.wikipedia.org/wiki/SHA-2) digests safely for use in JSON and URIs, resulting in a 52 character string, for example: `kw3akwcypoedvfdquuppofpujbu7rplhj3vjvmvbkvf7z3do7kkq`. It is sometimes also used to encode public key material, small JSON objects, and in implementations to print binary values for debugging.

Base 32 encoding was chosen to maximize compatibilty and consistency, such that it is usable in any part of a URI, as DNS labels, and is case insensitive and alphanumeric only. It's only used for small fixed values where interchanging the data safely is more important than efficency, it is never used to encode dynamic application data over a transport.
Base 32 encoding was chosen to maximize compatibilty and consistency, such that it is usable in any part of a URI and as DNS labels, and is case insensitive and alphanumeric only. It's only used for small fixed values where interchanging the data safely is more important than efficency, and is never used to encode dynamic application data over a transport.

4 changes: 2 additions & 2 deletions v3/hashname.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
# Hashnames

A _hashname_ is a unique fingerprint to represent the union of one or more public keys of different formats ([Cipher Sets](e3x/cs/)), providing consistent verifiable endpoint addresses when utilizing multiple different Public-key algorithms. This enables a compatibility layer for improving the algorithms used so that any application can increase security in newer versions while still being able to represent itself securely to older ones.
A _hashname_ is a unique fingerprint to represent the union of one or more public keys of different formats ([Cipher Sets](e3x/cs/)), providing consistent verifiable endpoint addresses when utilizing multiple different public-key algorithms. This enables a compatibility layer for improving the algorithms used so that any application can increase security in newer versions while still being able to represent itself securely to older ones.

A _hashname_ can be viewed as a portable secure [MAC address](http://en.wikipedia.org/wiki/MAC_address), it is a universally unique identifier for a network endpoint that is also self-generated and cryptographically verifiable.
A _hashname_ can be viewed as a portable, secure, virtual equivalent of a [MAC address](http://en.wikipedia.org/wiki/MAC_address), since it is a universally unique identifier for a network endpoint that is also self-generated and cryptographically verifiable.

The value is always a [base 32](base32.md) encoded string that is 52 characters long. When decoded it is always a 32 byte binary value, which corresponds to the result of a [SHA-256](http://en.wikipedia.org/wiki/SHA-2) hash digest. An example _hashname_ is `kw3akwcypoedvfdquuppofpujbu7rplhj3vjvmvbkvf7z3do7kkq`.

Expand Down
4 changes: 2 additions & 2 deletions v3/link.md
Original file line number Diff line number Diff line change
Expand Up @@ -108,11 +108,11 @@ The `"csid":"2a"` is optional when sent as an encrypted message, but required wh
<a name="jwt" />
## Identity (JWT)

The endpoints connected over a link are always uniquely identified by their hashnames which serve as a stable universally unique and verifiable address, but is not intended to be used as a higher level identity for an end-user or other entity beyond the single instance/device. Once a hashname is generated in a new context, it should be registered and associated with other portable identities by the application.
The endpoints connected over a link are always uniquely identified by their hashnames. A hashname serves as stable, universally unique, verifiable address, but is not intended to be used as a higher-level identity for an end user or other entity beyond the single instance/device. Once a hashname is generated in a new context, it should be registered and associated with other portable identities by the application.

[OpenID Connect](http://openid.net/connect/) or any service that is able to generate a [JSON Web Token](http://tools.ietf.org/html/draft-ietf-oauth-json-web-token) can be used for primary user/entity identification, enabling strongly encrypted communication to be easily coupled with standard identity management tools.

Just as a JWT is sent as a Bearer token over HTTP, it can be automatically included as part of the [handshake process](e3x/handshake.md) between endpoints with a `"type":"jwt"`. This enables applications to require additional context before deciding to establish a link or apply restrictions on to what can be performed over the link once connected.
Just as a JWT is sent as a Bearer token over HTTP, it can be automatically included as part of the [handshake process](e3x/handshake.md) between endpoints with a `"type":"jwt"`. This enables applications to require additional context before deciding to establish a link or apply restrictions on what can be performed over the link once it is established.

### Audience

Expand Down
6 changes: 3 additions & 3 deletions v3/mesh.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,9 +3,9 @@ Mesh Network

A mesh network consists of one or more [links](link.md), which are active [encrypted sessions](e3x/) between two endpoints over any [transport](transports/) established by exchanging [handshakes](e3x/handshake.md).

Each link is identified with a unique [hashname](hashname.md). A mesh is private to each endpoint, which has complete control over what links it accepts, there is no automatic sharing of any link state to any other endpoint.
Each link is identified with a unique [hashname](hashname.md). A mesh is private to each endpoint, which has complete control over what links it accepts (there is no automatic sharing of any link state to any other endpoint).

Once handshakes are verified and a link is up then [channels](channels/) are used to send data over it between endpoints.
Once handshakes are verified and a link is up, [channels](channels/) are used to send data over the link between endpoints.

Any link may be set as a [router](routing.md) when it is known that it will provide relaying/bridging to other links. Any endpoint may advertise its [router](routing.md) as a path to other endpoints that may not have the same router. An endpoint may also use a base [URI](uri.md) from a [router](routing.md) as an out-of-band mechanism to establish new links.

Expand All @@ -14,7 +14,7 @@ Any link may be set as a [router](routing.md) when it is known that it will prov

By default a local endpoint will never respond to any request unless it comes from a link it already knows and trusts. Implementations should support a `discover` mode that can be enabled to temporarily change this behavior and broadcast the endpoint's hashname and keys to any local [network transport](transports/) that supports discovery.

This mode should be used sparingly so that local networks cannot record what endpoints are available, typically only enabled based on a user behavior ("add a friend" or "pair device", etc) and only for a short period of time. Permanent local well-known services/servers that support dynamic association may have it always enabled.
This mode should be used sparingly so that local networks cannot record what endpoints are available. Typically this is enabled only based on a user behavior ("add a friend" or "pair device", etc) and only for a short period of time. Permanent, local, well-known services/servers that support dynamic association may have it always enabled.

All transports that support discovery should always be listening for incoming `discover` announcements regardless of the discovery state and pass those to the application to evaluate. Discovery does not need to be enabled to receive announcements and see other endpoints, only to announce the local endpoint.

0 comments on commit e716d81

Please sign in to comment.