4 files changed, 155 insertions, 2 deletions
diff --git a/doc/contributor/covenant.html b/doc/contributor/covenant.html
new file mode 100644
index 000000000..4facac24e
--- /dev/null
+++ b/doc/contributor/covenant.html
@@ -0,0 +1,106 @@
+<!DOCTYPE html>
+
+<html lang="en">
+<head>
+  <meta charset="utf-8"/>
+  <title>Contributor Covenant 1.4.0</title>
+  <style>
+    body {
+      font-family: monospace;
+      padding: 4em;
+    }
+    a {
+      color: #990000;
+    }
+  </style>
+  <link rel="alternate" hreflang="de" href="version/1/3/0/de/" />
+  <link rel="alternate" hreflang="es" href="version/1/4/es/" />
+  <link rel="alternate" hreflang="fr" href="version/1/3/0/fr/" />
+  <link rel="alternate" hreflang="hu" href="version/1/3/0/hu/" />
+  <link rel="alternate" hreflang="it" href="version/1/3/0/it/" />
+  <link rel="alternate" hreflang="ja" href="version/1/3/0/ja/" />
+  <link rel="alternate" hreflang="pl" href="version/1/4/pl/" />
+  <link rel="alternate" hreflang="pt" href="version/1/3/0/pt/" />
+  <link rel="alternate" hreflang="pt" href="version/1/3/0/pt_br/" />
+  <link rel="alternate" hreflang="ru" href="version/1/3/0/ru/" />
+  <link rel="alternate" hreflang="sl" href="version/1/4/sl/" />
+  <link rel="alternate" hreflang="uk" href="version/1/4/uk/" />
+</head>
+
+<body>
+
+<h1>Contributor Covenant Code of Conduct</h1>
+
+<h2>Our Pledge</h2>
+
+<p>In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.</p>
+
+<h2>Our Standards</h2>
+
+<p>Examples of behavior that contributes to creating a positive environment
+include:</p>
+
+<ul>
+  <li>Using welcoming and inclusive language</li>
+  <li>Being respectful of differing viewpoints and experiences</li>
+  <li>Gracefully accepting constructive criticism</li>
+  <li>Focusing on what is best for the community</li>
+  <li>Showing empathy towards other community members</li>
+</ul>
+
+<p>Examples of unacceptable behavior by participants include:</p>
+
+<ul>
+  <li>The use of sexualized language or imagery and unwelcome sexual attention or advances</li>
+  <li>Trolling, insulting/derogatory comments, and personal or political attacks</li>
+  <li>Public or private harassment</li>
+  <li>Publishing others' private information, such as a physical or electronic address, without explicit permission</li>
+  <li>Other conduct which could reasonably be considered inappropriate in a professional setting</li>
+</ul>
+
+<h2>Our Responsibilities</h2>
+
+<p>Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.</p>
+
+<p>Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.</p>
+
+<h2>Scope</h2>
+
+<p>This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.</p>
+
+<h2>Enforcement</h2>
+
+<p>Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at project&#x40;hubzilla.org. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.</p>
+
+<p>Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.</p>
+
+<h2>Attribution</h2>
+
+<p>This Code of Conduct is adapted from the <a href="http://contributor-covenant.org">Contributor Covenant</a>, version 1.4,
+available at <a href="http://contributor-covenant.org/version/1/4/">http://contributor-covenant.org/version/1/4</a>.</p>
+
+</body>
+</html>
diff --git a/doc/develop.bb b/doc/develop.bb
index ef3ea5bd0..7a7350049 100644
--- a/doc/develop.bb
+++ b/doc/develop.bb
@@ -27,5 +27,5 @@
 [zrl=[baseurl]/help/dev_beginner]Step-for-step manual for beginning developers[/zrl]
 
 [h3]External Resources[/h3]
-[url=https://zothub.com/channel/one]Development Channel[/url]
+[url=https://grid.reticu.li/channel/hubzilla]Development Channel[/url]
 [url=https://federated.social/channel/postgres]Postgres-specific $Projectname Admin Support Channel[/url]
diff --git a/doc/developers.bb b/doc/developers.bb
index 6f7752577..c7cf66093 100644
--- a/doc/developers.bb
+++ b/doc/developers.bb
@@ -1,6 +1,6 @@
 [b]$Projectname Developer Guide[/b]
 
-We're pretty relaxed when it comes to developers. We don't have a lot of rules. Some of us are over-worked and if you want to help we're happy to let you help. That said, attention to a few guidelines will make the process smoother and make it easier to work together. We have developers from across the globe with different abilities and different cultural backgrounds and different levels of patience. Our primary rule is to respect others. Sometimes this is hard and sometimes we have very different opinions of how things should work, but if everybody makes an effort, we'll get along just fine.  
+We're pretty relaxed when it comes to developers. We don't have a lot of rules. Some of us are over-worked and if you want to help we're happy to let you help. That said, attention to a few guidelines will make the process smoother and make it easier to work together. All developers are expected to abide by our [zrl=[baseurl]/help/contributor/covenant]code of conduct[/zrl]. We have developers from across the globe with different abilities and different cultural backgrounds and different levels of patience. Our primary rule is to respect others. Sometimes this is hard and sometimes we have very different opinions of how things should work, but if everybody makes an effort, we'll get along just fine. 
 
 [b]Here is how you can join us.[/b]
 
diff --git a/doc/feature/access_tokens.bb b/doc/feature/access_tokens.bb
new file mode 100644
index 000000000..eb5c03717
--- /dev/null
+++ b/doc/feature/access_tokens.bb
@@ -0,0 +1,47 @@
+Feature: Zot Access Tokens
+Status: Draft
+Date: 15 July 2016
+
+
+Purpose:
+
+In order to facilitate sharing of private resources with non-members or members of federation nodes with limited identification discovery, Hubzilla should provide members with a mechanism to create and manage temporary ("throwaway") logins, aka "Zot Access Tokens". These tokens/credentials may be used to authenticate to a hubzilla site for the sole purpose of accessing privileged or access controlled resources (files, photos, posts, webpages, chatrooms, etc.). 
+
+
+Scope: 
+
+Zot Access Tokens do not convey membership in the site or network. In particular, they do not provide an account or channel; which may be necessary to interact with the hub owner or with others in the network or federation of networks. In most cases they can only be used to consume restricted resources and do not have an ability to create those resources, however this ability may be provided by custom configurations or in future releases or addons. 
+
+For instance the ability for a temporary login to access a chatroom may provide suitable permission to create chat messages inside that chatroom.
+
+
+Implementation:
+
+Zot Access Tokens are managed through a "tab" of the settings page. Access to this tab may be controlled by site configuration. On this page, channels may create, edit, list, and remove any access tokens under their control. 
+
+The form to create/edit accepts three parameters, a human readable name, a password or access token, and an optional expiration. Once expired, the access token is no longer valid, may no longer be used, and will be automatically purged from the list of temporary accounts. The password field in the create/edit forms displays the text of the access token and not an obscured password. By default we will create a token using the autoname() function, which generally produces a random character sequence which is "pronounceable", hence easy to convey or remember. This can be changed to any other character sequence which is acceptable to the site password complexity policy. (In most Hubzilla installations this imposes a minimum of three characters, but may be extended by plugin or site policy).
+
+
+Usage:
+
+We do not specify mechanisms for sharing these tokens with others. Any communication method may be used. Any tokens you have created are added to the Access Control List selector and may be used anywhere that Access Control Lists are provided.
+
+	Example: A visitor arrives at your site. She has an access token you have provided, and attempts to visit one of your photo albums (which is restricted to be viewed only by yourself and one temporary identity). Permission is denied.
+
+The visitor now selects "Login" from the menu navigation bar. This presents a login page. She enters the name and password you have provided her, and she can now view the restricted photo album.
+
+
+Alternatively, you may share a link to a protected file by adding a parameter "&zat=abc123" to the URL, where the string "abc123" is the access token or password for the temporary login. No further negotiation is required, and the file is presented. 
+
+Zot Acess Tokens are represented internally as an authenticated "observer". Querying the observer in code should return a pseudo or system generated xchan with an unknown protocol and a default profile photo. It will match (successfully) any access control rule which allows authenticated observers. 
+
+Security Considerations:
+
+The URL form of authentication is inherently less secure than using a login, but may be preferable for some uses of this feature. It probably should not be transmitted over non-SSL links. 
+
+
+Future development:
+
+It might be desirable for future implementations to provide an options for single-use, where the access token is removed promptly following first use.   
+   
+ 
+\ No newline at end of file