Merge pull request #676 from anaqreon/doco

Doco

27 files changed, 388 insertions, 999 deletions

diff --git a/doc/Privacy.md b/doc/Privacy.md
deleted file mode 100644
index 1ac019f5a..000000000
--- a/doc/Privacy.md
+++ /dev/null
@@ -1,77 +0,0 @@
-Privacy Policy
-==============
-
-
-##Summary##
-
-
-Q: Who can see my content?
- 
-A: By default ANYBODY on the internet, UNLESS you restrict it. $Projectname allows you to choose the privacy level you desire. Restricted content will NOT be visible to "spy networks" and advertisers. It will be protected against eavesdropping by outsiders - to the best of our ability. Hub administrators with sufficient skills and patience MAY be able to eavesdrop on some private communications but they must expend effort to do so. Privacy modes exist within $Projectname which are even resistant to eavesdropping by skilled and determined hub administrators.    
-
-Q: Can my content be censored?
-
-A: $Projectname (the network) CANNOT censor your content. Server and hub administrators are subject to local laws and MAY remove objectionable content from their site/hub. Anybody MAY become a hub administrator, including you; and therefore publish content which might otherwise be censored. You still MAY be subject to local laws.   
-
-
-##Definitions
-
-**$Projectname** 
-
-Otherwise referred to as "the network", $Projectname is a collection of individual computers/servers (aka **hubs**) which connect together to form a larger cooperative network. 
-
-**hub** 
-
-An individual computer or server connected to $Projectname. These are provided by a **hub administrator** and may be public or private, paid or free.
-
-**hub administrator**
-
-The system operator of an individual hub. 
-
-##Policies
-
-**Public Information**
-
-Any information or anything posted by you within $Projectname MAY be public or visible to anybody on the internet. To the extent possible, $Projectname allows you to protect content and restrict who can view it.
-
-Your profile photo, your channel name, and the location (URL or network address) of your channel are visible to anybody on the internet and privacy controls will not affect the display of these items. 
-
-You MAY additionally provide other profile information. Any information which you provide in your "default" or **public profile** MAY be transmitted to other hubs in $Projectname and additionally MAY be displayed in the channel directory. You can restrict the viewing of this profile information. It may be restricted only to members of your hub, or only connections (friends), or other limited sets of viewers as you desire. If you wish for your profile to be restricted, you must set the appropriate privacy setting, or simply DO NOT provide additional information. 
-
-**Content**
-
-Content you provide (status posts, photos, files, etc.) belongs to you. $Projectname default is to publish content openly and visible to anybody on the internet (PUBLIC). You MAY control this in your channel settings and restrict the default permissions or you MAY restrict the visibility of any single published item separately (PRIVATE). $Projectname developers will ensure that restricted content is ONLY visible to those in the restriction list - to the best of their ability. 
-
-Content (especially status posts) that you share with other networks or that you have made visible to anybody on the internet (PUBLIC) cannot easily be taken back once it has been published. It MAY be shared with other networks and made available through RSS/Atom feeds. It may also be syndicated on other $Projectname sites. It MAY appear on other networks and websites and be visible in internet searches. If you do not wish this default behaviour please adjust your channel settings and restrict who can see your content. 
-
-**Comments and Forum posts**
-
-Comments to posts that were created by others and posts which are designated as forum posts belong to you as the creator/author, but the distribution of these posts is not under your direct control, and you relinquish SOME rights to these items. These posts/comments MAY be re-distributed to others, and MAY be visible to anybody on the internet. In the case of comments, the creator of the "first message" in the thread (conversation) to which you are replying controls the distribution of all comments and replies to that message. They "own" and therefore have certain rights with regard to the entire conversation (including all comments contained within it). You can still edit or delete the comment, but the conversation owner also has rights to edit, delete, re-distribute, and backup/restore any or all the content from the conversation. 
-
-**Private Information**
-
-$Projectname developers will ensure that any content you provide which is designated as PRIVATE will be protected against eavesdropping - to the best of their ability. Private channel content CAN be seen in the database of every involved hub administrator, but private messages are obscured in the database. The latter means that it is very difficult, but NOT impossible for this content to be seen by a hub administrator. Private channel content and private messages are also stripped from email notifications. End to end encryption is provided as an optional feature and this CANNOT be seen, even by a determined administrator.  
-
-##Identity Privacy
-
-Privacy for your identity is another aspect. Because you have a decentralized identity in $Projectname, your privacy extends beyond your home hub. If you want to have complete control of your privacy and security you should run your own hub on a dedicated server. For many people, this is complicated and may stretch their technical abilities. So let's list a few precautions you can make to assure your privacy as much as possible.
-
-A decentralized identity has a lot of advantages and gives you al lot of interesting features, but you should be aware of the fact that your identity is known by other hubs in $Projectname network. One of those advantages is that other channels can serve you customized content and allow you to see private things (such as private photos which others wish to share with you). Because of this those channels need to know who you are. But we understand that sometimes those other channels know more from you than you might desire. For instance the plug-in Visage that can tell a channel owner the last time you visit their profile. You can easily OPT-OUT of this low level and we think, harmless tracking.
-
-* You can enable [Do Not Track (DNT)](http://donottrack.us/) in your web browser. We respect this new privacy policy proposal. All modern browsers support DNT. You will find it in the privacy settings of your browsers or else you can consult the web browser's manual. This will not affect the functionality of $Projectname. This setting is probably enough for most people.
-
-*You can [disable publication](settings) of your channel in our channel directory. If you want people to find your channel, you should give your channel address directly to them. We think this is a good indication that you prefer extra privacy and automatically enable "Do Not Track" if this is the case.
-
-* You can have a blocked hub. That means that all channels and content on that hub is not public, and not visible to the outside world. This is something only your hub administrator can do. We also respect this and automatically enable "Do Not Track" if it is set.
-
-###Censorship
-
-$Projectname is a global network which is inclusive of all religions and cultures. This does not imply that every member of the network feels the same way you do on contentious issues, and some people may be STRONGLY opposed to the content you post. In general, if you wish to post something that you know may nor be universally acceptable, the best approach is to restrict the audience using privacy controls to a small circle of friends. 
-
-$Projectname as a network provider is unable to censor content. However, hub administrators MAY censor any content which appears on their hub to comply with local laws or even personal judgement. Their decision is final. If you have issues with any hub administrator, you may move your account and postings to another site which is more in line with your expectations. Please check (periodically) the [Terms of Service](help/TermsOfService) of your hub to learn about any rules or guidelines. If your content consists of material which is illegal or may cause issues, you are STRONGLY encouraged to host your own (become a hub administrator). You may still find that your content is blocked on some hubs, but $Projectname as a network cannot block it from being posted.
-
-$Projectname RECOMMENDS that hub administrators provide a grace period of 1-2 days between warning an account holder of content that needs to be removed and physically removing or disabling the account. This will give the content owner an opportunity to export their channel meta-data and import it to another site. In rare cases the content may be of such a nature to justify the immediate termination of the account. This is a hub decision, not a $Projectname decision. 
-
-If you typically and regularly post content of an adult or offensive nature, you are STRONGLY encouraged to mark your account "NSFW" (Not Safe For Work). This will prevent the display of your profile photo in the directory except to viewers that have chosen to disable "safe mode". If your profile photo is found by directory administrators to be adult or offensive, the directory administrator MAY flag your profile photo as NSFW. There is currently no official mechanism to contest or reverse this decision, which is why you SHOULD mark your own account NSFW if it is likely to be inappropriate for general audiences. 
-
-#include doc/macros/main_footer.bb;
diff --git a/doc/about.bb b/doc/about.bb
deleted file mode 100644
index 1ec1cf28e..000000000
--- a/doc/about.bb
+++ /dev/null
@@ -1,24 +0,0 @@
-[b]About[/b]

-

-$Projectname is a decentralized communication network, which aims to provide communication that is censorship-resistant, privacy-respecting, and thus free from the oppressive claws of contemporary corporate communication giants. These giants function primarily as spy networks for paying clients of all sorts and types, in addition to monopolizing and centralizing the Internet; a feature that was not part of the original and revolutionary goals that produced the World Wide Web. 

-

-$Projectname is free and open source.  It is designed to scale from a $35 Raspberry Pi, to top of the line AMD and Intel Xeon-powered multi-core enterprise servers.  It can be used to support communication between a few individuals, or scale to many thousands and more.

-

-$Projectname aims to be skill and resource agnostic. It is easy to use by everyday computer users, as well as by systems administrators and developers. 

-

-How you use it depends on how you want to use it. 

-

-It is written in the PHP scripting language, thus making it trivial to install on any hosting platform in use today. This includes self-hosting at home, at hosting providers such as [url=http://mediatemple.com/]Media Temple[/url] and [url=http://www.dreamhost.com/]Dreamhost[/url], or on virtual and dedicated servers, offered by the likes of [url=https://www.linode.com]Linode[/url],  [url=http://greenqloud.com]GreenQloud[/url] or [url=https://aws.amazon.com]Amazon AWS[/url].

-

-In other words, $Projectname can run on any computing platform that comes with a web server, a MySQL-compatible database, and the PHP scripting language. 

-

-Along the way, $Projectname offers a number of unique goodies: 

-

-[b]Single-click user identification:[/b] meaning you can access sites on $Projectname simply by clicking on links to remote sites. Authentication just happens automagically behind the scenes. Forget about remembering multiple user names with multiple passwords when accessing different sites online.

-

-[b]Cloning:[/b] of online identities. Your online presence no longer has to be tied to a single server, domain name or IP address.  You can clone and import your identity (or channel as we call it) to another server (or, a hub as servers are known in $Projectname).  Now, should your primary hub go down, no worries, your contacts, posts[i]*[/i], and messages[i]*[/i] will automagically continue to be available and accessible under your cloned channel. [i](*: only posts and messages as from the moment you cloned your channel)[/i]

-

-[b]Privacy:[/b] $Projectname identities (Zot IDs) can be deleted, backed up/downloaded, and cloned.  The user is in full control of their data. Should you decide to delete all your content and erase your Zot ID, all you have to do is click on a link and it's immediately deleted from the hub.  No questions, no fuss. 

-

-#include doc/macros/main_footer.bb;

-

diff --git a/doc/account_basics.bb b/doc/account_basics.bb
deleted file mode 100644
index 664949d6e..000000000
--- a/doc/account_basics.bb
+++ /dev/null
@@ -1,38 +0,0 @@
-[b]Account Basics[/b]

-

-[b]Registration[/b]

-

-Not all $Projectname sites allow open registration. If registration is allowed, you will see a "Register" link immediately below the login prompts on the site home page. Following this link will take you to the site Registration page. On some sites it may redirect you to another site which allow registrations. As all $Projectname sites are linked, it does not matter where your account resides.

-

-[b]Your Email Address[/b]

-

-Please provide a valid email address. Your email address is never published. This address will be used to (optionally) send email notifications for incoming messages or items, and used to recover lost passwords.

-

-[b]Password[/b]

-

-Enter a password of your choice, and repeat it in the second box to ensure it was typed correctly. As $Projectname offers a decentralised identity, your account can log you in to many other websites.

-

-[b]Terms Of Service[/b]

-

-Click the link to read the site's terms of service. Once you've read them, tick the box in the register form to confirm.

-

-[b]Register[/b]

-

-Once you have provided the necessary details, click the 'Register' button. Some sites may require administrator approval before the registration is processed, and you will be alerted if this is the case. Please watch your email (including spam folders) for your registration approval.

-

-[b]Create a Channel[/b]

-

-Next, you will be presented with the "Add a channel" screen. Normally, your first channel will be one that represents you - so using your own name (or psuedonym) as the channel name is a good idea. The channel name should be thought of as a title, or brief description of your channel. The "choose a short nickname" box is similar to a "username" field. We will use whatever you enter here to create a channel address, which other people will use to connect to you, and you will use to log in to other sites. This looks like an email address, and takes the form nickname@siteyouregisteredat.xyz*

-

-When your channel is created you will be taken straight to your settings page where you can define permissions, enable features, etc. All these things are covered in the appropriate section of the helpfiles.

-

-*Note: It is not possible to change this address after creating the channel.

-

-See Also

-

-[zrl=[baseurl]/help/permissions]Permissions[/zrl]

-[zrl=[baseurl]/help/privacy]Privacy[/zrl]

-[zrl=[baseurl]/help/profiles]Profiles[/zrl]

-[zrl=[baseurl]/help/remove_account]Remove Account[/zrl]

-

-#include doc/macros/main_footer.bb;

diff --git a/doc/accounts.bb b/doc/accounts.bb
deleted file mode 100644
index 7c0378504..000000000
--- a/doc/accounts.bb
+++ /dev/null
@@ -1,4 +0,0 @@
-This one still needs to be written.
-
-#include doc/macros/main_footer.bb;
-
diff --git a/doc/admin/administrator_guide.md b/doc/admin/administrator_guide.md
index f21c55327..c233d8564 100644
--- a/doc/admin/administrator_guide.md
+++ b/doc/admin/administrator_guide.md
@@ -196,6 +196,70 @@ The installation script was originally designed for a small hardware server behi
 1. `service apache2 reload`
 1. Open your domain with a browser and step throught the initial configuration of $Projectname.
 
+### Server Roles
+
+$Projectname can be configured in many different ways. One of the configurations available at installation is to select a 'server role'. There are currently three server roles. We highly recommend that you use 'standard' unless you have special needs. 
+
+
+#### Basic
+
+The 'basic' server role is designed to be relatively simple, and it doesn't present options 
+or complicated features. The hub admin may configure additional features at a site level. 
+This role is designed for simple social networking and social network federation. Many features 
+which do not federate easily have been removed, including (and this is somewhat important) 
+"nomadic identity". You may move a channel to or from a basic server, but you may not clone 
+it. Once moved, it becomes read-only on the origination site. No updates of any kind will be 
+provided. It is recommended that after the move, the original channel be deleted - as it is 
+no longer useable. The data remains only in case there are issues making a copy of the data. 
+
+This role is supported by the hubzilla community.
+
+#### Standard
+
+
+The 'standard' server role is recommended for most sites. All features of the software are 
+available to everybody unless locked by the hub administrator. Some features will not federate 
+easily with other networks, so there is often an increased support burden explaining why 
+sharing events with Diaspora (for instance) presents a different experience on that network. 
+Additionally any member can enable "advanced" or "expert" features, and these may be beyond 
+their technical skill level. This may also result in an increased support burden.
+
+This role is supported by the hubzilla community.
+
+#### Pro
+
+The 'pro' server role is primarily designed for communities which want to present a uniform 
+experience and be relieved of many federation support issues. In this role there is 
+**no federation with other networks**. Additional features **may** be provided, such 
+as channel ratings, premium channels, and e-commerce. 
+
+By default a channel may set a "techlevel" appropriate to their technical skill. Higher 
+levels provide more features. Everybody starts with techlevel 0 (similar to the 'basic' 
+role) where all complicated features are hidden from view. Increasing the techlevel provides 
+more advanced or complex features.
+
+The hub admin may also lock individual channels or their entire site at a defined techlevel 
+which provides an installation with a selection of advanced features consistent with the 
+perceived technical skills of the members. For instance, a community for horse racing might 
+have a different techlevel than a community for Linux kernel developers. 
+
+This role is not supported by the hubzilla community. 
+
+### Techlevels
+
+Techlevels is a unique feature of Hubzilla 'pro'. It is not available in other server_roles, although it expands on the concepts introduced in $Projectname 'basic'.
+
+We've implemented several different mechanisms in order to reduce the apparent complexity and learning curve presented to new members. At the same time, we do not wish to limit any functionality for people who are able to grasp some slightly advanced technical technical features. The first mechanism was to move several features to an optional 'Features' page where they could be enabled at will; with the default interface kept somewhat lean. 
+
+The problem we had now is that the number of features began to grow dramatically, and the Feature page is daunting in possibilities. There are also features present which probably should not be available to all members, but may be extremely useful to those with technical backgrounds.
+
+The techlevels seeeks to remedy this by grouping features within different levels of technical ability; starting at 0 (uncomfortable with technology), and up to 5 (Unix wizard or equivalent).
+
+When a new member registers, their account is provided a techlevel setting of 0. On the account settings page they may change this to any available level. A higher level opens more advanced features and possible interactions.
+
+The account administrator may also lock a particular level, lock a maximum level, or change/re-arrange the features available to any level. Those with the minimum level are typically not very exploratory and are unlikely to discover the advanced modes. This is by design. Those that look around and desire more interactions will find them. In the absence of administrator defaults they may choose any level. As they look at the features available to the level in question, it is generally expected that they will discover some features are beyond their comprehension and it is hoped they will back off to a level where the interface and features are comfortable to their skill level. This is somewhat experimental at present and for that reason is not part of the 'standard' server role. The standard server role is preset to level '5', and the basic server role is preset to level '0', with no possibility of change. Members in these roles may find themselves overwhelmed or underwhelmed by the feature set and complexity.        
+
+
 ### Service Classes
 
 Service classes allow you to set limits on system resources by limiting what individual
diff --git a/doc/contributor/covenant.html b/doc/contributor/covenant.html
deleted file mode 100644
index 4facac24e..000000000
--- a/doc/contributor/covenant.html
+++ /dev/null
@@ -1,106 +0,0 @@
-<!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/database.bb b/doc/database.bb
index 02a70e2c7..160ec505e 100644
--- a/doc/database.bb
+++ b/doc/database.bb
@@ -1,6 +1,4 @@
-[h2]Database Tables[/h2]
-[table]
-[tr][th]Table[/th][th]Description[/th][/tr]
+[h2]Database Tables[/h2][table border=1][tr][th]Table[/th][th]Description[/th][/tr]
 [tr][td][zrl=[baseurl]/help/database/db_abconfig]abconfig[/zrl][/td][td]arbitrary storage for connections of local channels[/td][/tr]
 [tr][td][zrl=[baseurl]/help/database/db_abook]abook[/zrl][/td][td]connections of local channels[/td][/tr]
 [tr][td][zrl=[baseurl]/help/database/db_account]account[/zrl][/td][td]service provider account[/td][/tr]
diff --git a/doc/developer/api_zot.bb b/doc/developer/api_zot.bb
index f33faed17..1314f90b5 100644
--- a/doc/developer/api_zot.bb
+++ b/doc/developer/api_zot.bb
@@ -286,7 +286,7 @@ list photo metadata
 [h3]group[/h3]
 
 
-`GET /api/z/1.0/group`
+[code]GET /api/z/1.0/group[/code]
 
 Description: list privacy groups
 
@@ -326,7 +326,7 @@ To use with API group_members, provide either 'group_id' from the id element ret
 [h3]group_members[/h3]
 
 
-`GET /api/z/1.0/group_members`
+[code]GET /api/z/1.0/group_members[/code]
 
 Required:
 
@@ -462,7 +462,7 @@ group_member+abook+xchan (DB join) for each member of the privacy group
 An xchan is a global location independent channel and is the primary record for a network 
 identity. It may refer to channels on other websites, networks, or services. 
 
-`GET /api/z/1.0/xchan`
+[code]GET /api/z/1.0/xchan[/code]
 
 Required: one of [ address, hash, guid ] as GET parameters
 
@@ -506,7 +506,7 @@ Returns:
 
 Create or update an item (post, activity, webpage, etc.)
 
-Usage: `POST /api/z/1.0/item/update`
+Usage: [code]POST /api/z/1.0/item/update[/code]
 
 Description: item/update posts an item (typically a conversation item or post, but can be any item) using form input.  
 
diff --git a/doc/developer/covenant.bb b/doc/developer/covenant.bb
new file mode 100644
index 000000000..431cc74e9
--- /dev/null
+++ b/doc/developer/covenant.bb
@@ -0,0 +1,47 @@
+[size=large]Contributor Covenant Code of Conduct[/size]
+
+[h3]Our Pledge[/h3]
+
+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.
+
+[h3]Our Standards[/h3]
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+[list]
+  [*]Using welcoming and inclusive language
+  [*]Being respectful of differing viewpoints and experiences
+  [*]Gracefully accepting constructive criticism
+  [*]Focusing on what is best for the community
+  [*]Showing empathy towards other community members
+[/list]
+
+Examples of unacceptable behavior by participants include:
+
+[list]
+  [*]The use of sexualized language or imagery and unwelcome sexual attention or advances
+  [*]Trolling, insulting/derogatory comments, and personal or political attacks
+  [*]Public or private harassment
+  [*]Publishing others' private information, such as a physical or electronic address, without explicit permission
+  [*]Other conduct which could reasonably be considered inappropriate in a professional setting
+[/list]
+
+[h3]Our Responsibilities[/h3]
+
+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.  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.
+
+[h3]Scope[/h3]
+
+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.
+
+[h3]Enforcement[/h3]
+
+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.
+
+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.
+
+[h3]Attribution[/h3]
+
+This Code of Conduct is adapted from the [url=http://contributor-covenant.org]Contributor Covenant[/url], version 1.4, available at [url=http://contributor-covenant.org/version/1/4/]http://contributor-covenant.org/version/1/4[/url].
+
diff --git a/doc/developer/developer_guide.bb b/doc/developer/developer_guide.bb
new file mode 100644
index 000000000..f8ba0c1d8
--- /dev/null
+++ b/doc/developer/developer_guide.bb
@@ -0,0 +1,178 @@
+[h3]Who is a $Projectname developer? Should I read this?[/h3]
+
+Anyone who contributes to making $Projectname better is a developer. There are many different and important ways you can contribute to this amazing technology, [i]even if you do not know how to write code[/i]. The software itself is only a part of the $Projectname project. You can contribute by 
+[list]
+[*] translating text to your language so that people around the world have the opportunity to use $Projectname
+[*] promoting $Projectname and spreading awareness of the platform through blog posts, articles, and word-of-mouth
+[*] creating artwork and graphics for project assets such as icons and marketing material
+[*] supporting project infrastructure like the project website and demo servers
+[/list]
+[i]Software[/i] developers are of course welcomed; there are so many great ideas to implement and not enough people to make them all a reality! The $Projectname code base is an advanced and mature system, but the platform is still very flexible and responsive to new ideas. 
+
+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/developer/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. 
+
+This document will help you get started learning and contributing to $Projectname.
+
+[h3]Versions and Releases[/h3]
+
+$Projectname currently uses a standard version numbering sequence of $x.$y(.$z), for instance '1.12' or '1.12.1'. The first digit is the major version number. Major versions are released "roughly" once per year; often in December.
+
+The second digit is the minor release number. If this number is odd, it is a development version. If the number is even, it is a released version. Minor versions are released (moved from dev to master) typically once per month when development is 'stable', but this is likely to increase. Going forward minor releases will be made somewhere between one and three months; corresponding to a stable code point and when there is general community consensus that the current code base is stable enough to consider a release.
+
+The final digit is an interface or patch designator. 
+
+The release process involves changing the version number (by definition the minor version number will be odd, and the minor number will be incremented). Once a year for a major release the major version will be incremented, and the minor number reset to 0. 
+
+The release candidate is moved to a new branch; and testing will commence/continue for a period of 1-2 weeks afterward or until any significant issues have been resolved. This branch is usually labelled with RC (release candidate); for instance 1.8RC represents the pending release of version 1.8. At this time, the minor version number on the dev branch is incremented to the next odd number. (For instance 1.9). New development can then take place in the dev branch. 
+
+Bug fixes should always be applied to 'dev' and from there merged forward (typically with git cherry-pick) to the RC branch and if necessary applied to the master or official release branch.
+
+At the time a release candidate is produced, the language strings file is frozen until a release is made. Translation work may continue, but all translations should be submitted to 'dev' and merged forward to RC.
+
+Once RC testing is completed, RC is merged to 'master' and the RC version designator removed; resulting in one final checkin to change the version number. The CHANGELOG file should also be updated at or just prior to this time. If there are merge conflicts during this final merge, the merge will be abandoned; and 'git merge -s ours' applied. This results in a replacement of master with the contents of the RC branch. Conflicts often arise with string updates which were made to master after the last release and cannot easily be resolved without hand editing. Since this is a release of tested code, hand editing is discouraged, and the replacement merge strategy should be used instead. It is assumed that RC now contains the most recent well-tested code. 
+
+Once the release is live and merged to master, the RC branch may be removed. 
+
+Fixes may be made to master after release. Where possible these should be made to dev and 'git cherry-pick' used to merge forward; which preserves the commit info and prevents merge conflicts in the next cycle. Only rarely does a patch only apply to the master branch. If necessary this can be made. If the change is severe, the interface version number should be incremented. This is at the discretion of the community. In any event, a 'git pull' of the master branch should always result in the latest release with any post-release patches applied. 
+
+The interface number (the $z in $x.$y.$z) should be incremented in dev whenever a change is made which changes the interfaces or API in incompatible ways so that any external packages (especially addons and API clients) relying on a the current behaviour can discover and change their own interfaces accordingly at the point that it changed.  
+
+[h3]Git repository branches[/h3]
+
+There are two official branches of the $Projectname git repo. 
+[list]
+[*] The stable version is maintained on the [b]master[/b] branch. The latest commit in this branch is considered to be suitable for production hubs. 
+[*] Experimental development occurs on the [b]dev[/b] branch, which is merged into [b]master[/b] when it is deemed tested and stable enough.
+[/list]
+
+[h3]Developer tools and workflows[/h3]
+
+[h4]Hub Snapshots[/h4]
+
+The [url=[baseurl]/help/admin/hub_snapshots]hub snapshots[/url] page provides instructions and scripts for taking complete snapshots of a hub to support switching between consistent and completely known states. This is useful to prevent situations where the content or database schema might be incompatible with the code. 
+
+[h3]Translations[/h3]
+
+Our translations are managed through Transifex. If you wish to help out translating $Projectname to another language, sign up on transifex.com, visit [url=https://www.transifex.com/Friendica/red-matrix/]Transifex[/url] and request to join one of the existing language teams or create a new one. Notify one of the core developers when you have a translation update which requires merging, or ask about merging it yourself if you're comfortable with git and PHP. We have a string file called 'messages.po' which is gettext compliant and a handful of email templates, and from there we automatically generate the application's language files.   
+
+[h4]Translation Process[/h4]
+
+The strings used in the UI of $Projectname is translated at [url=https://www.transifex.com/Friendica/red-matrix/]Transifex[/url] and then
+included in the git repository at github. If you want to help with translation
+for any language, be it correcting terms or translating $Projectname to a
+currently not supported language, please register an account at transifex.com
+and contact the Redmatrix translation team there.
+
+Translating $Projectname is simple. Just use the online tool at transifex. If you
+don't want to deal with git & co. that is fine, we check the status of the[/td][/tr]
+[tr]ranslations regularly and import them into the source tree at github so that
+others can use them.
+
+We do not include every translation from transifex in the source tree to avoid
+a scattered and disturbed overall experience. As an uneducated guess we have a
+lower limit of 50% translated strings before we include the language. This
+limit is judging only by the amount of translated strings under the assumption[/td][/tr]
+[tr]hat the most prominent strings for the UI will be translated first by a[/td][/tr]
+[tr]ranslation team. If you feel your translation useable before this limit,
+please contact us and we will probably include your teams work in the source[/td][/tr]
+[tr]ree.
+
+If you want to get your work into the source tree yourself, feel free to do so
+and contact us with and question that arises. The process is simple and
+$Projectname ships with all the tools necessary.
+
+The location of the translated files in the source tree is
+    /view/LNG-CODE/
+where LNG-CODE is the language code used, e.g. de for German or fr for French.
+For the email templates (the *.tpl files) just place them into the directory
+and you are done. The translated strings come as a "hmessages.po" file from[/td][/tr]
+[tr]ransifex which needs to be translated into the PHP file $Projectname uses.  To do
+so, place the file in the directory mentioned above and use the "po2php"
+utility from the util directory of your $Projectname installation.
+
+Assuming you want to convert the German localization which is placed in
+view/de/hmessages.po you would do the following.
+
+1. Navigate at the command prompt to the base directory of your
+   $Projectname installation
+
+2. Execute the po2php script, which will place the translation
+   in the hstrings.php file that is used by $Projectname.
+
+       $> php util/po2php.php view/de/hmessages.po
+
+   The output of the script will be placed at view/de/hstrings.php where
+   froemdoca os expecting it, so you can test your translation mmediately.
+                                  
+3. Visit your $Projectname page to check if it still works in the language you
+   just translated. If not try to find the error, most likely PHP will give
+   you a hint in the log/warnings.about the error.
+                                        
+   For debugging you can also try to "run" the file with PHP. This should
+   not give any output if the file is ok but might give a hint for
+   searching the bug in the file.
+
+       $> php view/de/hstrings.php
+
+4. commit the two files with a meaningful commit message to your git
+   repository, push it to your fork of the $Projectname repository at github and
+   issue a pull request for that commit.
+
+[h4]Utilities[/h4]
+
+Additional to the po2php script there are some more utilities for translation
+in the "util" directory of the $Projectname source tree.  If you only want to[/td][/tr]
+[tr]ranslate $Projectname into another language you wont need any of these tools most
+likely but it gives you an idea how the translation process of $Projectname
+works.
+
+For further information see the utils/README file.
+
+[h4]Known Problems[/h4]
+
+* $Projectname uses the language setting of the visitors browser to determain the
+  language for the UI. Most of the time this works, but there are some known
+  quirks.
+* the early translations are based on the friendica translations, if you 
+  some rough translations please let us know or fix them at Transifex.
+
+[h3]Licensing[/h3]
+
+All code contributed to the project falls under the MIT license, unless otherwise specified. We will accept third-party code which falls under MIT, BSD and LGPL, but copyleft licensing (GPL, and AGPL) is only permitted in addons. It must be possible to completely remove the GPL (copyleft) code from the main project without breaking anything.
+
+[h3]Coding Style[/h3]
+
+In the interests of consistency we adopt the following code styling. We may accept patches using other styles, but where possible please try to provide a consistent code style. We aren't going to argue or debate the merits of this style, and it is irrelevant what project 'xyz' uses. This is not project 'xyz'. This is a baseline to try and keep the code readable now and in the future. 
+[list]
+[*]All comments should be in English.
+[*]We use doxygen to generate documentation. This hasn't been consistently applied, but learning it and using it are highly encouraged.
+[*]Indentation is accomplished primarily with tabs using a tab-width of 4.
+[*]String concatenation and operators should be separated by whitespace. e.g. "$foo = $bar . 'abc';" instead of "$foo=$bar.'abc';"
+[*]Generally speaking, we use single quotes for string variables and double quotes for SQL statements. "Here documents" should be avoided. Sometimes using double quoted strings with variable replacement is the most efficient means of creating the string. In most cases, you should be using single quotes.
+[*]Use whitespace liberally to enhance readability. When creating arrays with many elements, we will often set one key/value pair per line, indented from the parent line appropriately. Lining up the assignment operators takes a bit more work, but also increases readability.
+[*]Generally speaking, opening braces go on the same line as the thing which opens the brace. They are the last character on the line. Closing braces are on a line by themselves. 
+[*]Some functions take arguments in argc/argv style like main() in C or function args in bash or Perl. Urls are broken up within a module. e.g, given "http://example.com/module/arg1/arg2", then $this->argc will be 3 (integer) and $this->argv will contain:   [0] => 'module', [1] => 'arg1',  [2] => 'arg2'. There will always be one argument. If provided a naked domain  URL, $this->argv[0] is set to "home".
+[/list]
+
+[h3]File system layout[/h3]
+[table border=0]
+[th]Directory[/th][th]Description[/th][/tr]
+[tr][td]addon[/td][td]optional addons/plugins[/td][/tr]
+[tr][td]boot.php[/td][td]Every process uses this to bootstrap the application structure[/td][/tr]
+[tr][td]doc[/td][td]Help Files[/td][/tr]
+[tr][td]images[/td][td]core required images[/td][/tr]
+[tr][td]include[/td][td]The "model" in MVC - (back-end functions), also contains PHP "executables" for background processing[/td][/tr]
+[tr][td]index.php[/td][td]The front-end controller for web access[/td][/tr]
+[tr][td]install[/td][td]Installation and upgrade files and DB schema[/td][/tr]
+[tr][td]library[/td][td]Third party modules (must be license compatible)[/td][/tr]
+[tr][td]mod[/td][td]Controller modules based on URL pathname (e.g. [url=http://sitename/foo]http://sitename/foo[/url] loads mod/foo.php)[/td][/tr]
+[tr][td]mod/site/[/td][td]site-specific mod overrides, excluded from git[/td][/tr]
+[tr][td]util[/td][td]translation tools, main English string database and other miscellaneous utilities[/td][/tr]
+[tr][td]version.inc[/td][td]contains current version (auto-updated via cron for the master repository and distributed via git)[/td][/tr]
+[tr][td]view[/td][td]theming and language files[/td][/tr]
+[tr][td]view/(css,js,img,php,tpl)[/td][td]default theme files[/td][/tr]
+[tr][td]view/(en,it,es ...)[/td][td]language strings and resources[/td][/tr]
+[tr][td]view/theme/[/td][td]individual named themes containing (css,js,img,php,tpl) over-rides[/td][/tr]
+[/table]
+
+[b][url=[baseurl]/help/developer/unorganized]More information needing re-organization and updating...[/url][/b]
diff --git a/doc/developer/developer_guide.md b/doc/developer/developer_guide.md
deleted file mode 100644
index fa50de8a1..000000000
--- a/doc/developer/developer_guide.md
+++ /dev/null
@@ -1,422 +0,0 @@
-### Who is a Hubzilla developer? Should I read this?
-
-Anyone who contributes to making Hubzilla better is a developer. There are many different and important ways you can contribute to this amazing technology, _even if you do not know how to write code_. The software itself is only a part of the Hubzilla project. You can contribute by 
-
-* translating text to your language so that people around the world have the opportunity to use Hubzilla
-* promoting Hubzilla and spreading awareness of the platform through blog posts, articles, and word-of-mouth
-* creating artwork and graphics for project assets such as icons and marketing material
-* supporting project infrastructure like the project website and demo servers
-
-_Software_ developers are of course welcomed; there are so many great ideas to implement and not enough people to make them all a reality! The Hubzilla code base is an advanced and mature system, but the platform is still very flexible and responsive to new ideas. 
-
-This document will help you get started learning and contributing to Hubzilla.
-
-### Versioning system
-
-The versioning system is similar to the popular semantic versioning but less stringent. Given x.y.z,  x changes yearly. y changes for "stable" monthly builds, and z increments when there are interface changes. We maintain our date and build numbers for medium grain version control (commits within a certain date range) and of course git revs for fine grained control.
-
-### Git repository branches
-
-There are two official branches of the Hubzilla git repo. 
-
-* The stable version is maintained on the **master** branch. The latest commit in this branch is considered to be suitable for production hubs. 
-* Experimental development occurs on the **dev** branch, which is merged into **master** when it is deemed tested and stable enough.
-
-### Developer tools and workflows
-
-#### Hub Snapshots
-
-The [hub snapshots](/help/admin/hub_snapshots) page provides instructions and scripts for taking complete 
-snapshots of a hub to support switching between consistent and completely known 
-states. This is useful to prevent situations where the content or database schema 
-might be incompatible with the code. 
-
-### Translations
-
-Our translations are managed through Transifex. If you wish to help out translating Hubzilla to another language, sign up on transifex.com, visit [https://www.transifex.com/projects/p/red-matrix/](https://www.transifex.com/projects/p/red-matrix/) and request to join one of the existing language teams or create a new one. Notify one of the core developers when you have a translation update which requires merging, or ask about merging it yourself if you're comfortable with git and PHP. We have a string file called 'messages.po' which is gettext compliant and a handful of email templates, and from there we automatically generate the application's language files.   
-
-#### Translation Process
-
-The strings used in the UI of Hubzilla is translated at [Transifex][1] and then
-included in the git repository at github. If you want to help with translation
-for any language, be it correcting terms or translating Hubzilla to a
-currently not supported language, please register an account at transifex.com
-and contact the Redmatrix translation team there.
-
-Translating Hubzilla is simple. Just use the online tool at transifex. If you
-don't want to deal with git & co. that is fine, we check the status of the
-translations regularly and import them into the source tree at github so that
-others can use them.
-
-We do not include every translation from transifex in the source tree to avoid
-a scattered and disturbed overall experience. As an uneducated guess we have a
-lower limit of 50% translated strings before we include the language. This
-limit is judging only by the amount of translated strings under the assumption
-that the most prominent strings for the UI will be translated first by a
-translation team. If you feel your translation useable before this limit,
-please contact us and we will probably include your teams work in the source
-tree.
-
-If you want to get your work into the source tree yourself, feel free to do so
-and contact us with and question that arises. The process is simple and
-Hubzilla ships with all the tools necessary.
-
-The location of the translated files in the source tree is
-    /view/LNG-CODE/
-where LNG-CODE is the language code used, e.g. de for German or fr for French.
-For the email templates (the *.tpl files) just place them into the directory
-and you are done. The translated strings come as a "hmessages.po" file from
-transifex which needs to be translated into the PHP file Hubzilla uses.  To do
-so, place the file in the directory mentioned above and use the "po2php"
-utility from the util directory of your Hubzilla installation.
-
-Assuming you want to convert the German localization which is placed in
-view/de/hmessages.po you would do the following.
-
-1. Navigate at the command prompt to the base directory of your
-   Hubzilla installation
-
-2. Execute the po2php script, which will place the translation
-   in the hstrings.php file that is used by Hubzilla.
-
-       $> php util/po2php.php view/de/hmessages.po
-
-   The output of the script will be placed at view/de/hstrings.php where
-   froemdoca os expecting it, so you can test your translation mmediately.
-                                  
-3. Visit your Hubzilla page to check if it still works in the language you
-   just translated. If not try to find the error, most likely PHP will give
-   you a hint in the log/warnings.about the error.
-                                        
-   For debugging you can also try to "run" the file with PHP. This should
-   not give any output if the file is ok but might give a hint for
-   searching the bug in the file.
-
-       $> php view/de/hstrings.php
-
-4. commit the two files with a meaningful commit message to your git
-   repository, push it to your fork of the Hubzilla repository at github and
-   issue a pull request for that commit.
-
-#### Utilities
-
-Additional to the po2php script there are some more utilities for translation
-in the "util" directory of the Hubzilla source tree.  If you only want to
-translate Hubzilla into another language you wont need any of these tools most
-likely but it gives you an idea how the translation process of Hubzilla
-works.
-
-For further information see the utils/README file.
-
-#### Known Problems
-
-* Hubzilla uses the language setting of the visitors browser to determain the
-  language for the UI. Most of the time this works, but there are some known
-  quirks.
-* the early translations are based on the friendica translations, if you 
-  some rough translations please let us know or fix them at Transifex.
-
-### To-be-organized information
-
-**Here is how you can join us.**
-
-First, get yourself a working git package on the system where you will be
-doing development.
-
-Create your own github account.
-
-You may fork/clone the Red repository from [https://github.com/redmatrix/hubzilla.git](https://github.com/redmatrix/hubzilla.git).
-
-Follow the instructions provided here: [http://help.github.com/fork-a-repo/](http://help.github.com/fork-a-repo/)
-to create and use your own tracking fork on github
-
-Then go to your github page and create a "Pull request" when you are ready
-to notify us to merge your work.
-
-
-**Important**
-
-Please pull in any changes from the project repository and merge them with your work **before** issuing a pull request. We reserve the right to reject any patch which results in a large number of merge conflicts. This is especially true in the case of language translations - where we may not be able to understand the subtle differences between conflicting versions.
-
-Also - **test your changes**. Don't assume that a simple fix won't break something else. If possible get an experienced Red developer to review the code. 
-
-
-**Licensing**
-
-All code contributed to the project falls under the MIT license, unless otherwise specified. We will accept third-party code which falls under MIT, BSD and LGPL, but copyleft licensing (GPL, and AGPL) is only permitted in addons. It must be possible to completely remove the GPL (copyleft) code from the main project without breaking anything.
-
-**Coding Style** 
-
-In the interests of consistency we adopt the following code styling. We may accept patches using other styles, but where possible please try to provide a consistent code style. We aren't going to argue or debate the merits of this style, and it is irrelevant what project 'xyz' uses. This is not project 'xyz'. This is a baseline to try and keep the code readable now and in the future. 
-
-* All comments should be in English.
-
-* We use doxygen to generate documentation. This hasn't been consistently applied, but learning it and using it are highly encouraged.
-
-* Indentation is accomplished primarily with tabs using a tab-width of 4.
-
-* String concatenation and operators should be separated by whitespace. e.g. "$foo = $bar . 'abc';" instead of "$foo=$bar.'abc';"
-
-* Generally speaking, we use single quotes for string variables and double quotes for SQL statements. "Here documents" should be avoided. Sometimes using double quoted strings with variable replacement is the most efficient means of creating the string. In most cases, you should be using single quotes.
-
-* Use whitespace liberally to enhance readability. When creating arrays with many elements, we will often set one key/value pair per line, indented from the parent line appropriately. Lining up the assignment operators takes a bit more work, but also increases readability.
-
-* Generally speaking, opening braces go on the same line as the thing which opens the brace. They are the last character on the line. Closing braces are on a line by themselves. 
-
-
-**File system layout:**
-
-[addon] optional addons/plugins
-
-[boot.php] Every process uses this to bootstrap the application structure
-
-[doc] Help Files
-
-[images] core required images
-
-[include] The "model" in MVC - (back-end functions), also contains PHP "executables" for background processing
-
-[index.php] The front-end controller for web access
-
-[install] Installation and upgrade files and DB schema
-
-[library] Third party modules (must be license compatible)
-
-[mod] Controller modules based on URL pathname (e.g. #^[url=http://sitename/foo]http://sitename/foo[/url] loads mod/foo.php)
-
-[mod/site/] site-specific mod overrides, excluded from git
-
-[util] translation tools, main English string database and other miscellaneous utilities
-
-[version.inc] contains current version (auto-updated via cron for the master repository and distributed via git)
-
-[view] theming and language files
-
-[view/(css,js,img,php,tpl)] default theme files
-
-[view/(en,it,es ...)] language strings and resources
-
-[view/theme/] individual named themes containing (css,js,img,php,tpl) over-rides
-
-**The Database:**
-
-
-| Table                   | Description                                            |
-|-------------------------|--------------------------------------------------------|
-| abconfig                | contact table, replaces Friendica 'contact'            |
-| abook                   |                                                        |
-| account                 | service provider account                               |
-| addon                   |                                                        |
-| addressbookchanges      |                                                        |
-| addressbooks            |                                                        |
-| app                     |                                                        |
-| atoken                  |                                                        |
-| attach                  |                                                        |
-| auth_codes              |                                                        |
-| cache                   |                                                        |
-| cal                     |                                                        |
-| calendarchanges         |                                                        |
-| calendarinstances       |                                                        |
-| calendarobjects         |                                                        |
-| calendars               |                                                        |
-| calendarsubscriptions   |                                                        |
-| cards                   |                                                        |
-| channel                 |                                                        |
-| chat                    |                                                        |
-| chatpresence            |                                                        |
-| chatroom                |                                                        |
-| clients                 |                                                        |
-| config                  |                                                        |
-| conv                    |                                                        |
-| dreport                 |                                                        |
-| event                   |                                                        |
-| group_member            |                                                        |
-| groupmembers            |                                                        |
-| groups                  |                                                        |
-| hook                    |                                                        |
-| hubloc                  |                                                        |
-| iconfig                 |                                                        |
-| issue                   |                                                        |
-| item                    |                                                        |
-| item_id                 |                                                        |
-| likes                   |                                                        |
-| locks                   |                                                        |
-| mail                    |                                                        |
-| menu                    |                                                        |
-| menu_item               |                                                        |
-| notify                  |                                                        |
-| obj                     |                                                        |
-| outq                    |                                                        |
-| pconfig                 | personal (per channel) configuration storage           |
-| photo                   |                                                        |
-| poll                    |                                                        |
-| poll_elm                |                                                        |
-| principals              |                                                        |
-| profdef                 |                                                        |
-| profext                 |                                                        |
-| profile                 |                                                        |
-| profile_check           |                                                        |
-| propertystorage         |                                                        |
-| register                |                                                        |
-| schedulingobjects       |                                                        |
-| session                 |                                                        |
-| shares                  |                                                        |
-| sign                    |                                                        |
-| site                    |                                                        |
-| source                  |                                                        |
-| sys_perms               |                                                        |
-| term                    |                                                        |
-| tokens                  |                                                        |
-| updates                 |                                                        |
-| users                   |                                                        |
-| verify                  |                                                        |
-| vote                    |                                                        |
-| xchan                   |                                                        |
-| xchat                   |                                                        |
-| xconfig                 |                                                        |
-| xign                    |                                                        |
-| xlink                   |                                                        |
-| xperm                   |                                                        |
-| xprof                   |                                                        |
-| xtag                    |                                                        |
-
-
-    * abook - contact table, replaces Friendica 'contact'
-    * account - service provider account
-    * addon - registered plugins
-    * app - peronal app data
-    * attach - file attachments
-    * auth_codes - OAuth usage
-    * cache - OEmbed cache
-    * channel - replaces Friendica 'user'
-    * chat - chat room content
-    * chatpresence - channel presence information for chat
-    * chatroom - data for the actual chat room
-    * clients - OAuth usage
-    * config - main configuration storage
-    * conv - Diaspora private messages
-    * event - Events
-    * fcontact - friend suggestion stuff
-    * ffinder - friend suggestion stuff
-    * fserver - obsolete
-    * fsuggest - friend suggestion stuff
-    * groups - privacy groups
-    * group_member - privacy groups
-    * hook - plugin hook registry
-    * hubloc - Red location storage, ties a location to an xchan
-    * item - posts
-    * item_id - other identifiers on other services for posts
-    * likes - likes of 'things'
-    * mail - private messages
-    * menu - channel menu data
-    * menu_item - items uses by channel menus
-    * notify - notifications
-    * notify-threads - need to factor this out and use item thread info on notifications
-    * obj - object data for things (x has y)
-    * outq - output queue
-    * pconfig - personal (per channel) configuration storage
-    * photo - photo storage
-    * poll - data for polls
-    * poll_elm - data for poll elements
-    * profdef - custom profile field definitions
-    * profext - custom profile field data
-    * profile - channel profiles
-    * profile_check - DFRN remote auth use, may be obsolete
-    * register - registrations requiring admin approval
-    * session - web session storage
-    * shares - shared item information
-    * sign - Diaspora signatures.  To be phased out.
-    * site - site table to find directory peers
-    * source - channel sources data
-    * spam - unfinished
-    * sys_perms - extensible permissions for the sys channel
-    * term - item taxonomy (categories, tags, etc.) table
-    * tokens - OAuth usage
-    * updates - directory sync updates
-    * verify - general purpose verification structure
-    * vote - vote data for polls
-    * xchan - replaces 'gcontact', list of known channels in the universe
-    * xchat - bookmarked chat rooms
-    * xconfig - as pconfig but for channels with no local account
-    * xlink - "friends of friends" linkages derived from poco
-    * xprof - if this hub is a directory server, contains basic public profile info of everybody in the network
-    * xtag - if this hub is a directory server, contains tags or interests of everybody in the network
-
-    
-**How to theme Hubzilla**
-
-This is a short documentation on what I found while trying to modify Hubzilla's appearance.
-
-First, you'll need to create a new theme. This is in /view/theme, and I chose to copy 'redbasic' since it's the only available for now. Let's assume I named it .
-
-Oh, and don't forget to rename the _init function in /php/theme.php to be _init() instead of redbasic_init().
-
-At that point, if you need to add javascript or css files, add them to /js or /css, and then "register" them in _init() through head_add_js('file.js') and head_add_css('file.css').
-
-Now you'll probably want to alter a template. These can be found in in /view/tpl OR view//tpl. All you should have to do is copy whatever you want to tweak from the first place to your theme's own tpl directory.
-
-
-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.  
-
-**Here is how you can join us.**
-
-First, get yourself a working git package on the system where you will be
-doing development.
-
-Create your own github account.
-
-You may fork/clone the Red repository from [url=https://github.com/redmatrix/hubzilla.git]https://github.com/redmatrix/hubzilla.git[/url]
-
-Follow the instructions provided here: [url=http://help.github.com/fork-a-repo/]http://help.github.com/fork-a-repo/[/url]
-to create and use your own tracking fork on github
-
-Then go to your github page and create a "Pull request" when you are ready
-to notify us to merge your work.
-
-**Translations**
-
-Our translations are managed through Transifex. If you wish to help out translating the $Projectname to another language, sign up on transifex.com, visit [url=https://www.transifex.com/projects/p/red-matrix/]https://www.transifex.com/projects/p/red-matrix/[/url] and request to join one of the existing language teams or create a new one. Notify one of the core developers when you have a translation update which requires merging, or ask about merging it yourself if you're comfortable with git and PHP. We have a string file called 'messages.po' which is gettext compliant and a handful of email templates, and from there we automatically generate the application's language files.   
-
-
-**Important**
-
-Please pull in any changes from the project repository and merge them with your work **before** issuing a pull request. We reserve the right to reject any patch which results in a large number of merge conflicts. This is especially true in the case of language translations - where we may not be able to understand the subtle differences between conflicting versions.
-
-Also - **test your changes**. Don't assume that a simple fix won't break something else. If possible get an experienced Red developer to review the code. 
-
-Further documentation can be found at the Github wiki pages at: [url=https://github.com/friendica/red/wiki]https://github.com/friendica/red/wiki[/url]
-
-**Licensing**
-
-All code contributed to the project falls under the MIT license, unless otherwise specified. We will accept third-party code which falls under MIT, BSD and LGPL, but copyleft licensing (GPL, and AGPL) is only permitted in addons. It must be possible to completely remove the GPL (copyleft) code from the main project without breaking anything.
-
-**Concensus Building**
-
-Code changes which fix an obvious bug are pretty straight-forward. For instance if you click "Save" and the thing you're trying to save isn't saved, it's fairly obvious what the intended behaviour should be. Often when developing feature requests, it may affect large numbers of community members and it's possible that other members of the community won't agree with the need for the feature, or with your proposed implementation. They may not see something as a bug or a desirable feature.
-
-We encourage consensus building within the community when it comes to any feature which might be considered controversial or where there isn't unanimous decision that the proposed feature is the correct way to accomplish the task. The first place to pitch your ideas is to [url=https://zothub.com/channel/one]Channel One[/url]. Others may have some input or be able to point out facets of your concept which might be problematic in our environment. But also, you may encounter opposition to your plan. This doesn't mean you should stop and/or ignore the feature. Listen to the concerns of others and try and work through any implementation issues. 
-
-There are places where opposition cannot be resolved. In these cases, please consider making your feature **optional** or non-default behaviour that must be specifically enabled. This technique can often be used when a feature has significant but less than unanimous support. Those who desire the feature can turn it on and those who don't want it - will leave it turned off.
-
-If a feature uses other networks or websites and or is only seen as desirable by a small minority of the community, consider making the functionality available via an addon or plugin. Once again, those who don't desire the feature won't need to install it. Plugins are relatively easy to create and "hooks" can be easily added or modified if the current hooks do not do what is needed to allow your plugin to work.
-     
-
-**Coding Style**
-
-In the interests of consistency we adopt the following code styling. We may accept patches using other styles, but where possible please try to provide a consistent code style. We aren't going to argue or debate the merits of this style, and it is irrelevant what project 'xyz' uses. This is not project 'xyz'. This is a baseline to try and keep the code readable now and in the future. 
-
-*  All comments should be in English.
-
-*  We use doxygen to generate documentation. This hasn't been consistently applied, but learning it and using it are highly encouraged.
-
-*  Indentation is accomplished primarily with tabs using a tab-width of 4.
-
-*  String concatenation and operators should be separated by whitespace. e.g. "$foo = $bar . 'abc';" instead of "$foo=$bar.'abc';"
-
-*  Generally speaking, we use single quotes for string variables and double quotes for SQL statements. "Here documents" should be avoided. Sometimes using double quoted strings with variable replacement is the most efficient means of creating the string. In most cases, you should be using single quotes.
-
-*  Use whitespace liberally to enhance readability. When creating arrays with many elements, we will often set one key/value pair per line, indented from the parent line appropriately. Lining up the assignment operators takes a bit more work, but also increases readability.
-
-*  Generally speaking, opening braces go on the same line as the thing which opens the brace. They are the last character on the line. Closing braces are on a line by themselves. 
-
-*  Some functions take arguments in argc/argv style like main() in C or function args in bash or Perl. Urls are broken up within a module. e.g, given "http://example.com/module/arg1/arg2", then $this->argc will be 3 (integer) and $this->argv will contain:   [0] => 'module', [1] => 'arg1',  [2] => 'arg2'. There will always be one argument. If provided a naked domain  URL, $this->argv[0] is set to "home".
\ No newline at end of file
diff --git a/doc/developer/unorganized.md b/doc/developer/unorganized.md
new file mode 100644
index 000000000..74d914aaf
--- /dev/null
+++ b/doc/developer/unorganized.md
@@ -0,0 +1,73 @@
+### To-be-organized information
+
+**Here is how you can join us.**
+
+First, get yourself a working git package on the system where you will be
+doing development.
+
+Create your own github account.
+
+You may fork/clone the Red repository from [https://github.com/redmatrix/hubzilla.git](https://github.com/redmatrix/hubzilla.git).
+
+Follow the instructions provided here: [http://help.github.com/fork-a-repo/](http://help.github.com/fork-a-repo/)
+to create and use your own tracking fork on github
+
+Then go to your github page and create a "Pull request" when you are ready
+to notify us to merge your work.
+
+
+**Important**
+
+Please pull in any changes from the project repository and merge them with your work **before** issuing a pull request. We reserve the right to reject any patch which results in a large number of merge conflicts. This is especially true in the case of language translations - where we may not be able to understand the subtle differences between conflicting versions.
+
+Also - **test your changes**. Don't assume that a simple fix won't break something else. If possible get an experienced Red developer to review the code. 
+
+**How to theme Hubzilla**
+
+This is a short documentation on what I found while trying to modify Hubzilla's appearance.
+
+First, you'll need to create a new theme. This is in /view/theme, and I chose to copy 'redbasic' since it's the only available for now. Let's assume I named it .
+
+Oh, and don't forget to rename the _init function in /php/theme.php to be _init() instead of redbasic_init().
+
+At that point, if you need to add javascript or css files, add them to /js or /css, and then "register" them in _init() through head_add_js('file.js') and head_add_css('file.css').
+
+Now you'll probably want to alter a template. These can be found in in /view/tpl OR view//tpl. All you should have to do is copy whatever you want to tweak from the first place to your theme's own tpl directory.
+
+
+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.  
+
+**Here is how you can join us.**
+
+First, get yourself a working git package on the system where you will be
+doing development.
+
+Create your own github account.
+
+You may fork/clone the Red repository from [url=https://github.com/redmatrix/hubzilla.git]https://github.com/redmatrix/hubzilla.git[/url]
+
+Follow the instructions provided here: [url=http://help.github.com/fork-a-repo/]http://help.github.com/fork-a-repo/[/url]
+to create and use your own tracking fork on github
+
+Then go to your github page and create a "Pull request" when you are ready
+to notify us to merge your work.
+
+
+**Important**
+
+Please pull in any changes from the project repository and merge them with your work **before** issuing a pull request. We reserve the right to reject any patch which results in a large number of merge conflicts. This is especially true in the case of language translations - where we may not be able to understand the subtle differences between conflicting versions.
+
+Also - **test your changes**. Don't assume that a simple fix won't break something else. If possible get an experienced Red developer to review the code. 
+
+Further documentation can be found at the Github wiki pages at: [url=https://github.com/friendica/red/wiki]https://github.com/friendica/red/wiki[/url]
+
+**Concensus Building**
+
+Code changes which fix an obvious bug are pretty straight-forward. For instance if you click "Save" and the thing you're trying to save isn't saved, it's fairly obvious what the intended behaviour should be. Often when developing feature requests, it may affect large numbers of community members and it's possible that other members of the community won't agree with the need for the feature, or with your proposed implementation. They may not see something as a bug or a desirable feature.
+
+We encourage consensus building within the community when it comes to any feature which might be considered controversial or where there isn't unanimous decision that the proposed feature is the correct way to accomplish the task. The first place to pitch your ideas is to [url=https://zothub.com/channel/one]Channel One[/url]. Others may have some input or be able to point out facets of your concept which might be problematic in our environment. But also, you may encounter opposition to your plan. This doesn't mean you should stop and/or ignore the feature. Listen to the concerns of others and try and work through any implementation issues. 
+
+There are places where opposition cannot be resolved. In these cases, please consider making your feature **optional** or non-default behaviour that must be specifically enabled. This technique can often be used when a feature has significant but less than unanimous support. Those who desire the feature can turn it on and those who don't want it - will leave it turned off.
+
+If a feature uses other networks or websites and or is only seen as desirable by a small minority of the community, consider making the functionality available via an addon or plugin. Once again, those who don't desire the feature won't need to install it. Plugins are relatively easy to create and "hooks" can be easily added or modified if the current hooks do not do what is needed to allow your plugin to work.
+     
diff --git a/doc/feature/saved_search.bb b/doc/feature/saved_search.bb
deleted file mode 100644
index 1e75f5a85..000000000
--- a/doc/feature/saved_search.bb
+++ /dev/null
@@ -1,19 +0,0 @@
-[h2]Saved Searches[/h2]
-
-In order to quickly find information, the 'saved search' widget may be used. This widget may be presented as a sidebar tool on your network page and possibly from your channel page. It is differentiated from the 'navigation bar' search tool in that it does not search the entire site, but only the subset of information available to your channel. 
-
-Additionally the search terms you provide may activate a one-tme search or be saved in a list for re-use. Saving the search item also invokes the search in addition to adding it to the saved list (which is displayed below the search text entry box). Any item in the list may be discarded if it is no longer needed. 
-
-The saved search widget will provide autocompletion of channels (the results are prefixed with '@'), and hashtags (prefixed with '#'). You do not need to enter these tags; although entering the desired tag will reduce the autocomplete results to only hold the relevant information. The behaviour maps as follows:
-
-[ul]
-
-[li]@name - search your network stream for posts or comments written by 'name'. This will also change the post editor permissions to include only 'name'; as if this was a privacy group.[/li]
-
-[li]#hashtag - search you network stream for posts containing #hashtag.[/li]
-
-[li]text - search your network stream for posts containing 'text'.[/li]
-
-
-[/li]
-
diff --git a/doc/feature/techlevels.bb b/doc/feature/techlevels.bb
deleted file mode 100644
index 9b07f086f..000000000
--- a/doc/feature/techlevels.bb
+++ /dev/null
@@ -1,15 +0,0 @@
-[h2]Techlevels[/h2]
-
-Techlevels is a unique feature of Hubzilla 'pro'. It is not available in other server_roles, although it expands on the concepts introduced in Hubzilla 'basic'.
-
-[h3]Background[/h3]
-
-We've implemented several different mechanisms in order to reduce the apparent complexity and learning curve presented to new members. At the same time, we do not wish to limit any functionality for people who are able to grasp some slightly advanced technical technical features. The first mechanism was to move several features to an optional 'Features' page where they could be enabled at will; with the default interface kept somewhat lean. 
-
-The problem we had now is that the number of features began to grow dramatically, and the Feature page is daunting in possibilities. There are also features present which probably should not be available to all members, but may be extremely useful to those with technical backgrounds.
-
-The techlevels seeeks to remedy this by grouping features within different levels of technical ability; starting at 0 (uncomfortable with technology), and up to 5 (Unix wizard or equivalent).
-
-When a new member registers, their account is provided a techlevel setting of 0. On the account settings page they may change this to any available level. A higher level opens more advanced features and possible interactions.
-
-The account administrator may also lock a particular level, lock a maximum level, or change/re-arrange the features available to any level. Those with the minimum level are typically not very exploratory and are unlikely to discover the advanced modes. This is by design. Those that look around and desire more interactions will find them. In the absence of administrator defaults they may choose any level. As they look at the features available to the level in question, it is generally expected that they will discover some features are beyond their comprehension and it is hoped they will back off to a level where the interface and features are comfortable to their skill level. This is somewhat experimental at present and for that reason is not part of the 'standard' server role. The standard server role is preset to level '5', and the basic server role is preset to level '0', with no possibility of change. Members in these roles may find themselves overwhelmed or underwhelmed by the feature set and complexity.        
diff --git a/doc/main.bb b/doc/main.bb
deleted file mode 100644
index 8ba5d481b..000000000
--- a/doc/main.bb
+++ /dev/null
@@ -1,13 +0,0 @@
-

-[zrl=[baseurl]/help/about][b]What is $Projectname?[/b][/zrl]

-$Projectname is a decentralized communication and publishing platform that enables you to keep in control of your communication needs by automatic encryption and finely grained access control. It's you, and only you who decides who is allowed to see your stuff.

-

-[zrl=[baseurl]/help/features][b]$Projectname Features[/b][/zrl]

-

-$Projectname is already running as a global distributed network and proves its versatility and scalability from standalone to huge sites on a daily basis. 

-Think of standalone family communication platforms, distributed online communities, support forums, blogs and homepages. Or professional content providers with commercial premium channels and targeted content acces. Whatever you want, $Projectname is there to cater to your creativity.

-

-[zrl=[baseurl]/help/what_is_zot][b]Got Zot? Well, you should.[/b][/zrl]

-Zot is the great new communicaton protocol invented especially for $Projectname. As a member you are no longer bound to a single site or hub thanks to "Nomadic Identities". Migrate easily to another server and keep your contacts intact, or clone it and run the same channel on several servers. Just in case one of them might shut down, you don't lose out. Plus once you are inside $Projectname there is no need for you to authenticate twice, even when accessing another $Projectname site. Zot is what sets $Projectname apart. 

-

-

diff --git a/doc/member/member_guide.bb b/doc/member/member_guide.bb
index 6d95b230c..c0fdcbb50 100644
--- a/doc/member/member_guide.bb
+++ b/doc/member/member_guide.bb
@@ -294,8 +294,11 @@ To create and manage guest tokens, open the [zrl=[baseurl]/settings/tokens/]Gues
 
 Additional permissions may be granted to the guest token by expanding the [b]Individual Permissions[/b] options and selecting privacy settings such as [b]Can view my channel stream and posts[/b] or [b]Can chat with me[/b].
 
+[url=[baseurl]/help/feature/access_tokens]More details can be found here...[/url]
+
 [img][baseurl]/doc/member/assets/zat_dialog.png[/img]
 
+
 [h3]Markup Languages[/h3]
 $Projectname supports several markup languages for advanced formatting of content. The default markup language is a [url=[baseurl]/help/member/bbcode]custom variant of BBcode[/url], tailored for use in $Projectname. [url=[baseurl]/help/member/bbcode]BBcode[/url] is supported for posts, wiki pages, and web page elements. Wiki pages and webpage elements may also be written using standard Markdown.
 [table border=0]
@@ -969,6 +972,21 @@ Once open you can set a bookmark.
 
 Note: There have been reported issues with clients that use "chunked transfer encoding", which includes Apple iOS services, and also the "AnyClient" and "CyberDuck" tools. These work fine for downloads, but uploads often end up with files of zero size. This is caused by an incorrect implemention of chunked encoding in some current FCGI (fast-cgi) implementations. Apache running with PHP as a module does not have these issues, but when running under FCGI you may need to use alternative clients or use the web uploader. At the time of this writing the issue has been open and no updates provided for at least a year. If you encounter zero size files with other clients, please check the client notes; as there are occasional configuration issues which can also produce these symptoms.  
 
+[h3]Saved Searches[/h3]
+
+In order to quickly find information, the 'saved search' widget may be used. This widget may be presented as a sidebar tool on your network page and possibly from your channel page. It is differentiated from the 'navigation bar' search tool in that it does not search the entire site, but only the subset of information available to your channel. 
+
+Additionally the search terms you provide may activate a one-time search or be saved in a list for re-use. Saving the search item also invokes the search in addition to adding it to the saved list (which is displayed below the search text entry box). Any item in the list may be discarded if it is no longer needed. 
+
+The saved search widget will provide autocompletion of channels (the results are prefixed with '@'), and hashtags (prefixed with '#'). You do not need to enter these tags; although entering the desired tag will reduce the autocomplete results to only hold the relevant information. The behaviour maps as follows:
+
+[list]
+[*]@name - search your network stream for posts or comments written by 'name'. This will also change the post editor permissions to include only 'name'; as if this was a privacy group.
+[*]#hashtag - search you network stream for posts containing #hashtag.
+[*]text - search your network stream for posts containing 'text'.
+[/list]
+
+
 [h3]Remove Channel or Account[/h3]
 
 [h4]Remove Channel[/h4]
diff --git a/doc/members.bb b/doc/members.bb
deleted file mode 100644
index bf5b09898..000000000
--- a/doc/members.bb
+++ /dev/null
@@ -1,25 +0,0 @@
-[h2]Documentation for hub members[/h2]
-[h3]Getting started[/h3]
-[zrl=[baseurl]/help/registration]Account Registration[/zrl]
-[zrl=[baseurl]/help/accounts_profiles_channels_basics]You at $Projectname: accounts, profiles and channels in short[/zrl]
-[zrl=[baseurl]/help/profiles]Profiles[/zrl]
-[zrl=[baseurl]/help/channels]Channels[/zrl]
-[zrl=[baseurl]/help/roles]Permission roles and Channel types[/zrl]
-[zrl=[baseurl]/help/first-post]Your first posting[/zrl]
-[zrl=[baseurl]/help/connecting_to_channels]Connecting To Other Channels[/zrl]
-[zrl=[baseurl]/help/permissions]Permissions And Encryption: You Are In Control[/zrl]
-[zrl=[baseurl]/help/cloud]Cloud Storage[/zrl]
-[zrl=[baseurl]/help/remove_account]Remove Channel or Account[/zrl]
-[h3]Members help[/h3]
-[zrl=[baseurl]/help/tags_and_mentions]Tags and Mentions[/zrl]
-[zrl=[baseurl]/help/webpages]Web Pages[/zrl]
-[zrl=[baseurl]/help/bbcode]BBcode reference for posts and comments[/zrl]
-[zrl=[baseurl]/help/checking_account_quota_usage]Checking Account Quota Usage[/zrl]
-[zrl=[baseurl]/help/cloud_desktop_clients]Cloud Desktop Clients[/zrl]
-[zrl=[baseurl]/help/AdvancedSearch]Advanced Directory Search[/zrl]
-[zrl=[baseurl]/help/addons]Help With Addons[/zrl]
-[zrl=[baseurl]/help/diaspora_compat]Diaspora Communications Compatibility (Diaspora and Friendica)[/zrl]
-[zrl=[baseurl]/help/faq_members]FAQ For Members[/zrl]
-[zrl=[baseurl]/help/bugs]Bugs, Issues, and things that go bump in the night...[/zrl]
-
-#include doc/macros/main_footer.bb;
diff --git a/doc/profiles.bb b/doc/profiles.bb
deleted file mode 100644
index 513bf5fed..000000000
--- a/doc/profiles.bb
+++ /dev/null
@@ -1,37 +0,0 @@
-[b]Profiles[/b]

-

-$Projectname has unlimited profiles. You may use different profiles to show different &quot;sides of yourself&quot; to different audiences. This is different to having different channels. Different channels allow for completely different sets of information. You may have a channel for yourself, a channel for your sports team, a channel for your website, or whatever else. A profile allows for finely graded &quot;sides&quot; of each channel. For example, your default public profile might say &quot;Hello, I'm Fred, and I like laughing&quot;. You may show your close friends a profile that adds &quot;and I also enjoy dwarf tossing&quot;.

-

-You always have a profile known as your &quot;default&quot; or &quot;public&quot; profile. This profile is always available to the general public and cannot be hidden (there may be rare exceptions on privately run or disconnected sites). You may, and probably should restrict the information you make available on your public profile.

-

-That said, if you want other friends to be able to find you, it helps to have the following information in your public profile...

-

-[ul][*]Your real name or at least a nickname everybody knows

-[*]A photo of you

-[*]Your location on the planet, at least to a country level.[/ul]

-

-In addition, if you'd like to meet people that share some general interests with you, please take a moment and add some &quot;Keywords&quot; to your profile. Such as &quot;music, linux, photography&quot; or whatever. You can add as many keywords as you like.

-

-To create an alternate profile, first go to [zrl=[baseurl]/settings/features]Settings &gt; Additional Features[/zrl] and enable &quot;Multiple Profiles&quot; there, otherwise you won't have the ability to use more than just your default profile.

-

-Then select &quot;Edit Profiles&quot; from the menu of your $Projectname site. You may edit an existing profile, change the profile photo, add things to a profile or create a new profile. You may also create a &quot;clone&quot; of an existing profile if you only wish to change a few items but don't wish to enter all the information again. To do that, click on the profile you want to clone and choose &quot;Clone this profile&quot; there.

-

-In the list of your profiles, you can also choose the contacts who can see a specific profile. Just click on &quot;Edit visibility&quot; next to the profile in question (only available for the profiles that are not your default profile) and then click on user images to add them to or remove them from the group of people who can see this profile.

-

-Once a profile has been selected, when the person views your profile, they will see the private profile you have assigned. If they are not authenticated, they will see your public profile.

-

-There is a setting which allows you to publish your profile to a directory and ensure that it can be found by others. You can change this setting on the &quot;Settings&quot; page.

-

-If you do not wish to be found be people unless you give them your channel address, you may leave your profile unpublished.

-

-[b]Keywords and Directory Search[/b]

-

-On the directory page, you may search for people with published profiles. Currently, only the name field and the keywords are searched.  You may also include such keywords in your default profile - which may be used to search for common interests with other members. Keywords are used in the channel suggestion tool and although they aren't visible in the directory, they are shown if people visit your profile page.

-

-On your Connnections page and in the directory there is a link to &quot;Suggestions&quot; or &quot;Channel Suggestions&quot;, respectively. This will find channels who have matching and/or similar keywords. The more keywords you provide, the more relevant the search results that are returned. These are sorted by relevance.

-

-See Also

-

-[zrl=[baseurl]/help/AdvancedSearch]Advanced Searching[/zrl]

-

-#include doc/macros/main_footer.bb;

diff --git a/doc/project/governance.bb b/doc/project/governance.bb
deleted file mode 100644
index 4c1538b4b..000000000
--- a/doc/project/governance.bb
+++ /dev/null
@@ -1,29 +0,0 @@
-[h2]$Projectname Governance[/h2]
-
-Governance relates to the management of a project and particularly how this relates to conflict resolution.
-
-[h3]Community Governance[/h3]
-
-The project is maintained and decisions made by the 'community'. The governance structure is still evolving. Until the structure is finalised, decisions are made in the following order:
-
-[ol]
-[*] Lazy Consensus
-
-If a project proposal is made to one of the community governance forums and there are no serious objections in a "reasonable" amount of time from date of proposal (we usually provide 2-3 days for all interested parties to weigh in), no vote needs to be taken and the proposal will be considered approved. Some concerns may be raised at this time, but if these are addressed during discussion and work-arounds provided, it will still be considered approved. 
-
-[*] Veto
-
-Senior developers with a significant history of project commits may veto any decision. The decision may not proceed until the veto is removed or an alternative proposal is presented.
-
-[*] Community Vote
-
-A decision which does not have a clear mandate or clear consensus, but is not vetoed, can be taken to a community vote. At present this is a simple popular vote in one of the applicable community forums.  At this time, popular vote decides the outcome. This may change in the future if the community adopts a 'council' governance model. This document will be updated at that time with the updated governance rules. 
-[/ol]
-
-Community Voting does not always provide a pleasant outcome and can generate polarised factions in the community (hence the reason why other models are under consideration). If the proposal is 'down voted' there are still several things which can be done and the proposal re-submitted with slightly different parameters (convert to an addon, convert to an optional feature which is disabled by default, etc.). If interest in the feature is high and the vote is "close", it can generate lots of bad feelings amongst the losing voters. On such close votes, it is [b]strongly recommended[/b] that the proposer take steps to address any concerns that were raised and re-submit.
-
-  
-
- 
-
-
diff --git a/doc/project/toc.html b/doc/project/toc.html
deleted file mode 100644
index e264e014d..000000000
--- a/doc/project/toc.html
+++ /dev/null
@@ -1,5 +0,0 @@
-<h3>Project Information</h3>
-<ul>
-<li><a href="help/project/governance">Project Governance</a></li>
-<li><a href="help/project/versions">Versions and Versioning</a></li>
-</ul>
diff --git a/doc/project/versions.bb b/doc/project/versions.bb
deleted file mode 100644
index 451cd0448..000000000
--- a/doc/project/versions.bb
+++ /dev/null
@@ -1,30 +0,0 @@
-[h2]Versions and Releases[/h2]
-
-$Projectname currently uses a standard version numbering sequence of $x.$y(.$z), for instance '1.12' or '1.12.1'. The first digit is the major version number. Major versions are released "roughly" once per year; often in December.
-
-The second digit is the minor release number. If this number is odd, it is a development version. If the number is even, it is a released version. Minor versions are released (moved from dev to master) typically once per month when development is 'stable', but this is likely to increase. Going forward minor releases will be made somewhere between one and three months; corresponding to a stable code point and when there is general community consensus that the current code base is stable enough to consider a release.
-
-The final digit is an interface or patch designator. 
-
-The release process involves changing the version number (by definition the minor version number will be odd, and the minor number will be incremented). Once a year for a major release the major version will be incremented, and the minor number reset to 0. 
-
-The release candidate is moved to a new branch; and testing will commence/continue for a period of 1-2 weeks afterward or until any significant issues have been resolved. This branch is usually labelled with RC (release candidate); for instance 1.8RC represents the pending release of version 1.8. At this time, the minor version number on the dev branch is incremented to the next odd number. (For instance 1.9). New development can then take place in the dev branch. 
-
-Bug fixes should always be applied to 'dev' and from there merged forward (typically with git cherry-pick) to the RC branch and if necessary applied to the master or official release branch.
-
-At the time a release candidate is produced, the language strings file is frozen until a release is made. Translation work may continue, but all translations should be submitted to 'dev' and merged forward to RC.
-
-
-Once RC testing is completed, RC is merged to 'master' and the RC version designator removed; resulting in one final checkin to change the version number. The CHANGELOG file should also be updated at or just prior to this time. If there are merge conflicts during this final merge, the merge will be abandoned; and 'git merge -s ours' applied. This results in a replacement of master with the contents of the RC branch. Conflicts often arise with string updates which were made to master after the last release and cannot easily be resolved without hand editing. Since this is a release of tested code, hand editing is discouraged, and the replacement merge strategy should be used instead. It is assumed that RC now contains the most recent well-tested code. 
-
-Once the release is live and merged to master, the RC branch may be removed. 
-
-Fixes may be made to master after release. Where possible these should be made to dev and 'git cherry-pick' used to merge forward; which preserves the commit info and prevents merge conflicts in the next cycle. Only rarely does a patch only apply to the master branch. If necessary this can be made. If the change is severe, the interface version number should be incremented. This is at the discretion of the community. In any event, a 'git pull' of the master branch should always result in the latest release with any post-release patches applied. 
-
-The interface number (the $z in $x.$y.$z) should be incremented in dev whenever a change is made which changes the interfaces or API in incompatible ways so that any external packages (especially addons and API clients) relying on a the current behaviour can discover and change their own interfaces accordingly at the point that it changed.  
- 
-
-
-
-
-    
\ No newline at end of file
diff --git a/doc/server_roles.bb b/doc/server_roles.bb
deleted file mode 100644
index ef6ec28ae..000000000
--- a/doc/server_roles.bb
+++ /dev/null
@@ -1,27 +0,0 @@
-[h2]Server Roles[/h2]
-
-$Projectname can be configured in many different ways. One of the configurations available at installation is to select a 'server role'. There are currently three server roles. We highly recommend that you use 'standard' unless you have special needs. 
-
-
-[h3]Basic[/h3]
-
-The 'basic' server role is designed to be relatively simple, and it doesn't present options or complicated features. The hub admin may configure additional features at a site level. This role is designed for simple social networking and social network federation. Many features which do not federate easily have been removed, including (and this is somewhat important) "nomadic identity". You may move a channel to or from a basic server, but you may not clone it. Once moved, it becomes read-only on the origination site. No updates of any kind will be provided. It is recommended that after the move, the original channel be deleted - as it is no longer useable. The data remains only in case there are issues making a copy of the data. 
-
-This role is supported by the hubzilla community.
-
-[h3]Standard[/h3]
-
-
-The 'standard' server role is recommended for most sites. All features of the software are available to everybody unless locked by the hub administrator. Some features will not federate easily with other networks, so there is often an increased support burden explaining why sharing events with Diaspora (for instance) presents a different experience on that network. Additionally any member can enable "advanced" or "expert" features, and these may be beyond their technical skill level. This may also result in an increased support burden.
-
-This role is supported by the hubzilla community.
-
-[h3]Pro[/h3]
-
-The 'pro' server role is primarily designed for communities which want to present a uniform experience and be relieved of many federation support issues. In this role there is [b]no federation with other networks[/b]. Additional features [b]may[/b] be provided, such as channel ratings, premium channels, and e-commerce. 
-
-By default a channel may set a "techlevel" appropriate to their technical skill. Higher levels provide more features. Everybody starts with techlevel 0 (similar to the 'basic' role) where all complicated features are hidden from view. Increasing the techlevel provides more advanced or complex features.
-
-The hub admin may also lock individual channels or their entire site at a defined techlevel which provides an installation with a selection of advanced features consistent with the perceived technical skills of the members. For instance, a community for horse racing might have a different techlevel than a community for Linux kernel developers. 
-
-This role is not supported by the hubzilla community. 
\ No newline at end of file
diff --git a/doc/service_classes.bb b/doc/service_classes.bb
deleted file mode 100644
index 4dead5d29..000000000
--- a/doc/service_classes.bb
+++ /dev/null
@@ -1,38 +0,0 @@
-[b]Service Classes[/b]
-
-Service classes allow you to set limits on system resources. A GUI to configure this is currently under development. 
-
-As a temporary measure, the following commandline utilities can be used:
-
-Usage:
-
-[code]util/service_class[/code]
-list service classes
-
-[code]util/config system default_service_class firstclass[/code]
-set the default service class to 'firstclass'
-
-[code]util/service_class firstclass[/code]
-list the services that are part of 'firstclass' service class
-
-[code]util/service_class firstclass photo_upload_limit 10000000[/code]
-set firstclass total photo disk usage to 10 million bytes
-
-[code]util/service_class --account=5 firstclass[/code]
-set account id 5 to service class 'firstclass' (with confirmation)
-
-[code]util/service_class --channel=blogchan firstclass[/code]
-set the account that owns channel 'blogchan' to service class 'firstclass' (with confirmation)
-
-[b]current limits[/b]
-photo_upload_limit - maximum total bytes for photos
-total_items - maximum total toplevel posts
-total_pages - maximum comanche pages
-total_identities - maximum number of channels owned by account
-total_channels - maximum number of connections
-total_feeds - maximum number of rss feed connections
-attach_upload_limit - maximum file upload storage (bytes)
-minimum_feedcheck_minutes - lowest setting allowed for polling rss feeds
-chatrooms - maximum chatrooms
-chatters_inroom - maximum chatters per room
-access_tokens - maximum number of Guest Access Tokens per channel
\ No newline at end of file
diff --git a/doc/theme_management.bb b/doc/theme_management.bb
deleted file mode 100644
index 5691f7c48..000000000
--- a/doc/theme_management.bb
+++ /dev/null
@@ -1,10 +0,0 @@
-[h1]Theme Management[/h1]

-$Projectname allows hub admins to easily add and update themes hosted in common git repositories.

-[h2]Add new theme repo to your hub[/h2]

-1. Navigate to your hub web root 

-[code]root@hub:~# cd /var/www[/code] 

-2. Add the theme repo and give it a name 

-[code][nobb]root@hub:/var/www# util/add_theme_repo https://github.com/username/theme-repo.git UniqueThemeRepoName[/nobb][/code] 

-[h2]Update existing theme repo[/h2]

-Update the repo by using 

-[code]root@hub:/var/www# util/update_theme_repo UniqueThemeRepoName[/code]

diff --git a/doc/to_do_code.bb b/doc/to_do_code.bb
deleted file mode 100644
index b1c4923b1..000000000
--- a/doc/to_do_code.bb
+++ /dev/null
@@ -1,42 +0,0 @@
-[b]Project Code To-Do List[/b]

-

-We need much more than this, but here are areas where developers can help. Please edit this page when items are finished. Another place for developers to start is with the issues list.

-

-[li]Documentation - see Red Documentation Project To-Do List[/li]

-[li]Include TOS link in registration/verification email[/li]

-[li]Auto preview posts/comments (configurable timer kicks in the preview if not 0)[/li]

-[li]SAML 2.0 and OpenID Connect provider functionality[/li]

-[li]relmeauth (aka indieauth) support[/li]

-[li]Create bug tracker module[/li]

-[li]Filing posts - provide a dropdown menu integrated with the 'post actions menu'[/li]

-[li]translation plugins - moses or apertium[/li]

-[li]plugins - provide 'disable' which is softer than 'uninstall' for those plugins which create additional DB tables[/li]

-[li]Infinite scroll improvements (i.e. embedded page links) see http://scrollsample.appspot.com/items [/li]

-[li]Finish the anti-spam bayesian engine[/li]

-[li]implement an email permission denied bounce message from the sys channel[/li]

-[li]provide a way for xchans with a certain network type to upgrade (unknown to rss, rss to statusnet, friendica-over-diaspora to friendica, for instance) based on new knowledge and/or redmatrix ability[/li]

-[li]Integrate the &quot;open site&quot; list with the register page[/li]

-[li]Support comments and member notes on documentation pages (to achieve an effect similar to php.net)[/li]

-[li]Support comments on webpages[/li]

-[li]Write more webpage layouts[/li]

-[li]Write more webpage widgets[/li]

-[li]restricted access OAuth clients[/li]

-[li](Advanced) create a UI for building Comanche pages[/li]

-[li](less advanced) create a way to preview Comanche results on a preview page while editing on another page[/li]

-[li]External post connectors - create standard interface[/li]

-[li]External post connectors, add popular services[/li]

-[li]service classes - provide a pluggable subscription payment gateway for premium accounts[/li]

-[li]service classes - account overview page showing resources consumed by channel. With special consideration this page can also be accessed at a meta level by the site admin to drill down on problematic accounts/channels.[/li]

-[li]Uploads - integrate #^[url=https://github.com/blueimp/jQuery-File-Upload]https://github.com/blueimp/jQuery-File-Upload[/url][/li]

-[li]API extensions, for Twitter API - search, friending, threading. For Red API, lots of stuff[/li]

-[li]Import channel from Diaspora/Friendica (Diaspora partially done)[/li]

-[li]MediaGoblin photo "crosspost" connector[/li]

-[li]provide a visual editor[/li]

-[li]Create mobile clients for the top platforms - which involves extending the API so that we can do stuff far beyond the current crop of Twitter/Statusnet clients. Ditto for mobile themes. We can probably use something like the Friendica Android app as a base to start from.[/li]

-[li]Implement owned and exchangeable &quot;things&quot;.[/li]

-[li]Family Account creation - using service classes (an account holder can create a certain number of sub-accounts which are all tied to their subscription - if the subscription lapses they all go away).[/li]

-

-

-In many cases some of the work has already been started and code exists so that you needn't start from scratch. Please contact one of the developer channels like Channel One (one@zothub.com) before embarking and we can tell you what we already have and provide some insights on how we envision these features fitting together.

-

-Return to the [url=[baseurl]/help/main]Main documentation page[/url]

diff --git a/doc/to_do_doco.md b/doc/to_do_doco.md
deleted file mode 100644
index 018b9efa2..000000000
--- a/doc/to_do_doco.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# Documentation To-Do List #

-

-## How to contribute documentation ##

-

-Documentation files are in */doc*.

-

-When help is first accessed, the file loaded is *main.bb*. That file contains case sensitive links without an extension. The extensions is added automatically if the file is found, first *.md* then *.bb*.

-

-For translating documentation, create a directory in */doc* named by the language code, copy the files and translate the content.

-

-## Documentation we need to write ##

-

-* Database schema detailed descriptions

-

-* Complete plugin hook documentation

-

-* API documentation

-

-* Function and code documentation (doxygen)

-

-* New Member guide

-

-* &quot;Extra Feature&quot; reference, description of each

-

-* Detailed Personal Settings Documentation

-

-* Administration Guide (post-install)

-

-* Administration Guide (pre-install)

-

-#include doc/macros/main_footer.bb;

diff --git a/doc/toc.html b/doc/toc.html
index 851f356e6..3c9c5c299 100644
--- a/doc/toc.html
+++ b/doc/toc.html
@@ -37,6 +37,7 @@
             <ul class="list-group">
                 <li class="doco-list-group-item"><a href="/help/admin/administrator_guide">Guide</a></li>
                 <li class="doco-list-group-item"><a href="/help/admin/hub_snapshots">Hub Snapshots</a></li>
+                <li class="doco-list-group-item"><a href="/help/database">Database Tables</a></li>
             </ul>
         </div>
     </div>
@@ -49,8 +50,10 @@
         <div id="developers" class="panel-collapse collapse in">
             <ul class="list-group">
                 <li class="doco-list-group-item"><a href="/help/developer/developer_guide">Guide</a></li>
+                <li class="doco-list-group-item"><a href="/help/developer/covenant">Code of Conduct</a></li>
                 <li class="doco-list-group-item"><a href="/help/developer/zot_protocol">Zot Protocol</a></li>
                 <li class="doco-list-group-item"><a href="/help/developer/api_zot">Zot API</a></li>
+                <li class="doco-list-group-item"><a href="/help/hooklist">Hooks</a></li>
             </ul>
         </div>
     </div>