Merge pull request #634 from anaqreon/dev

I'm going to go ahead and merge this. It should be easy to revert undesired changes.

31 files changed, 646 insertions, 1649 deletions

diff --git a/doc/admin/administrator_guide.md b/doc/admin/administrator_guide.md
index b7056e7e3..f21c55327 100644
--- a/doc/admin/administrator_guide.md
+++ b/doc/admin/administrator_guide.md
@@ -308,8 +308,16 @@ empty:
 1. On the $Projectname server visit new.hub/locs and upgrade to your channel to a primary one. And when the old Redmatrix server is still listed delete them here as well. Press "Sync" to inform all other server in the grid.
 
 ### Troubleshooting
+
 #### Log files
 
+The system logfile is an extremely useful resource for tracking down things that go wrong. This can be enabled in the admin/log configuration page. A loglevel setting of LOGGER_DEBUG is preferred for stable production sites. Most things that go wrong with communications or storage are listed here. A setting of LOGGER_DATA provides [b]much[/b] more detail, but may fill your disk. In either case we recommend the use of logrotate on your operating system to cycle logs and discard older entries. 
+
+At the bottom of your .htconfig.php file are several lines (commented out) which enable PHP error logging. This reports issues with code syntax and executing the code and is the first place you should look for issues which result in a "white screen" or blank page. This is typically the result of code/syntax problems. 
+Database errors are reported to the system logfile, but we've found it useful to have a file in your top-level directory called dbfail.out which [b]only[/b] collects database related issues. If the file exists and is writable, database errors will be logged to it as well as to the system logfile.
+
+In the case of "500" errors, the issues may often be logged in your webserver logs, often /var/log/apache2/error.log or something similar. Consult your operating system documentation. 
+
 There are three different log facilities.
 
 **The first is the database failure log**. This is only used if you create a file called specifically 'dbfail.out' in the root folder of your website and make it write-able by the web server. If we have any database failed queries, they are all reported here. They generally indicate typos in our queries, but also occur if the database server disconnects or tables get corrupted. On rare occasions we'll see race conditions in here where two processes tried to create an xchan or cache entry with the same ID. Any other errors (especially persistent errors) should be investigated.
@@ -343,3 +351,14 @@ To immediately clear out all the extra logging stuff you added.  Use the informa
 1. Enable the **logrot** addon in the official [hubzilla-addons](https://github.com/redmatrix/hubzilla-addons) repo
 1. Create a directory in your web root called `log` with webserver write permissions
 1. Go to the **logrot** admin settings and enter this folder name as well as the max size and number of retained log files.
+
+
+#### Reporting issues
+
+When reporting issues, please try to provide as much detail as may be necessary for developers to reproduce the issue and provide the complete text of all error messages.
+
+We encourage you to try to the best of your abilities to use these logs combined with the source code in your possession to troubleshoot issues and find their cause. The community is often able to help, but only you have access to your site logfiles and it is considered a security risk to share them.   
+
+If a code issue has been uncovered, please report it on the project bugtracker (https://github.com/redmatrix/hubzilla/issues). Again provide as much detail as possible to avoid us going back and forth asking questions about your configuration or how to duplicate the problem, so that we can get right to the problem and figure out what to do about it. You are also welcome to offer your own solutions and submit patches. In fact we encourage this as we are all volunteers and have little spare time available. The more people that help, the easier the workload for everybody. It's OK if your solution isn't perfect. Every little bit helps and perhaps we can improve on it. 
+
+
diff --git a/doc/api_zot.md b/doc/api_zot.md
deleted file mode 100644
index 6da8cddbe..000000000
--- a/doc/api_zot.md
+++ /dev/null
@@ -1,84 +0,0 @@
-Zot API
-=======
-
-
-
-channel/export/basic
-
-	Export channel data
-
-
-
-channel/stream
-
-	Fetch channel conversation items 
-
-network/stream
-
-	Fetch network conversation items 
-
-
-[files](help/api/api_files)
-
-	List file storage
-
-filemeta
-
-	Export file metadata for any uploaded file
-
-
-[filedata](help/api/api_filedata)
-
-	Fetch file contents or partial contents for any uploaded file 
-
-
-file/export
-
-file
-
-[albums](help/api/api_albums)
-
-	List photo albums
-
-
-photos
-
-	list photo metadata
-
-
-photo
-
-
-[group](help/api/group)
-
-	List privacy groups
-
-[group_members](help/api/group_members)
-
-	List members of a privacy group
-
-
-[xchan](help/api/api_xchan)
-
-	Global extended channel (identity) information
-
-[item/update](help/api/api_item_update)
-
-	Create or update an item (post, activity, webpage, etc.)
-
-
-item/full
-
-	Get all data associated with an item
-
-abook
-
-	Connections
-
-abconfig
-
-	Connection metadata (such as permissions)
-
-perm_allowed
-
-	Check a permission for a given xchan
diff --git a/doc/channels.bb b/doc/channels.bb
deleted file mode 100644
index eca8dd0e6..000000000
--- a/doc/channels.bb
+++ /dev/null
@@ -1,39 +0,0 @@
-[h2]Channels[/h2]

-

-[h3]What are channels?[/h3]

-

-Channels are simply collections of content stored in one place. A channel can represent anything. It could represent you, a website, a forum, photo albums, anything. For most people, their first channel with be "Me".

-

-The most important features for a channel that represents "me" are:

-[ul]

-[*]Secure and private "spam free" communications

-

-[*]Identity and "single-signon" across the entire network

-

-[*]Privacy controls and permissions which extend to the entire network

-

-[*]Directory services (like a phone book)

-[/ul]

-In short, a channel that represents yourself is "me, on the internet".

-

-[h3]Creating channels[/h3]

-

-You will be required to create your first channel as part of the sign up process. You can also create additonal channels from the "Select channel" link.

-

-You will be asked to provide a channel name, and a short nick name. For a channel that represents yourself, it is a good idea to use your real name here to ensure your friends can find you, and connect to your channel. The short nickname will be used to generate a "webbie". This is a bit like a username, and will look like an email address, taking the form nickname@domain. You should put a little thought into what you want to use here. Imagine somebody asking for your webbie and having to tell them it is "llamas-are_kewl.123". "llamasarecool" would be a much better choice.

-

-Once you have created your channel, you will be taken to the settings page, where you can configure your channel, and set your default permissions.

-

-Once you have done this, your channel is ready to use. At [observer=1][observer.url][/observer][observer=0]example.com/channel/username[/observer] you will find your channel "stream". This is where your recent activity will appear, in reverse chronological order. If you post in the box marked "share", the entry will appear at the top of your stream. You will also find links to all the other communication areas for this channel here. The "About" tab contains your "profile", the photos page contain photo albums, and the events page contains events share by both yourself and your contacts.

-

-[h3]The grid, permissions and delegation[/h3]

-

-The "Grid" page contains all recent posts from across $Projectname network, again in reverse chronologial order. The exact posts that appear here depend largely on your permissions. At their most permissive, you will receive posts from complete strangers. At the other end of the scale, you may see posts from only your friends - or if you're feeling really anti-social, only your own posts.

-

-As mentioned at the start, many other kinds of channel are possible, however, the creation procedure is the same. The difference between channels lies primarily in the permissions assigned. For example, a channel for sharing documents with colleagues at work would probably want more permissive settings for "Can write to my "public" file storage" than a personal account. For more information, see the [zrl=[baseurl]/help/roles]permissions section[/zrl].

-

-You can also delegate control of your channels' posts and connections, but not its configurations, to another channel. That is done by editing a connection and assigning it the permission to administer your channel's resources.

-

-#include doc/macros/main_footer.bb;

-

-

diff --git a/doc/cloud.bb b/doc/cloud.bb
deleted file mode 100644
index 2ad22806b..000000000
--- a/doc/cloud.bb
+++ /dev/null
@@ -1,27 +0,0 @@
-[b]Personal Cloud Storage[/b]

-

-$Projectname provides an ability to store privately and/or share arbitrary files with friends.

-

-You may either upload files from your computer into your storage area, or copy them directly from the operating system using the WebDAV protocol.

-

-On many public servers there may be limits on disk usage.

-

-[b]File Attachments[/b]

-

-The quickest and easiest way to share files is through file attachments. In the row of icons below the status post editor is a tool to upload attachments. Click the tool, select a file and submit. After the file is uploaded, you will see an attachment code placed inside the text region. Do not edit this line or it may break the ability for your friends to see the attachment. You can use the post permissions dialogue box or privacy hashtags to restrict the visibility of the file - which will be set to match the permissions of the post your are sending.

-

-To delete attachments or change the permissions on the stored files, visit [observer.baseurl]/cloud/{{username}}" replacing {{username}} with the nickname you provided during channel creation.

-

-[b]Web Access[/b]

-

-Your files are visible on the web at the location "cloud/{{username}}" to anybody who is allowed to view them. If the viewer has sufficient privileges, they may also have the ability to create new files and folders/directories.

-

-[b]WebDAV access[/b]

-

-See: [zrl=[baseurl]/help/cloud_desktop_clients]Cloud Desktop Clients[/zrl]

-

-[b]Permissions[/b]

-

-When using WebDAV, the file is created with your channel's default file permissions and this cannot be changed from within the operating system. It also may not be as restrictive as you would like. What we've found is that the preferred method of making files private is to first create folders or directories; then visit "filestorage/{{username}}"; select the directory and change the permissions. Do this before you put anything into the directory. The directory permissions take precedence so you can then put files or other folders into that container and they will be protected from unwanted viewers by the directory permissions. It is common for folks to create a "personal" or "private" folder which is restricted to themselves. You can use this as a personal cloud to store anything from anywhere on the web or any computer and it is protected from others. You might also create folders for "family" and "friends" with permission granted to appropriate privacy groups.

-

-#include doc/macros/main_footer.bb;

diff --git a/doc/cloud_desktop_clients.bb b/doc/cloud_desktop_clients.bb
deleted file mode 100644
index 2f099527f..000000000
--- a/doc/cloud_desktop_clients.bb
+++ /dev/null
@@ -1,21 +0,0 @@
-[b]Cloud Desktop Clients[/b]

-

-[b]Windows Clients[/b]

-

-[li][zrl=[baseurl]/help/dav_windows]Windows Internal Client[/zrl][/li]

-

-

-[b]Linux Clients[/b]

-

-[li][zrl=[baseurl]/help/dav_mount]Command Line as a Filesystem[/zrl][/li]

-[li][zrl=[baseurl]/help/dav_dolphin]Dolphin[/zrl][/li]

-[li][zrl=[baseurl]/help/dav_konqueror]Konqueror[/zrl][/li]

-[li][zrl=[baseurl]/help/dav_nautilus]Nautilus[/zrl][/li]

-[li][zrl=[baseurl]/help/dav_nemo]Nemo[/zrl][/li]

-

-

-[b]Server Notes[/b]

-

-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.  

-

-#include doc/macros/cloud_footer.bb;

diff --git a/doc/connecting_to_channels.bb b/doc/connecting_to_channels.bb
deleted file mode 100644
index 291323f75..000000000
--- a/doc/connecting_to_channels.bb
+++ /dev/null
@@ -1,19 +0,0 @@
-[b]Connecting To Channels[/b]

-

-Connections in $Projectname can take on a great many different meanings. But let's keep it simple, you want to be friends with somebody like you are familiar with from social networking. How do you do it?

-

-First, you need to find some channels to connect to. There are two primary ways of doing this. Firstly, setting the "Can send me their channel stream and posts" permission to "Anybody in this network" will bring posts from complete strangers to your matrix. This will give you a lot of public content and should hopefully help you find interesting, entertaing people, forums, and channels.

-

-The next thing you can do is look at the Directory. The directory is available on every $Projectname website which means searching from your own site will bring in results from the entire network. You can search by name, interest, location and keyword. This is incomplete, so we'll improve this paragraph later.

-

-To connect with other $Projectname channels:

-

-Visit their profile by clicking their photograph in the directory, matrix, or comments, and it will open their channel home page in the channel viewer. At the left hand side of the screen, you will usually see a link called "connect". Click it, and you're done. Depending on the settings of the channel you are connecting to, you may need to wait for them to approve your connection, but no further action is needed on your part. Once you've initiated the connection, you will be taken to the connection editor. This allows you to assign specific permissions for this channel. If you don't allow any permissions, communication will be very limited. There are some quick links which you can use to avoid setting individual permissions. To provide a social network environment, "Full Sharing" is recommended. You may review the settings that are applied with the quick links to ensure they are suitable for the channel you are connecting with and adjust if necessary. Then scroll to the bottom of the page and click "Submit".

-

-You may also connect with any channel by visiting the "Connections" page of your site or the Directory and typing their "webbie" into the "Add New Connection" field. Use this method if somebody tells you their webbie and you wish to connect with them. A webbie looks like an email address; for example "bob@example.com". The process is the same as connecting via the "Connect" button - you will then be taken to the connection editor to set permissions.

-

-[b]Premium Channels[/b]

-

-Some channels are designated "Premium Channels" and may require some action on your part before a connection can be established. The Connect button will for these channels will take you to a page which lists in detail what terms the channel owner has set. If the terms are accepted, the connection will then proceed normally. In some cases, such as with celebrities and world-reknowned publishers, this may involve payment. If you do not agree to the terms, the connection will not proceed, or it may proceed but with reduced permissions allowed on your interactions with that channel.

-

-#include doc/macros/main_footer.bb;

diff --git a/doc/connecting_to_channels.md b/doc/connecting_to_channels.md
deleted file mode 100644
index 349f58b67..000000000
--- a/doc/connecting_to_channels.md
+++ /dev/null
@@ -1,34 +0,0 @@
-# Connecting To Channels #
-
-Connections in $Projectname can take on a great many different meanings. But let's keep it simple, you want to be friends with somebody like you are familiar with from social networking. How do you do it?
-
-First, you need to find some channels to connect to.  There are two primary ways of doing this.  Firstly, setting the "Can send me their channel stream and posts" permission to "Anybody in this network" will bring posts from complete strangers to your matrix.  This will give you a lot of public content and should hopefully help you find interesting, entertaing people, forums, and channels.
-
-The next thing you can do is look at the Directory.  The directory is available on every $Projectname website which means searching from your own site will bring in results from the entire network.  You can search by name, interest, location and keyword.  This is incomplete, so we'll improve this paragraph later.
-
-To connect with other $Projectname channels:
-
-Visit their profile by clicking their photograph in the directory, matrix, or comments, and it will open their channel home page in the channel viewer.  At the left hand side of the screen, you will usually see a link called "connect".  Click it, and you're done.  Depending on the settings of the channel you are connecting to, you may need to wait for them to approve your connection, but no further action is needed on your part. Once you've initiated the connection, you will be taken to the connection editor. This allows you to assign specific permissions for this channel. If you don't allow any permissions, communication will be very limited. There are some quick links which you can use to avoid setting individual permissions. To provide a social network environment, "Full Sharing" is recommended. You may review the settings that are applied with the quick links to ensure they are suitable for the channel you are connecting with and adjust if necessary. Then scroll to the bottom of the page and click "Submit". 
-
-You may also connect with any channel by visiting the "Connections" page of your site or the Directory and typing their "webbie" into the "Add New Connection" field. Use this method if somebody tells you their webbie and you wish to connect with them. A webbie looks like an email address; for example "bob@example.com". The process is the same as connecting via the "Connect" button - you will then be taken to the connection editor to set permissions. 
-
-## Block/Ignore/Archive/Hide channels ##
-
-Channels in your address book can have statuses such as *blocked*, *ignored*, *archived* and *hidden*. From your connections page you can see tabs that display the channels with those statuses. From your edit connection pages you can change the statuses of a channel.
-
-Here's their meaning:
-
-**Blocked:** the channel can't read your items regardless of permissions, nor can it write to your channel.
-
-**Ignored:** the channel can read your items if it has permission, but can't write to your channel.
-
-**Hidden:** the channel does not show up in your profile's connections list, noone can see you're connected, but beware they may still show up to your other connections, for example in post replies.
-
-**Archived:** if a channel can't be reached for 30 days, it is automatically marked as archived. This keeps all the data but stops polling the channel for new information and removes it from autocomplete. If later you learn the channel has come back online, you may manually unarchive it.
-
-
-## Premium Channels ##
-
-Some channels are designated "Premium Channels" and **may** require some action on your part before a connection can be established. The Connect button will for these channels will take you to a page which lists in detail what terms the channel owner has set. If the terms are accepted, the connection will then proceed normally. In some cases, such as with celebrities and world-reknowned publishers, this **may** involve payment. If you do not agree to the terms, the connection will not proceed, or it may proceed but with reduced permissions allowed on your interactions with that channel. 
-
-#include doc/macros/main_footer.bb;
diff --git a/doc/credits.bb b/doc/credits.bb
deleted file mode 100644
index 5219d7bf5..000000000
--- a/doc/credits.bb
+++ /dev/null
@@ -1,82 +0,0 @@
-[b]Credits[/b]
-
-Thanks to all who have helped and contributed to the project and its predecessors over the years. It is possible we missed in your name but this is unintentional. We also thank the community and its members for providing valuable input and without whom this entire effort would be meaningless. 
-
-It is also worth acknowledging the contributions and solutions to problems which arose from discussions amongst members and developers of other somewhat related and competing projects; even if we have had our occasional disagreements. 
-
-Mike Macgirvin
-Fabio Comuni
-Simon L'nu
-marijus
-Tobias Diekershoff
-fabrixxm
-tommy tomson
-Simon
-zottel
-Christian Vogeley
-Jeroen van Riet Paap (jeroenpraat)
-Michael Vogel
-erik
-Zach Prezkuta
-Paolo T
-Michael Meer
-Michael
-Abinoam P. Marques Jr
-Tobias Hößl
-Alexander Kampmann
-Olaf Conradi
-Paolo Tacconi
-tobiasd
-Devlon Duthie
-Zvi ben Yaakov (a.k.a rdc)
-Alexandre Hannud Abdo
-Olivier Migeot
-Chris Case
-Klaus Weidenbach
-Michael Johnston
-olivierm
-Vasudev Kamath
-pixelroot
-Max Weller
-duthied
-Martin Schmitt
-Sebastian Egbers
-Erkan Yilmaz
-sasiflo
-Stefan Parviainen
-Haakon Meland Eriksen
-Oliver Hartmann (23n)
-Erik Lundin
-habeascodice
-sirius
-Charles
-Tony Baldwin
-Hauke Zuehl
-Keith Fernie
-Anne Walk
-toclimb
-Daniel Frank
-Matthew Exon
-Michal Supler
-Tobias Luther
-U-SOUND\mike
-mrjive
-nostupidzone
-tonnerkiller
-Antoine G
-Christian Drechsler
-Ludovic Grossard
-RedmatrixCanada
-Stanislav Lechev [0xAF]
-aweiher
-bufalo1973
-dsp1986
-felixgilles
-ike
-maase2
-mycocham
-ndurchx
-pafcu
-Simó Albert i Beltran
-Manuel Reva
-Manuel Jiménez Friaza
diff --git a/doc/dav_dolphin.bb b/doc/dav_dolphin.bb
deleted file mode 100644
index ae60a6d52..000000000
--- a/doc/dav_dolphin.bb
+++ /dev/null
@@ -1,9 +0,0 @@
-[b]Using The Cloud - Dolphin[/b]

-

-Visit webdavs://example.com/dav where "example.com" is the URL of your hub.

-

-When prompted for a username and password, enter your channel name (the first part of your webbie - no @ or domain name) and password for your normal account.

-

-Note, if you are already logged in to the web interface via Konqueror, you will not be prompted for further authentication.

-

-#include doc/macros/cloud_footer.bb;

diff --git a/doc/dav_konqueror.bb b/doc/dav_konqueror.bb
deleted file mode 100644
index 97c046e46..000000000
--- a/doc/dav_konqueror.bb
+++ /dev/null
@@ -1,12 +0,0 @@
-[b]Using The Cloud - Konqueror[/b]

-

-Simply visit webdavs://example.com/dav after logging in to your hub, where "example.com" is the URL of your hub.

-

-No further authentication is required if you are logged in to your hub in the normal manner.  

-

-Additionally, if one has authenticated at a different hub during their normal browser session, your identity will be passed to the cloud for these hubs too - meaning you can access any private files on any server, as long as you have permissions to see them, as long as you have visited that site earlier in your session.

-

-This functionality is normally restricted to the web interface, and is not available to any desktop software other than KDE.

-

-#include doc/macros/cloud_footer.bb;

-

diff --git a/doc/dav_mount.bb b/doc/dav_mount.bb
deleted file mode 100644
index 94db18ac7..000000000
--- a/doc/dav_mount.bb
+++ /dev/null
@@ -1,83 +0,0 @@
-[b]Mounting As A Filesystem[/b]

-

-To install your cloud directory as a filesystem, you first need davfs2 installed.  99% of the time, this will be included in your distributions repositories.  In Debian

-

-[code]apt-get install davfs2[/code]

-

-If you want to let normal users mount the filesystem

-

-[code] dpkg-reconfigure davfs2[/code]

-

-and select "yes" at the prompt.

-

-Now you need to add any user you want to be able to mount dav to the davfs2 group

-

-[code]usermod -aG davfs2 <DesktopUser>[/code]

-

-[b]Note:[/b] on some systems the user group may be different, i.e. - "network" 

-on Arch Linux. If in doubt, check the davfs documentation for your 

-particular OS.

-

-Edit /etc/fstab

-

-[code]nano /etc/fstab[/code]

-

- to include your cloud directory by adding

-

-[code]

-[baseurl]/dav/ /mount/point davfs user,noauto,uid=<DesktopUser>,file_mode=600,dir_mode=700 0 1

-[/code]

-

-Where [baseurl] is the URL of your hub, /mount/point is the location you want to mount the cloud, and <DesktopUser> is the user you log in to one your computer.  Note that if you are mounting as a normal user (not root) the mount point must be in your home directory.

-

-For example, if I wanted to mount my cloud to a directory called 'cloud' in my home directory, and my username was bob, my fstab would be 

-

-[code][baseurl]/dav/ /home/bob/cloud davfs user,noauto,uid=bob,file_mode=600,dir_mode=700 0 1[/code]

-

-Now, create the mount point.

-

-[code]mkdir /home/bob/cloud[/code]

-

-and also create a directory file to store your credentials

-

-[code]mkdir /home/bob/.davfs2[/code]

-

-Create a file called 'secrets'

-

-[code]nano /home/bob/.davfs2/secrets[/code]

-

-and add your cloud login credentials

-

-[code]

-[baseurl]/dav <username> <password>

-[/code]

-

-Where <username> and <password> are the username and password [i]for your hub[/i].

-

-Don't let this file be writeable by anyone who doesn't need it with

-

-[code]chmod 600 /home/bob/.davfs2/secrets[/code]

-

-Finally, mount the drive.

-

-[code]mount [baseurl]/dav[/code]

-

-You can now find your cloud at /home/bob/cloud and use it as though it were part of your local filesystem - even if the applications you are using have no dav support themselves.

-

-[b]Troubleshooting[/b]

-

-With some webservers and certain configurations, you may find davfs2 creating files with 0 bytes file size where other clients work just fine.  This is generally caused by cache and locks.  If you are affected by this issue, you need to edit your davfs2 configuration.

-

-[code]nano /etc/davfs2/davfs2.conf[/code]

-

-Your distribution will provide a sample configuration, and this file should already exist, however, most of it will be commented out with a # at the beginning of the line.  

-

-First step is to remove locks.

-

-Edit the use_locks line so it reads [code]use_locks 0[/code].

-

-Unmount your file system, remount your file system, and try copying over a file from the command line.  Note you should copy a new file, and not overwrite an old one for this test.  Leave it a minute or two then do [code]ls -l -h[/code] and check the file size of your new file is still greater than 0 bytes.  If it is, stop there, and do nothing else.

-

-If that still doesn't work, disable the cache.  Note that this has a performance impact so should only be done if disabling locks didn't solve your problem.  Edit the cache_size and set it to [code]cache_size 0[/code] and also set file_refresh to [code]file_refresh 0[/code].  Unmount your filesystem, remount your file system, and test it again.

-

-If it [i]still[/i] doesn't work, there is one more thing you can try.  (This one is caused by a bug in older versions of dav2fs itself, so updating to a new version may also help).  Enable weak etag dropping by setting [code]drop_weak_etags 1[/code].  Unmount and remount your filesystem to apply the changes.

diff --git a/doc/dav_nautilus.bb b/doc/dav_nautilus.bb
deleted file mode 100644
index c8911cda8..000000000
--- a/doc/dav_nautilus.bb
+++ /dev/null
@@ -1,9 +0,0 @@
-[b]Using The Cloud - Nautilus[/b]

-

-1. Open a File browsing window (that's Nautilus)

-2. Select File > Connect to server from the menu

-3. Type davs://<domain_name>/dav/<your_channelname> and click Connect

-4. You will be prompted for your channel name (same as above) and password

-5. Your personal DAV directory will be shown in the window

-

-#include doc/macros/cloud_footer.bb;

diff --git a/doc/dav_nemo.bb b/doc/dav_nemo.bb
deleted file mode 100644
index f2d994fbb..000000000
--- a/doc/dav_nemo.bb
+++ /dev/null
@@ -1,19 +0,0 @@
-[b]Using The Cloud - Nemo[/b]

-

-For (file browser) Nemo 1.8.2 under Linux Mint 15, Cinnamon 1.8.8. Nemo ist the standard file browser there.

-

-1st way

-type "davs://<domain_name>/dav/<your_channelname>" in the address bar.

-

-2nd way

-Menu > file > connect to server

-Fill the dialog

-- Server: hubzilla_domain_name

-- Type: Secure WebDAV (https)

-- Folder: /dav

-- Username: yourchannelname

-- Password: yourpassword

-

-Once open you can set a bookmark.

-

-#include doc/macros/cloud_footer.bb; 

diff --git a/doc/dav_windows.bb b/doc/dav_windows.bb
deleted file mode 100644
index 96862e2b5..000000000
--- a/doc/dav_windows.bb
+++ /dev/null
@@ -1,11 +0,0 @@
-[b]Using The Cloud - Windows Internal Client[/b]

-

-RedDav using Windows 7 graphical user interface wizard:

-1. Left-click the Start-button to open the start menu.

-2. Right-click the My computer icon to access its menu.

-3. Left-click Map network drive... to open the connection dialog wizard.

-4. Type #^[url=https://example.net/dav/your_channel_name]https://example.net/dav/your_channel_name[/url] in the textbox and click the Complete button where "example.net" is the URL of your hub.

-5. Type your Hubzilla account's user name. IMPORTANT - NO at-sign or domain name.

-6. Type your Hubzilla password

-

-#include doc/macros/cloud_footer.bb;

diff --git a/doc/developer/zot_protocol.bb b/doc/developer/zot_protocol.bb
index 007672c70..159024612 100644
--- a/doc/developer/zot_protocol.bb
+++ b/doc/developer/zot_protocol.bb
@@ -1,6 +1,14 @@
 [h3] What is Zot?[/h3]
 Zot is the revolutionary protocol that powers $Projectname, providing [b]communications[/b], [b]identity management[/b], and [b]access control[/b] across a fully [b]decentralised[/b] network of independent websites, often called "the grid". The resulting platform is a robust system that supports privacy and security while enabling the kind of rich web services typically seen only in centralized, proprietary solutions.
 
+Consider this typical scenario: 
+
+Jaquelina wishes to share photos with Roberto from her blog at [b]jaquelina.org[/b], but to nobody else. Roberto maintains his own family hub at [b]roberto.net[/b] on a completely independent server. Zot allows Jaquelina to publish her photos using an [i]access control list (ACL)[/i] that includes only Roberto. That means that while Roberto can see the photos when he visits her blog, his brother Marco cannot, and neither can any of his other family members who have accounts on [b]roberto.net[/b].
+
+The magic in this scenario comes from the fact that Roberto never logged in to Jaquelina's website. Instead, he had to login only once using his password on his [i]own[/i] website at [b]roberto.net[/b]. When Roberto visits [b]jaquelina.org[/b], her hub seamlessly authenticates him by remotely querying his server in the background. 
+
+It is not uncommon for servers to have technical problems or become inaccessible for a variety of reasons. Zot provides robustness for Roberto's online activities by allowing him to have [i]clones[/i] of his online identity, or [i]channel[/i], on multiple independent hubs. Imagine that Roberto's server crashes for some reason and he cannot log in there. He simply logs in to one of his clones at [b]gadfly.com[/b], a site operated by his friend Peter. Once authenticated at [b]gadfly.com[/b], Roberto can view Jaquelina's blog as before, without Jaquelina having to grant any additional access!
+
 [h4] Communications[/h4]
 Communications and social networking are an integral part of the grid. Any channel (and any services provided by that channel) can make full use of feature-rich social communications on a global scale. These communications may be public or private - and private communications comprise not only fully encrypted transport, but also encrypted storage to help protect against accidental snooping and disclosure by rogue system administrators and internet service providers. 
 
@@ -32,6 +40,366 @@ This type of control is trivial on large corporate providers because they own th
 
 Access can be granted or denied for any resource, to any channel, or any group of channels; anywhere within the grid. Others can access your content if you permit them to do so, and they do not even need to have an account on your hub. 
 
+[h3]Technical Introduction[/h3]
+Zot is a JSON-based web framework for implementing secure decentralised communications and services. In order to provide this functionality, Zot creates a decentralised globally unique identifier for each hub on the network. This global identifier is not linked inextricably to DNS, providing the requisite mobility. Many existing decentralised communications frameworks provide the communication aspect, but do not provide remote access control and authentication. Additionally most of these are based on 'webfinger', which still binds identity to domain names and cannot support nomadic identity.
+
+The primary issues Zot addresses are 
+
+[list]
+[*] completely decentralised communications
+[*] independence from DNS-based identity
+[*] node mobility
+[*] seamless remote authentication
+[*] high performance
+[/list]
+We will rely on DNS-based user@host addresses as a "user-friendly" mechanism to let people know where you are, specifically on a named host with a given username, and communication will be carried out to DNS entities using TCP and the web.
+
+But the underlying protocol will provide an abstraction layer on top of this, so that a communications node (e.g. "identity") can move to an alternate DNS location and (to the best of our ability) gracefully recover from site re-locations and/or maintain pre-existing communication relationships. A side effect of this requirement is the ability to communicate from alternate/multiple DNS locations and service providers and yet maintain a single online identity.
+
+We will call this overlay network the "grid". Servers attached to this network are known as "hubs" and may support any number of individual identities. 
+
+An identity does not necessarily correspond to a person. It is just something which requires the ability to communicate within the grid. 
+
+The ability to recover will be accomplished by communication to the original location when creating a new or replacement identity, or as a fallback from a stored file describing the identity and their contacts in the case where the old location no longer responds. 
+
+At least on the short term, the mobility of existing content is not a top priority. This may or may not take place at a later stage. The most important things we want to keep are your identity and your friends.  
+
+Addresses which are shared amongst people are user@host, and which describe the [b]current[/b] local account credentials for a given identity. These are DNS based addresses and used as a seed to locate a given identity within the grid. The machine communications will bind this address to a globally unique ID. A single globally unique ID may be attached or bound to any number of DNS locations. Once an identity has been mapped or bound to a DNS location, communications will consist of just knowing the globally unique address, and what DNS (url) is being used currently (in order to call back and verify/complete the current communication). These concepts will be specified in better detail. 
+
+In order for an identity to persist across locations, one must be able to provide or recover 
+
+[list]
+[*] the globally unique ID for that identity
+[*] the private key assigned to that identity
+[*] (if the original server no longer exists) an address book of contacts for that identity.
+[/list]
+This information will be exportable from the original server via API, and/or downloadable to disk or thumb-drive. 
+
+We may also attempt to recover with even less information, but doing so is prone to account hijacking and will require that your contacts confirm the change. 
+
+In order to implement high performance communications, the data transfer format for all aspects of Zot is JSON. XML communications require way too much overhead.
+
+Bi-directional encryption is based on RSA 4096-bit keys expressed in DER/ASN.1 format using the PKCS#8 encoding variant, with AES-256-CBC used for block encryption of variable length or large items.
+
+Some aspects of well known "federation protocols" (webfinger, salmon, activitystreams, portablecontacts, etc.) may be used in zot, but we are not tied to them and will not be bound by them. $Projectname project is attempting some rather novel developments in decentralised communications and if there is any need to diverge from such "standard protocols" we will do so without question or hesitation. 
+
+In order to create a globally unique ID, we will base it on a whirlpool hash of the identity URL of the origination node and a psuedo-random number, which should provide us with a 256 bit ID with an extremely low probability of collision (256 bits represents approximately 115 quattuorviginitillion or 1.16 X 10^77 unique numbers). This will be represented in communications as a base64url-encoded string. We will not depend on probabilities however and the ID must also be attached to a public key with public key cryptography used to provide an assurance of identity which has not been copied or somehow collided in whirlpool hash space.
+
+Basing this ID on DNS provides a globally unique seed, which would not be the case if it was based completely on psuedo-random number generation.  
+
+We will refer to the encoded globally unique uid string as zot_uid 
+
+As there may be more than one DNS location attached/bound to a given zot_uid identity, delivery processes should deliver to all of them - as we do not know for sure which hub instance may be accessed at any given time. However we will designate one DNS location as "primary" and which will be the preferred location to view web profile information.
+
+We must also provide the ability to change the primary to a new location. A look-up of information on the current primary location may provide a "forwarding pointer" which will tell us to update our records and move everything to the new location. There is also the possibility that the primary location is defunct and no longer responding. In that case, a location which has already been mapped to this zot_uid can seize control, and declare itself to be primary. In both cases the primary designation is automatically approved and moved. A request can also be made from a primary location which requests that another location be removed. 
+
+In order to map a zot_uid to a second (or tertiary) location, we require a secure exchange which verifies that the new location is in possession of the private key for this zot_uid. Security of the private key is thus essential to avoid hijacking of identities.
+
+Communications will then require
+[list]
+[*] zot_uid (string)
+[*] uid_sig 
+[*] callback (current location Zot endpoint url)
+[*] callback_sig
+[*] spec (int)
+[/list]
+passed with every communique. The spec is a revision number of the applicable Zot spec so that communications can be maintained with hubs using older and perhaps incompatible protocol specifications. Communications are verified using a stored public key which was copied when the connection to this zot_uid was first established. 
+
+Key revocation and replacement must take place from the primary hub. The exact form for this is still being worked out, but will likely be a notification to all other bound hubs to "phone home" (to the primary hub) and request a copy of the new key. This communique should be verified using a site or hub key; as the original identity key may have been compromised and cannot be trusted.   
+
+In order to eliminate confusion, there should be exactly one canonical url for any hub, so that these can be indexed and referenced without ambiguity. 
+
+So as to avoid ambiguity of scheme, it is strongly encouraged that all addresses to be https with a "browser valid" cert and a single valid host component (either www.domain.ext or domain.ext, but not both), which is used in all communications. Multiple URLs may be provided locally, but only one unique URL should be used for all Zot communications within the grid.
+
+Test installation which do not connect to the public grid may use non-SSL, but all traffic flowing over public networks should be safe from session-hijacking, preferably with a "browser recognised" cert.
+
+Where possible, Zot encourages the use of "batching" to minimise network traffic between two hubs. This means that site 'A' can send multiple messages to site 'B' in a single transaction, and also consolidate deliveries of identical messages to multiple recipients on the same hub.
+
+Messages themselves may or may not be encrypted in transit, depending on the private nature of the messages. SSL (strongly encouraged) provides unconditional encryption of the data stream, however there is little point in encrypting public communications which have been designated as having unrestricted visibility. The encryption of data storage and so-called "end-to-end encryption" is outside the scope of zot. It is presumed that hub operators will take adequate safeguards to ensure the security of their data stores and these are functions of application and site integrity as opposed to protocol integrity. 
+
+
+[h4]Messages[/h4]
+
+Given the constraints listed previously, a Zot communique should therefore be a json array of individual messages. These can be mixed and combined within the same transmission.
+
+Each message then requires:
+[list]
+[*] type
+[*] (optional) recipient list
+[/list]
+Lack of a recipient list would indicate an unencrypted public or site level message. The recipient list would contain an array of zot_uid with an individual decryption key, and a common iv. The decryption key is encoded with the recipient identity's public key. The iv is encrypted with the sender's private key.
+
+All messages should be digitally signed by the sender.    
+
+The type can be one of (this list is extensible):
+[list]
+[*] post (or activity)
+[*] mail
+[*] identity
+[*] authenticate
+[/list]
+Identity messages have no recipients and notify the system social graph of an identity update, which could be a new or deleted identity, a new or deleted location, or a change in primary hub. The signature for these messages uses system keys as opposed to identity-specific keys.
+
+Posts include many different types of activities, such as top-level posts, likes/dislikes, comments, tagging activities, etc. These types are indicated within the message sturcture.
+
+authenticate messages result in mutual authentication and browser redirect to protected resources on the remote hub such as the ability to post wall-to-wall messages and view private photo albums and events, etc.
+
+[h4]Discovery[/h4]
+
+A well-known url is used to probe a hub for Zot capabilities and identity lookups, including the discovery of public keys, profile locations, profile photos, and primary hub location. 
+
+The location for this service is /.well-known/zot-info - and must be available at the root of the chosen domain.
+
+To perform a lookup, a POST request is made to the discovery location with the following parameters:
+
+Required:
+
+address  => an address on the target system such as "john"
+
+Optional
+
+target     => the Zot "guid" of the observer for evaluating permissions
+
+target_sig => an RSA signature (base64url encoded) of the guid
+
+key        => The public key needed to verify the signature
+
+token      => a string (possibly random) chosen by the requesting service. If provided, an entry in the discovered packet will be provided called 'signed_token' which consists of the base64url_encoded RSA signature of the concatenation of the string 'token.' and the provided token using the private key of the discovered channel. This can be verified using the provided 'key' entry, and provides assurance that the server is in possession of the private key for the discovered identity. After 2017-01-01 it is [b]required[/b] that a server provide a signed_token [i]if[/i] a token was provided in the request.  
+
+With no target provided, the permissions returned will be generic permissions 
+for unknown or unauthenticated observers
+
+Example of discovery packet for 'mike@zothub.com'
+[code nowrap]
+	{
+
+    "success": true,
+	"signed_token": "KBJrKTq1qrctNuxF3GwVh3GAGRqmgkirlXANPcJZAeWlvSt_9TMV097slR4AYnYCBEushbVqHEJ9Rb5wHTa0HzMbfRo8cRdl2yAirvvv5d98dtwHddQgX1jB0xEypXtmIYMdPGDLvhI1RNdIBhHkkrRcNreRzoy4xD--HM6m1W0-A8PJJJ9BcNxmGPcBtLzW08wzoP9trJ3M7DQ6Gkk6j7iwVsyApw1ZBaDvabGTdc_SFV-Iegtqw3rjzT_xXWsfzMlKBy-019MYn_KS-gu23YzjvGu5tS_zDfkQb8DMUlPLz5yyxM0yOMlUDtG2qQgIJAU2O0X6T5xDdJ6mtolNyhepg845PvFDEqBQGMIH1nc47CNumeudDi8IWymEALhjG_U8KAK7JVlQTJj2EKUb0au1g6fpiBFab5mmxCMtZEX3Jreyak5GOcFFz-WpxuXJD9TdSoIvaBfBFOoJnXkg2zE4RHXeQzZ2FotmrbBG5dm8B-_6byYGoHBc08ZsWze1K96JIeRnLpBaj6ifUDcVHxZMPcGHHT27dvU2PNbgLiBjlAsxhYqkhN5qOHN8XBcg2KRjcMBaI3V0YMxlzXz5MztmZq3fcB1p-ccIoIyMPMzSj3yMB7J9CEU2LYPSTHMdPkIeDE6GaCkQKviaQQJQde346tK_YjA2k7_SOBmvPYE",
+    "guid": "sebQ-IC4rmFn9d9iu17m4BXO-kHuNutWo2ySjeV2SIW1LzksUkss12xVo3m3fykYxN5HMcc7gUZVYv26asx-Pg",
+    "guid_sig": "Llenlbl4zHo6-g4sa63MlQmTP5dRCrsPmXHHFmoCHG63BLq5CUZJRLS1vRrrr_MNxr7zob_Ykt_m5xPKe5H0_i4pDj-UdP8dPZqH2fqhhx00kuYL4YUMJ8gRr5eO17vsZQ3XxTcyKewtgeW0j7ytwMp6-hFVUx_Cq08MrXas429ZrjzaEwgTfxGnbgeQYQ0R5EXpHpEmoERnZx77VaEahftmdjAUx9R4YKAp13pGYadJOX5xnLfqofHQD8DyRHWeMJ4G1OfWPSOlXfRayrV_jhnFlZjMU7vOdQwHoCMoR5TFsRsHuzd-qepbvo3pzvQZRWnTNu6oPucgbf94p13QbalYRpBXKOxdTXJrGdESNhGvhtaZnpT9c1QVqC46jdfP0LOX2xrVdbvvG2JMWFv7XJUVjLSk_yjzY6or2VD4V6ztYcjpCi9d_WoNHruoxro_br1YO3KatySxJs-LQ7SOkQI60FpysfbphNyvYMkotwUFI59G08IGKTMu3-GPnV1wp7NOQD1yzJbGGEGSEEysmEP0SO9vnN45kp3MiqbffBGc1r4_YM4e7DPmqOGM94qksOcLOJk1HNESw2dQYWxWQTBXPfOJT6jW9_crGLMEOsZ3Jcss0XS9KzBUA2p_9osvvhUKuKXbNztqH0oZIWlg37FEVsDs_hUwUJpv2Ar09k4",
+    "key": "-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA7QCwvuEIwCHjhjbpz3Oc\ntyei/Pz9nDksNbsc44Cm8jxYGMXsTPFXDZYCcCB5rcAhPPdZSlzaPkv4vPVcMIrw\n5cdX0tvbwa3rNTng6uFE7qkt15D3YCTkwF0Y9FVZiZ2Ko+G23QeBt9wqb9dlDN1d\nuPmu9BLYXIT/JXoBwf0vjIPFM9WBi5W/EHGaiuqw7lt0qI7zDGw77yO5yehKE4cu\n7dt3SakrXphL70LGiZh2XGoLg9Gmpz98t+gvPAUEotAJxIUqnoiTA8jlxoiQjeRK\nHlJkwMOGmRNPS33awPos0kcSxAywuBbh2X3aSqUMjcbE4cGJ++/13zoa6RUZRObC\nZnaLYJxqYBh13/N8SfH7d005hecDxWnoYXeYuuMeT3a2hV0J84ztkJX5OoxIwk7S\nWmvBq4+m66usn6LNL+p5IAcs93KbvOxxrjtQrzohBXc6+elfLVSQ1Rr9g5xbgpub\npSc+hvzbB6p0tleDRzwAy9X16NI4DYiTj4nkmVjigNo9v2VPnAle5zSam86eiYLO\nt2u9YRqysMLPKevNdj3CIvst+BaGGQONlQalRdIcq8Lin+BhuX+1TBgqyav4XD9K\nd+JHMb1aBk/rFLI9/f2S3BJ1XqpbjXz7AbYlaCwKiJ836+HS8PmLKxwVOnpLMbfH\nPYM8k83Lip4bEKIyAuf02qkCAwEAAQ==\n-----END PUBLIC KEY-----\n",
+    "name": "Mike Macgirvin",
+    "name_updated": "2012-12-06 04:59:13",
+    "address": "mike@zothub.com",
+    "photo_mimetype": "image/jpeg",
+    "photo": "https://zothub.com/photo/profile/l/1",
+    "photo_updated": "2012-12-06 05:06:11",
+    "url": "https://zothub.com/channel/mike",
+    "connections_url": "https://zothub.com/poco/mike",
+    "target": "",
+    "target_sig": "",
+    "searchable": false,
+    "permissions": {
+        "view_stream": true,
+        "view_profile": true,
+        "view_photos": true,
+        "view_contacts": true,
+        "view_storage": true,
+        "view_pages": true,
+        "send_stream": false,
+        "post_wall": false,
+        "post_comments": false,
+        "post_mail": false,
+        "post_photos": false,
+        "tag_deliver": false,
+        "chat": false,
+        "write_storage": false,
+        "write_pages": false,
+        "delegate": false
+    },
+    "profile": {
+        "description": "Freedom Fighter",
+        "birthday": "0000-05-14",
+        "next_birthday": "2013-05-14 00:00:00",
+        "gender": "Male",
+        "marital": "It's complicated",
+        "sexual": "Females",
+        "locale": "",
+        "region": "",
+        "postcode": "",
+        "country": "Australia"
+    },
+    "locations": [
+        {
+            "host": "zothub.com",
+            "address": "mike@zothub.com",
+            "primary": true,
+            "url": "https://zothub.com",
+            "url_sig": "eqkB_9Z8nduBYyyhaSQPPDN1AhSm5I4R0yfcFxPeFpuu17SYk7jKD7QzvmsyahM5Kq7vDW6VE8nx8kdFYpcNaurqw0_IKI2SWg15pGrhkZfrCnM-g6A6qbCv_gKCYqXvwpSMO8SMIO2mjQItbBrramSbWClUd2yO0ZAceq3Z_zhirCK1gNm6mGRJaDOCuuTQNb6D66TF80G8kGLklv0o8gBfxQTE12Gd0ThpUb5g6_1L3eDHcsArW_RWM2XnNPi_atGNyl9bS_eLI2TYq0fuxkEdcjjYx9Ka0-Ws-lXMGpTnynQNCaSFqy-Fe1aYF7X1JJVJIO01LX6cCs-kfSoz29ywnntj1I8ueYldLB6bUtu4t7eeo__4t2CUWd2PCZkY3PKcoOrrnm3TJP5_yVFV_VpjkcBCRj3skjoCwISPcGYrXDufJxfp6bayGKwgaCO6QoLPtqqjPGLFm-fbn8sVv3fYUDGilaR3sFNxdo9mQ3utxM291XE2Pd0jGgeUtpxZSRzBuhYeOybu9DPusID320QbgNcbEbEImO8DuGIxuVRartzEXQF4WSYRdraZzbOqCzmU0O55P836JAfrWjgxTQkXlYCic-DBk-iE75JeT72smCtZ4AOtoFWCjZAABCw42J7JELY9APixZXWriKtjy6JI0G9d3fs6r7SrXr1JMy0",
+            "callback": "https://zothub.com/post",
+            "sitekey": "-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA1IWXwd/BZuevq8jzNFoR\n3VkenduQH2RpR3Wy9n4+ZDpbrUKGJddUGm/zUeWEdKMVkgyllVA/xHdB7jdyKs1X\nuIet9mIdnzvhdLO/JFD5hgbNG2wpSBIUY6aSNeCFTzszqXmuSXMW5U0Ef5pCbzEA\nnhoCoGL1KAgPqyxnGKUlj7q2aDwC9IRNtAqNyFQL67oT91vOQxuMThjlDhbR/29Q\ncYR4i1RzyahgEPCnHCPkT2GbRrkAPjNZAdlnk9UesgP16o8QB3tE2j50TVrbVc/d\nYRbzC56QMPP9UgUsapNeSJBHji75Ip/E5Eg/kfJC/HEQgyCqjCGfb7XeUaeQ7lLO\nqc7CGuMP+Jqr/cE54/aSHg8boTwxkMp11Ykb+ng17fl57MHTM2RJ99qZ1KBkXezR\nuH1lyvjzeJPxEFr9rkUqc4GH74/AgfbgaFvQc8TS7ovEa5I/7Pg04m7vLSEYc6UF\nYJYxXKrzmZT2TDoKeJzaBBx5MFLhW19l68h9dQ8hJXIpTP0hJrpI+Sr6VUAEfFQC\ndIDRiFcgjz6j7T/x8anqh63/hpsyf2PMYph1+4/fxtSCWJdvf+9jCRM8F1IDfluX\n87gm+88KBNaklYpchmGIohbjivJyru41CsSLe0uinQFvA741W00w6JrcrOAX+hkS\nRQuK1dDVwGKoIY85KtTUiMcCAwEAAQ==\n-----END PUBLIC KEY-----\n"
+        }
+    ],
+    "site": {
+        "url": "https://zothub.com",
+        "directory_mode": "primary",
+        "directory_url": "https://zothub.com/dirsearch"
+    }
+
+	}
+[/code]
+
+
+Discovery returns a JSON array with the following components:
+
+'success' => ('1' or '')  Operation was successful if '1'. Otherwise an optional 'message' may be present indicating the source of error.
+
+'signed_token' => If a token parameter was provided in the request, it is prepended with the text 'token.' and then RSA signed with the channel private key and base64url encoded and returned as 'signed_token'.
+
+'guid' => the guid of the address on the target system
+
+'guid_sig' => the base64url encoded RSA signature of the guid, signed with the private key associated with that guid.
+
+'key' => the public key associated with that guid
+
+'name' => channel name
+
+'name_updated' => MySQL style timestamp '2012-01-01 00:00:00' when the name was last changed (UTC)
+
+'address' => "webbie" or user@host address associated with this channel
+
+'photo' => URL of a profile photo for this channel (ideally 175x175)
+
+'photo_mimetype' => content-type of the profile photo
+
+'photo_updated' => MySQL style timestamp when photo was last updated (UTC)  
+
+'url' => location of channel homepage
+
+'connections_url' => location of Portable Contacts (extended for zot) URL for this channel
+
+'target' => if a permissions target was specified, it is mirrored
+
+'target_sig' => if a permissions target was specified, the signature is mirrored.
+    
+'searchable' => ('1' or '') '1' indicates this entry can be searched in a directory
+
+[h5]Permissions[/h5]
+
+
+'permisssions' => extensible array of permissions appropriate to this target, values are '1' or ''
+
+  Permissions may include:
+[list]
+[*] view_stream
+[*] view_profile
+[*] view_photos
+[*] view_contacts
+[*] view_storage
+[*] view_pages
+[*] send_stream
+[*] post_wall
+[*] post_comments
+[*] post_mail
+[*] post_photos
+[*] tag_deliver
+[*] chat
+[*] write_storage
+[*] write_pages
+[*] delegate
+[/list]
+
+
+[h5]Profile[/h5]
+
+
+'profile' => array of important profile fields
+[list]
+[*] description
+[*] birthday YYYY-MM-DD , all fields are optional, any field (such as year) may be zero
+[*] next_birthday => MySQL datetime string representing the next upcoming birthday, converted from the channel's default timezone to UTC. 
+[*] gender (free form)
+[*] marital (marital status)
+[*] sexual (preference)
+[*] locale (city)
+[*] region (state)
+[*] postcode
+[*] country
+[/list]
+
+[h5]Locations[/h5]
+
+
+'locations' => array of registered locations (DNS locations) this channel may be visible or may be posting from
+
+Each location is an array of
+
+'host' => DNS hostname, e.g. example.com
+
+'address' => the webbie or user@host identifier associated with this location
+
+'primary' => ('1' or '') whether or not this is the primary location for this channel where files and web pages are generally found
+
+'url' => url of the root of this DNS location e.g. https://example.com
+
+'url_sig' => base64url encoded RSA signature of the URL, signed with the channel private key
+
+'callback' => Zot communications endpoint on this site, usually https://example.com/post
+
+'sitekey' => public key of this site/host
+
+
+[h5]Site[/h5]
+
+
+'site' => array providing the directory role of the site responding to this request
+
+'url' => url of this site e.g. https://example.com
+
+'directory_mode' => one of 'primary', 'secondary', 'normal', or 'standalone'
+
+'directory_url' => if this is a directory server or standalone, the URL for the directory search module
+
+
+
+[h3]Magic Auth[/h3]
+
+So-called "magic auth" takes place by a special exchange. On the remote computer, a redirection is made to the Zot endpoint with special GET parameters.
+
+Endpoint: https://example.com/post/name
+
+where 'name' is the left hand side of the channel webbie, for instance 'mike' where the webbie is 'mike@zothub.com'
+
+Additionally four parameters are supplied:
+[list]
+[*] auth => the webbie of the person requesting access
+[*] dest => the desired destination URL (urlencoded)
+[*] sec  => a random string which is also stored locally for use during the verification phase. 
+[*] version => the Zot revision
+[/list]
+When this packet is received, a Zot message is initiated to the auth identity:
+
+[code nowrap]
+    {
+      "type":"auth_check",
+      "sender":{
+        "guid":"kgVFf_1_SSbyqH-BNWjWuhAvJ2EhQBTUdw-Q1LwwssAntr8KTBgBSzNVzUm9_RwuDpxI6X8me_QQhZMf7RfjdA",
+        "guid_sig":"PT9-TApzpm7QtMxC63MjtdK2nUyxNI0tUoWlOYTFGke3kNdtxSzSvDV4uzq_7SSBtlrNnVMAFx2_1FDgyKawmqVtRPmT7QSXrKOL2oPzL8Hu_nnVVTs_0YOLQJJ0GYACOOK-R5874WuXLEept5-KYg0uShifsvhHnxnPIlDM9lWuZ1hSJTrk3NN9Ds6AKpyNRqf3DUdz81-Xvs8I2kj6y5vfFtm-FPKAqu77XP05r74vGaWbqb1r8zpWC7zxXakVVOHHC4plG6rLINjQzvdSFKCQb5R_xtGsPPfvuE24bv4fvN4ZG2ILvb6X4Dly37WW_HXBqBnUs24mngoTxFaPgNmz1nDQNYQu91-ekX4-BNaovjDx4tP379qIG3-NygHTjFoOMDVUvs-pOPi1kfaoMjmYF2mdZAmVYS2nNLWxbeUymkHXF8lT_iVsJSzyaRFJS1Iqn7zbvwH1iUBjD_pB9EmtNmnUraKrCU9eHES27xTwD-yaaH_GHNc1XwXNbhWJaPFAm35U8ki1Le4WbUVRluFx0qwVqlEF3ieGO84PMidrp51FPm83B_oGt80xpvf6P8Ht5WvVpytjMU8UG7-js8hAzWQeYiK05YTXk-78xg0AO6NoNe_RSRk05zYpF6KlA2yQ_My79rZBv9GFt4kUfIxNjd9OiV1wXdidO7Iaq_Q",
+        "url":"http:\/\/podunk.edu",
+        "url_sig":"T8Bp7j5DHHhQDCFcAHXfuhUfGk2P3inPbImwaXXF1xJd3TGgluoXyyKDx6WDm07x0hqbupoAoZB1qBP3_WfvWiJVAK4N1FD77EOYttUEHZ7L43xy5PCpojJQmkppGbPJc2jnTIc_F1vvGvw5fv8gBWZvPqTdb6LWF6FLrzwesZpi7j2rsioZ3wyUkqb5TDZaNNeWQrIEYXrEnWkRI_qTSOzx0dRTsGO6SpU1fPWuOOYMZG8Nh18nay0kLpxReuHCiCdxjXRVvk5k9rkcMbDBJcBovhiSioPKv_yJxcZVBATw3z3TTE95kGi4wxCEenxwhSpvouwa5b0hT7NS4Ay70QaxoKiLb3ZjhZaUUn4igCyZM0h6fllR5I6J_sAQxiMYD0v5ouIlb0u8YVMni93j3zlqMWdDUZ4WgTI7NNbo8ug9NQDHd92TPmSE1TytPTgya3tsFMzwyq0LZ0b-g-zSXWIES__jKQ7vAtIs9EwlPxqJXEDDniZ2AJ6biXRYgE2Kd6W_nmI7w31igwQTms3ecXe5ENI3ckEPUAq__llNnND7mxp5ZrdXzd5HHU9slXwDShYcW3yDeQLEwAVomTGSFpBrCX8W77n9hF3JClkWaeS4QcZ3xUtsSS81yLrp__ifFfQqx9_Be89WVyIOoF4oydr08EkZ8zwlAsbZLG7eLXY"
+      },
+      "recipients":{
+        {
+        "guid":"ZHSqb3yGar3TYV_o9S-JkD-6o_V4DhUcxtv0VeyX8Kj_ENHPI_M3SyAUucU835-mIayGMmTpqJz3ujPkcavVhA",
+        "guid_sig":"JsAAXigNghTkkbq8beGMJjj9LBKZn28hZ-pHSsoQuwYWvBJ2lSnfc4r9l--WgO6sucH-SR6RiBo78eWn1cZrh_cRMu3x3LLx4y-tjixg-oOOgtZakkBg4vmOhkKPkci0mFtzvUrpY4YHySqsWTuPwRx_vOlIYIGEY5bRXpnkNCoC8J4EJnRucDrgSARJvA8QQeQQL0H4mWEdGL7wlsZp_2VTC6nEMQ48Piu6Czu5ThvLggGPDbr7PEMUD2cZ0jE4SeaC040REYASq8IdXIEDMm6btSlGPuskNh3cD0AGzH2dMciFtWSjmMVuxBU59U1I6gHwcxYEV6BubWt_jQSfmA3EBiPhKLyu02cBMMiOvYIdJ3xmpGoMY1Cn__vhHnx_vEofFOIErb6nRzbD-pY49C28AOdBA5ffzLW3ss99d0A-6GxZmjsyYhgJu4tFUAa7JUl84tMbq28Tib0HW6qYo6QWw8K1HffxcTpHtwSL5Ifx0PAoGMJsGDZDD1y_r9a4vH5pjqmGrjL3RXJJUy-m4eLV5r7xMWXsxjqu3D8r04_dcw4hwwexpMT1Nwf8CTB0TKb8ElgeOpDFjYVgrqMYWP0XdhatcFtAJI7gsS-JtzsIwON9Kij66-VAkqy_z1IXI0ziyqV1yapSVYoUV1vMScRZ_nMqwiB5rEDx-XLfzko"
+        }
+      }
+      "callback":"\/post",
+      "version":1,
+      "secret":"1eaa6613699be6ebb2adcefa5379c61a3678aa0df89025470fac871431b70467",
+      "secret_sig":"eKV968b1sDkOVdSMi0tLRtOhQw4otA8yFKaVg6cA4I46_zlAQGbFptS-ODiZlSAqR7RiiZQv4E2uXCKar52dHo0vvNKbpOp_ezWYcwKRu1shvAlYytsflH5acnDWL-FKOOgz5zqLLZ6cKXFMoR1VJGG_Od-DKjSwajyV9uVzTry58Hz_w0W2pjxwQ-Xv11rab5R2O4kKSW77YzPG2R5E6Q7HN38FrLtyWD_ai3K9wlsFOpwdYC064dk66X7BZtcIbKtM6zKwMywcfJzvS5_0U5yc5GGbIY_lY6SViSfx9shOKyxkEKHfS29Ynk9ATYGnwO-jnlMqkJC7t149H-sI9hYWMkLuCzaeLP56k2B2TmtnYvE_vHNQjzVhTwuHCIRVr-p6nplQn_P3SkOpYqPi3k_tnnOLa2d3Wtga8ClEY90oLWFJC3j2UkBf_VEOBNcg-t5XO3T-j9O4Sbk96k1Qoalc-QlznbGx4bOVsGkRBBMiH4YUqiiWB_OkFHtdqv7dqGeC-u-B4u9IxzYst46vvmyA3O-Q4APSZ1RY8ITUH0jLTbh6EAV7Oki8pIbOg0t56p-8RlanOZqmFvR-grVSc7Ak1ZcD8NACmvidUpa1B7WEvRcOeffx9lype0bt5XenDnMyx6szevwxZIiM8qGM2lsSk4fu8HI9cW0mLywzZT0"
+    }
+[/code]
+
+auth_check messages MUST be encrypted with AES256CBC. This message is sent to the origination site, which checks the 'secret' to see if it is the same as the 'sec' which it passed originally. It also checks the secret_sig which is the secret signed by the destination channel's private key and base64url encoded. If everything checks out, a json packet is returned:
+[code nowrap]
+    { 
+      "success":1, 
+      "confirm":"q0Ysovd1uQRsur2xG9Tg6bC23ynzw0191SkVd7CJcYoaePy6e_v0vnmPg2xBUtIaHpx_aSuhgAkd3aVjPeaVBmts6aakT6a_yAEy7l2rBydntu2tvrHhoVqRNOmw0Q1tI6hwobk1BgK9Pm0lwOeAo8Q98BqIJxf47yO9pATa0wktOg6a7LMogC2zkkhwOV5oEqjJfeHeo27TiHr1e2WaphfCusjmk27V_FAYTzw05HvW4SPCx55EeeTJYIwDfQwjLfP4aKV-I8HQCINt-2yxJvzH7Izy9AW-7rYU0Il_gW5hrhIS5MTM12GBXLVs2Ij1CCLXIs4cO0x6e8KEIKwIjf7iAu60JPmnb_fx4QgBlF2HLw9vXMwZokor8yktESoGl1nvf5VV5GHWSIKAur3KPS2Tb0ekNh-tIk9u-xob4d9eIf6tge_d3aq1LcAtrDBDLk8AD0bho5zrVuTmZ9k-lBVPr_DRHSV_dlpu088j3ThaBsuV1olHK3vLFRhYCDIO0CqqK5IuhqtRNnRaqhlNN6fQUHpXk2SwHiJ2W36RCYMTnno6ezFk_tN-RA2ly-FomNZoC5FPA9gFwoJR7ZmVFDmUeK3bW-zYTA5vu15lpBPnt7Up_5rZKkr0WQVbhWJmylqOuwuNWbn3SrMQ8rYFZ23Tv300cOfKVgRBaePWQb4" 
+    }
+[code]
+'confirm' in this case is the base64url encoded RSA signature of the concatenation of 'secret' with the base64url encoded whirlpool hash of the source guid and guid_sig; signed with the source channel private key. This prevents a man-in-the-middle from inserting a rogue success packet. Upon receipt and successful verification of this packet, the destination site will redirect to the original destination URL and indicate a successful remote login. 
+
 [h3]Zot Structures[/h3]
 [h4]Zot Signatures[/h4]
 All signed data in Zot is accomplished by performing an RSA sign operation using the private key of the initiator. The binary result is then base64url encoded for transport.
diff --git a/doc/faq_members.bb b/doc/faq_members.bb
deleted file mode 100644
index c7f50314d..000000000
--- a/doc/faq_members.bb
+++ /dev/null
@@ -1,18 +0,0 @@
-[size=large][b]$Projectname FAQ[/b][/size]
-
-[toc]
-
-
-[h3]I am able to edit a post's text after I saved it, but is there a way to change the permissions?[/h3]
-Short anser: No, there isn't. There are reasons. You are able to change permissons to your files, photos and the likes, but not to posts after you have saved them. The main reason is: Once you have saved a post it is being distributed either to the public channel and from there to other $Projectname servers or to those you intended it to go. Just like you cannot reclaim something you gave to another person, you cannot change permissions to $Projectname posts. We would need to track everywhere your posting goes, keep track of everyone you allowed to see it and then keep track of from whom to delete it. 
-If a posting is public this is even harder, as $Projectname is a global network and there is no way to follow a post, let alone reclaim it reliably. Other networks that may receive your post have no reliable way to delete or reclaim the post.
-
-[h3]I downloaded my channel and imported it (cloned my identity) to another site but there is no content, no posts, no photos. What is wrong???[/h3]
-Posts and photos/files are provided separately from the channel basic information. This is due to memory limitations dealing with years of conversations and photo archives. Posts and conversations can be synced separately from the basic channel information. Photos and file archives can be transferred using a plugin tool such as 'redfiles', which is currently listed as "experimental".  When creating this feature we thought that keeping all your contacts was the most important task. Your friends have already seen your old content. Posts/conversations were next in priority and these may now be synced. Files and photos are the last bit to get completely working. Once we find someone willing to finish implementing this, it will be done. :)
-[h3]I can't see private resources[/h3]
-You have probably disabled third party cookies.  You need to enable them for remote authentication to work.
-[h3]There are a lot of foreign language posts. Let's auto-translate them.[/h3]
-There are also a lot of [b]private[/b] foreign language posts and auto-translation services would require us to transmit these private messages to the translation service; and we don't know what they will do with them on their servers. Actually we do know thanks to Edward Snowden. Our best bet is a project called [b][i]Apertium[/i][/b] which is an open source translator we can install locally. It is currently missing German translations - which are the most requested translation in the matrix. Once again, this will be implemented when we find somebody who really wants to make it happen. 
-
-
-#include doc/macros/main_footer.bb;
diff --git a/doc/features.bb b/doc/features.bb
deleted file mode 100644
index 578af6050..000000000
--- a/doc/features.bb
+++ /dev/null
@@ -1,211 +0,0 @@
-[b][size=20]Features[/size][/b]

-

-[b][size=24]$Projectname in a Nutshell[/size][/b]

-

-TL;DR 

-

-$Projectname provides distributed web publishing and social communications with [b]decentralised permissions[/b].

-

-So what exactly are "decentralised permissions"? They give me the ability to share something on my website (photos, media, files, webpages, etc.) with specific people on completely different websites - but not necessarily [i]everybody[/i] on those websites; and they do not need a password on my website and do not need to login to my website to view the things I've shared with them. They have one password on their own website and "magic authentication" between affiliated websites in the network. Also, as it is decentralised, there is no third party which has the ability to bypass permissions and see everything in the network.

-

-$Projectname combines many features of traditional blogs, social networking and media, content management systems, and personal cloud storage into an easy to use framework. Each node in the grid can operate standalone or link with other nodes to create a super-network; leaving privacy under the control of the original publisher. 

-

-$Projectname is an open source webserver application written originally in PHP/MySQL and is easily installable by those with basic website administration skills. It is also easily extended via plugins and themes and other third-party tools. 

-

-[b][size=24]$Projectname Features[/size][/b]

-

-

-$Projectname is a general-purpose web publishing and communication network, with several unique features.  It is designed to be used by the widest range of people on the web, from non-technical bloggers, to expert PHP programmers and seasoned systems administrators.

-

-This page lists some of the core features of $Projectname that are bundled with the official release.  As with most free and open source software, there may be many other extensions, additions, plugins, themes and configurations that are limited only by the needs and imagination of the members.

-

-[b][size=20]Built for Privacy and Freedom[/size][/b]

-

-One of the design goals of $Projectname is to enable easy communication on the web, while preserving privacy, if so desired by members. To achieve this goal, $Projectname includes a number of features allowing arbitrary levels of privacy:

-

-[b]Affinity Slider[/b]

-

-When adding connnections in $Projectname, members have the option of assigning "affinity" levels (how close your friendship is) to the new connection.  For example, when adding someone who happens to be a person whose blog you follow, you could assign their channel an affinity level of "Acquaintances". 

-

-On the other hand, when adding a friend's channel, they could be placed under the affinity level of "Friends".

-

-At this point, $Projectname [i]Affinity Slider[/i] tool, which usually appears at the top of your "Matrix" page, adjusts the content on the page to include those within the desired affinity range. Channels outside that range will not be displayed, unless you adjust the slider to include them.

-

-The Affinity Slider allows instantaneous filtering of large amounts of content, grouped by levels of closeness.

-

-[b]Connection Filtering[/b]

-

-You have the ability to control precisely what appears in your stream using the optional "Connection Filter". When enabled, the Connection Editor provides inputs for selecting criteria which needs to be matched in order to include or exclude a specific post from a specific channel. Once a post has been allowed, all comments to that post are allowed regardless of whether they match the selection criteria. You may select words that if present block the post or ensure it is included in your stream. Regular expressions may be used for even finer control, as well as hashtags or even the detected language of the post.  

-

-[b]Access Control Lists[/b]

-

-When sharing content, members have the option of restricting who sees the content.  By clicking on the padlock underneath the sharing box, one may choose desired recipients of the post, by clicking on their names.

-

-Once sent, the message will be viewable only by the sender and the selected recipients.  In other words, the message will not appear on any public walls.

-

-Access Control Lists may be applied to content and posts, photos, events, webpages, chatrooms and files. 

-

-[b]Single Sign-on[/b]

-

-Access Control Lists work for all channels in the grid due to our unique single sign-on technology. Most internal links provide an identity token which can be verified on other $Projectname sites and used to control access to private resources. You login once to your home hub. After that, authentication to all $Projectname resources is "magic".

-

-

-[b]WebDAV enabled File Storage[/b]

-

-Files may be uploaded to your personal storage area using your operating system utilities (drag and drop in most cases). You may protect these files with Access Control Lists to any combination of $Projectname members (including some third party network members) or make them public.

-

-[b]Photo Albums[/b]

-

-Store photos in albums. All your photos may be protected by Access Control Lists.

-

-[b]Events Calendar[/b]

-

-Create and manage events and tasks, which may also be protected with Access Control Lists. Events can be imported/exported to other software using the industry standard vcalendar/iCal format and shared in posts with others. Birthday events are automatically added from your friends and converted to your correct timezone so that you will know precisely when the birthday occurs - no matter where you are located in the world in relation to the birthday person. Events are normally created with attendance counters so your friends and connections can RSVP instantly. 

-

-[b]Chatrooms[/b]

-

-You may create any number of personal chatrooms and allow access via Access Control Lists. These are typically more secure than XMPP, IRC, and other Instant Messaging transports, though we also allow using these other services via plugins.       

-

-[b]Webpage Building[/b]

-

-$Projectname has many "Content Management" creation tools for building webpages, including layout editing, menus, blocks, widgets, and page/content regions. All of these may be access controlled so that the resulting pages are private to their intended audience. 

-

-[b]Apps[/b]

-

-Apps may be built and distributed by members. These are different from traditional "vendor lockin" apps because they are controlled completely by the author - who can provide access control on the destination app pages and charge accordingly for this access. Most apps in $Projectname are free and can be created easily by those with no programming skills. 

-

-[b]Layout[/b]

-

-Page layout is based on a description language called Comanche. $Projectname is itself written in Comanche layouts which you can change. This allows a level of customisation you won't typically find in so-called "multi-user environments".

-

-[b]Bookmarks[/b]

-

-Share and save/manage bookmarks from links provided in conversations.    

- 

- 

-[b]Private Message Encryption and Privacy Concerns[/b]

-

-Private mail is stored in an obscured format. While this is not bullet-proof it typically prevents casual snooping by the site administrator or ISP.  

-

-Each $Projectname channel has it's own unique set of private and associated public RSA 4096-bit keys, generated when the channels is first created. This is used to protect private messages and posts in transit.

-

-Additionally, messages may be created utilising "end-to-end encryption" which cannot be read by $Projectname operators or ISPs or anybody who does not know the passcode. 

-

-Public messages are generally not encrypted in transit or in storage.  

-

-Private messages may be retracted (unsent) although there is no guarantee the recipient hasn't read it yet.

-

-Posts and messages may be created with an expiration date, at which time they will be deleted/removed on the recipient's site.  

-

-

-[b]Service Federation[/b]

-

-In addition to addon "cross-post connectors" to a variety of alternate networks, there is native support for importation of content from RSS/Atom feeds and using this to create special channels. Also, an experimental but working implementation of the Diaspora protocol allows communication with people on the Friendica and Diaspora decentralised social networks. This is currently marked experimental because these networks do not have the same level of privacy and encryption features and abilities as $Projectname and may present privacy risks.

-

-There is also experimental support for OpenID authentication which may be used in Access Control Lists. This is a work in progress. Your $Projectname hub may be used as an OpenID provider to authenticate you to external services which use this technology. 

-

-Channels may have permissions to become "derivative channels" where two or more existing channels combine to create a new topical channel. 

-

-[b]Privacy Groups[/b]

-

-Our implementation of privacy groups is similar to Google "Circles" and Diaspora "Aspects". This allows you to filter your incoming stream by selected groups, and automatically set the outbound Access Control List to only those in that privacy group when you post. You may over-ride this at any time (prior to sending the post).  

-

-

-[b]Directory Services[/b]

-

-We provide easy access to a directory of members and provide decentralised tools capable of providing friend "suggestions". The directories are normal $Projectname sites which have chosen to accept the directory server role. This requires more resources than most typical sites so is not the default. Directories are synchronised and mirrored so that they all contain up-to-date information on the entire network (subject to normal propagation delays).  

- 

-

-[b]TLS/SSL[/b]

-

-For $Projectname hubs that use TLS/SSL, client to server communications are encrypted via TLS/SSL.  Given recent disclosures in the media regarding widespread, global surveillance and encryption circumvention by the NSA and GCHQ, it is reasonable to assume that HTTPS-protected communications may be compromised in various ways. Private communications are consequently encrypted at a higher level before sending offsite.

-

-[b]Channel Settings[/b]

-

-When a channel is created, a role is chosen which applies a number of pre-configured security and privacy settings. These are chosen for best practives to maintain privacy at the requested levels.  

-

-If you choose a "custom" privacy role, each channel allows fine-grained permissions to be set for various aspects of communication.  For example, under the "Security and Privacy Settings" heading, each aspect on the left side of the page, has six (6) possible viewing/access options, that can be selected by clicking on the dropdown menu. There are also a number of other privacy settings you may edit.  

-

-The options are:

-

- - Nobody except yourself.

- - Only those you specifically allow.

- - Anybody in your address book.

- - Anybody on this website.

- - Anybody in this network.

- - Anybody authenticated.

- - Specific people you provide a Guest Access Token to in order to access a specific item.

- - Anybody on the Internet.

-

-

-[b]Public and Private Forums[/b]

-

-Forums are typically channels which may be open to participation from multiple authors. There are currently two mechanisms to post to forums: 1) "wall-to-wall" posts and 2) via forum @mention tags. Forums can be created by anybody and used for any purpose. The directory contains an option to search for public forums. Private forums can only be posted to and often only seen by members.

-

-

-[b]Account Cloning[/b]

-

-Accounts in $Projectname are referred to as [i]nomadic identities[/i], because a member's identity is not bound to the hub where the identity was originally created.  For example, when you create a Facebook or Gmail account, it is tied to those services.  They cannot function without Facebook.com or Gmail.com.  

-

-By contrast, say you've created a $Projectname identity called [b]tina@$Projectnamehub.com[/b].  You can clone it to another $Projectname hub by choosing the same, or a different name: [b]liveForever@Some$ProjectnameHub.info[/b]

-

-Both channels are now synchronized, which means all your contacts and preferences will be duplicated on your clone.  It doesn't matter whether you send a post from your original hub, or the new hub.  Posts will be mirrored on both accounts.

-

-This is a rather revolutionary feature, if we consider some scenarios:

-

- - What happens if the hub where an identity is based suddenly goes offline?  Without cloning, a member will not be able to communicate until that hub comes back online (no doubt many of you have seen and cursed the Twitter "Fail Whale").  With cloning, you just log into your cloned account, and life goes on happily ever after. 

-

- - The administrator of your hub can no longer afford to pay for his free and public $Projectname hub. He announces that the hub will be shutting down in two weeks.  This gives you ample time to clone your identity(ies) and preserve your$Projectname relationships, friends and content.

-

- - What if your identity is subject to government censorship?  Your hub provider may be compelled to delete your account, along with any identities and associated data.  With cloning, $Projectname offers [b]censorship resistance[/b].  You can have hundreds of clones, if you wanted to, all named different, and existing on many different hubs, strewn around the internet.  

-

-$Projectname offers interesting new possibilities for privacy. You can read more at the <<Private Communications Best Practices>> page.

-

-Some caveats apply. For a full explanation of identity cloning, read the <HOW TO CLONE MY IDENTITY>.

-

-[b]Multiple Profiles[/b]

-

-Any number of profiles may be created containing different information and these may be made visible to certain of your connections/friends. A "default" profile can be seen by anybody and may contain limited information, with more information available to select groups or people. This means that the profile (and site content) your beer-drinking buddies see may be different than what your co-workers see, and also completely different from what is visible to the general public. 

-

-[b]Account Backup[/b]

-

-Red offers a simple, one-click account backup, where you can download a complete backup of your profile(s).  

-

-Backups can then be used to clone or restore a profile.

-

-[b]Account Deletion[/b]

-

-Accounts can be immediately deleted by clicking on a link. That's it.  All associated content is then deleted from the grid (this includes posts and any other content produced by the deleted profile). Depending on the number of connections you have, the process of deleting remote content could take some time but it is scheduled to happen as quickly as is practical.

-

-[b][size=20]Content Creation[/size][/b]

-

-[b]Writing Posts[/b]

-

-$Projectname supports a number of different ways of adding rich-text content. The default is a custom variant of BBcode, tailored for use in $Projectname. You may also enable the use of Markdown if you find that easier to work with. A visual editor may also be used. The traditional visual editor for $Projectname had some serious issues and has since been removed. We are currently looking for a replacement. 

-

-When creating "Websites", content may be entered in HTML, Markdown, BBcode, and/or plain text.

-

-[b]Deletion of content[/b]

-Any content created in $Projectname remains under the control of the member (or channel) that originally created it.  At any time, a member can delete a message, or a range of messages.  The deletion process ensures that the content is deleted, regardless of whether it was posted on a channel's primary (home) hub, or on another hub, where the channel was remotely authenticated via Zot ($Projectname communication and authentication protocol).

-

-[b]Media[/b]

-Similar to any other modern blogging system, social network, or a micro-blogging service, $Projectname supports the uploading of files, embedding of videos, linking web pages.

-

-[b]Previewing/Editing[/b] 

-Post can be previewed prior to sending and edited after sending.

-

-[b]Voting/Consensus[/b]

-Posts can be turned into "consensus" items which allows readers to offer feedback, which is collated into "agree", "disagree", and "abstain" counters. This lets you gauge interest for ideas and create informal surveys. 

-

-

-[b]Extending $Projectname[/b]

-

-$Projectname can be extended in a number of ways, through site customisation, personal customisation, option setting, themes, and addons/plugins. 

-

-[b]API[/b]

-

-An API is available for use by third-party services. This is based originally on the early Twitter API (for which hundreds of third-party tools exist). It is currently being extended to provide access to facilities and abilities which are specific to $Projectname. Access may be provided by login/password or OAuth and client registration of OAuth applications is provided.

-

- 

-

-#include doc/macros/main_footer.bb;

diff --git a/doc/install.bb b/doc/install.bb
deleted file mode 100644
index e68b4a230..000000000
--- a/doc/install.bb
+++ /dev/null
@@ -1,4 +0,0 @@
-#include install/INSTALL.txt;

-

-#include doc/macros/main_footer.bb;

-

diff --git a/doc/member/member_guide.bb b/doc/member/member_guide.bb
index 6edd8a0a4..58ac13178 100644
--- a/doc/member/member_guide.bb
+++ b/doc/member/member_guide.bb
@@ -471,6 +471,265 @@ Content of [code]block.json[/code]:
 	}
 [/code]
 
+[h3]Comanche Page Description Language[/h3]
+
+Comanche is a markup language similar to [url=[baseurl]/help/member/bbcode]BBcode[/url] with which to create elaborate and complex web pages by assembling them from a series of components - some of which are pre-built and others which can be defined on the fly. Comanche uses a Page Decription Language to create these pages.
+
+Comanche primarily chooses what content will appear in various regions of the page. The various regions have names and these names can change depending on what layout template you choose.
+
+[h4]Page Templates[/h4]
+Currently there are five layout templates, unless your site provides additional layouts.
+
+[dl terms="b"]
+[*= default]
+The default template defines a "nav" region across the top, "aside" as a fixed width sidebar, 
+"content" for the main content region, and "footer" for a page footer.
+
+[*= full]
+The full template defines the same as the default template with the exception that there is no "aside" region.
+
+[*= choklet]
+The choklet template provides a number of fluid layout styles which can be specified by flavour:
+[list]
+[*]	(default flavour) - a two column layout similar to the "default" template, but more fluid
+[*]	bannertwo - a two column layout with a banner region, compatible with the "default" template on small displays
+[*]	three - three column layout (adds a "right_aside" region to the default template)
+[*]	edgestwo - two column layout with fixed side margins
+[*]	edgesthree - three column layout with fixed side margins
+[*]	full - three column layout with fixed side margins and adds a "header" region beneath the navigation bar
+[/list]
+
+[*= redable]
+A template for reading longer texts full screen (so without navigation bar). Three columns: aside, content and right_aside.
+For maximum readability it is advised to only use the middle content column.
+
+[*= zen]
+Gives you the freedom to do everything yourself. Just a blank page with a content region.
+[/dl]
+
+To choose a layout template, use the 'template' tag.
+
+[code]
+	[template]full[/template]
+
+[/code]
+
+To choose the "choklet" template with the "three" flavour:
+
+[code]
+	[template=three]choklet[/template]
+
+[/code]
+
+The default template will be used if no other template is specified. The template can use any names it desires for content regions. You will be using 'region' tags to decide what content to place in the respective regions.
+
+Three "macros" have been defined for your use.
+[code]
+	$htmlhead - replaced with the site head content.
+	$nav - replaced with the site navigation bar content.
+	$content - replaced with the main page content.
+
+[/code]
+
+By default, $nav is placed in the "nav" page region and $content is placed in the "content" region. You only need to use these macros if you wish to re-arrange where these items appear, either to change the order or to move them to other regions.
+
+
+To select a theme for your page, use the 'theme' tag.
+[code]
+	[theme]suckerberg[/theme]
+
+[/code]
+This will select the theme named "suckerberg". By default your channel's preferred theme will be used.
+
+[code]
+	[theme=passion]suckerberg[/theme]
+
+[/code]
+This will select the theme named "suckerberg" and select the "passion" schema (theme variant). Alternatively it may be possible to use a condensed theme notation for this. 
+
+[code]
+	[theme]suckerberg:passion[/theme]
+
+[/code]
+
+The condensed notation isn't part of Comanche itself but is recognised by $Projectname platform as a theme specifier.
+
+[h4]Regions[/h4]
+Each region has a name, as noted above. You will specify the region of interest using a 'region' tag, which includes the name. Any content you wish placed in this region should be placed between the opening region tag and the closing tag.
+
+[code]
+	[region=htmlhead]....content goes here....[/region]
+	[region=aside]....content goes here....[/region]
+	[region=nav]....content goes here....[/region]
+	[region=content]....content goes here....[/region]
+
+[/code]
+
+[h4]CSS and Javascript[/h4]
+We have the possibility to include javascript and css libraries in the htmlhead region. At present we make use of jquery (js), bootstrap (css/js) and foundation (css/js).
+This will overwrite the selected themes htmlhead.
+
+[code]
+	[region=htmlhead]
+		[css]bootstrap[/css]
+		[js]jquery[/js]
+		[js]bootstrap[/js]
+	[/region]
+
+[/code]
+
+[h4]Menus and Blocks[/h4]
+Your webpage creation tools allow you to create menus and blocks, in addition to page content. These provide a chunk of existing content to be placed in whatever regions and whatever order you specify. Each of these has a name which you define when the menu or block is created.
+
+[code]
+	[menu]mymenu[/menu]
+
+[/code]
+This places the menu called "mymenu" at this location on the page, which must be inside a region. 
+
+[code]
+	[menu=horizontal]mymenu[/menu]
+
+[/code]
+This places the menu called "mymenu" at this location on the page, which must be inside a region. Additionally it applies the "horizontal" class to the menu. "horizontal" is defined in the redbasic theme. It may or may not be available in other themes. 
+
+[code]
+	[menu][var=wrap]none[/var]mymenu[/menu]
+
+[/code]
+The variable [var=wrap]none[/var] in a block removes the wrapping div element from the menu.
+
+[code]
+	[block]contributors[/block]
+[/code]
+This places a block named "contributors" in this region.
+
+[code]
+	[block=someclass]contributors[/block]
+
+[/code]
+This places a block named "contributors" in this region. Additionally it applies the "someclass" class to the block. This replaces the default block classes "bblock widget".
+
+[code]
+	[block][var=wrap]none[/var]contributors[/block]
+
+[/code]
+The variable [var=wrap]none[/var] in a block removes the wrapping div element from the block.
+
+[h4]Widgets[/h4]
+Widgets are executable apps provided by the system which you can place on your page. Some widgets take arguments which allows you to tailor the widget to your purpose. (TODO: list available widgets and arguments). The base system provides
+
+[code]
+	profile - widget which duplicates the profile sidebar of your channel page. This widget takes no arguments
+	tagcloud - provides a tag cloud of categories
+		count - maximum number of category tags to list	
+
+[/code]
+
+Widgets and arguments are specified with the 'widget' and 'var' tags.
+[code]
+	[widget=recent_visitors][var=count]24[/var][/widget]
+
+[/code]
+
+This loads the "recent_visitors" widget and supplies it with the argument "count" set to "24". 
+ 
+[h4]Comments[/h4]
+The 'comment' tag is used to delimit comments. These comments will not appear on the rendered page.
+
+[code]
+	[comment]This is a comment[/comment]
+
+[/code]
+
+[h4]Conditional Execution[/h4]
+You can use an 'if' construct to make decisions. These are currently based on system configuration variable or the current observer.
+
+[code]
+	[if $config.system.foo]
+		... the configuration variable system.foo evaluates to 'true'.
+	[else]
+		... the configuration variable system.foo evaluates to 'false'.
+ 	[/if]
+
+	[if $observer]
+		... this content will only be show to authenticated viewers
+	[/if]
+
+[/code]
+
+	The 'else' clause is optional. 
+
+	Several tests are supported besides boolean evaluation.
+
+[code]
+	[if $config.system.foo == bar]
+		... the configuration variable system.foo is equal to the string 'bar'
+	[/if]
+	[if $config.system.foo != bar]
+		... the configuration variable system.foo is not equal to the string 'bar'
+	[/if]
+	[if $config.system.foo {} bar ]
+		... the configuration variable system.foo is a simple array containing a value 'bar'
+	[/if]
+	[if $config.system.foo {*} bar]
+		... the configuration variable system.foo is a simple array containing a key named 'bar'
+	[/if]
+[/code]
+
+[h4]Complex Example[/h4]
+[code]
+	[comment]use an existing page template which provides a banner region plus 3 columns beneath it[/comment]
+
+	[template]3-column-with-header[/template]
+
+	[comment]Use the "darknight" theme[/comment]
+
+	[theme]darkknight[/theme]
+
+	[comment]Use the existing site navigation menu[/comment]
+
+	[region=nav]$nav[/region]
+
+	[region=side]
+
+		[comment]Use my chosen menu and a couple of widgets[/comment]
+
+		[menu]myfavouritemenu[/menu]
+
+		[widget=recent_visitors]
+			[var=count]24[/var]
+			[var=names_only]1[/var]
+		[/widget]
+
+		[widget=tagcloud][/widget]
+		[block]donate[/block]
+
+	[/region]
+
+
+
+	[region=middle]
+
+		[comment]Show the normal page content[/comment]
+
+		$content
+
+	[/region]
+
+
+
+	[region=right]
+
+		[comment]Show my condensed channel "wall" feed and allow interaction if the observer is allowed to interact[/comment]
+
+		[widget]channel[/widget]
+
+	[/region]
+
+[/code]
+
+
 [h3]Personal Cloud Storage[/h3]
 
 $Projectname provides an ability to store privately and/or share arbitrary files with friends.
diff --git a/doc/nomadic-identity.bb b/doc/nomadic-identity.bb
deleted file mode 100644
index a062e58c8..000000000
--- a/doc/nomadic-identity.bb
+++ /dev/null
@@ -1 +0,0 @@
-This still needs to be written.
diff --git a/doc/permissions.bb b/doc/permissions.bb
deleted file mode 100644
index 64690d608..000000000
--- a/doc/permissions.bb
+++ /dev/null
@@ -1,84 +0,0 @@
-[h1]Permissions[/h1]

-Permissions in $Projectname are more complete than you may be used to. This allows us to define more fine graded relationships than the black and white "this person is my friend, so they can do everything" or "this person is not my friend, so they can't do anything" permissions you may find elsewhere.

-

-[b]Permission Roles[/b]

-

-When you create a channel we allow you to select different 'roles' for that channel. These create an entire family of permissions and privacy settings that are appropriate for that role. Typical roles are "Social - mostly public", "Social - mostly private", "Forum - public" and many others. These bring a level of simplicity to managing permissions. Just choose a role and appropriate permissions are automatically applied. You can also choose 'Custom/Expert mode' and change any individual permission setting in any way you desire. 

-

-

-[b]Default Permission Limits[/b]

-

-There are a large number of individual permissions. These control everything from the ability to view your stream to the ability to chat with you. Every permission has a limit. The scope of these permissions varies from "Only me" to "Everybody on the internet" - though some scopes may not be available for some permissions. The limit applies to any published thing you create which has no privacy or access control. For example if you publish a photo and didn't select a specific audience with permission to view it, we apply the limit. These limits apply to everything within that permission rule, so you cannot apply a limit to one photo. The limit applies to all your photos. If all your photos are visible to everybody on the internet and you reduce the limit only to friends, [b]all[/b] of your photos will now be visible only to friends.

-

-[b]Access Control[/b]

- 

-Access Control is the preferred method of managing privacy in [i]most[/i] cases, rather than using permission limits. This creates lists of either connections or privacy groups (or both) and uses the access list to decide if a permission is allowed. An access list is attached to everything you publish. Unlike permission limits, if you change the access control list on a single photo, it doesn't affect any of your other photos. You can use privacy groups and a "default access control list" to create and automate the management of access control lists to provide any level of privacy you desire on anything you publish. 

-

-We highly recommend that you use the "typical social network" settings when you create your first channel, as it allows others to communicate with you and help you out if you have difficulty. You will find that these settings allow you as much privacy as you desire - when you desire it; but also allow you to communicate in public if you choose to. You are free to use much more private settings once you have learned your way around.

-

-

-[dl terms="l"]

-[*= The scopes of permissions are:]

-[dl terms="i"]

-  [*= Nobody Except Yourself ] This is self explanatory. Only you will be allowed access.

-  

-  [*= Only those you specifically allow ] By default, people you are not connected to, and all new contacts will   have this permission denied. You will be able to make exceptions for individual channels on their contact edit   screen.

-  

-  [*= Anybody in your address book ] Anybody you do not know will have this permission denied, but anybody you   accept as a contact will have this permission approved. This is the way most legacy platforms handle   permissions.

-  

-  [*= Anybody On This Hub ] Anybody with a channel on the same hub/website as you will have permission approved. Anybody who is registered at a different hub will have this permission denied.

-  

-  [*= Anybody in this network ] Anybody in $Projectname will have this permission approved. Even complete   strangers. However, anybody not logged in/authenticated will have this permission denied.

-  

-  [*= Anybody authenticated ] This is similar to "anybody in this network" except that it can include anybody   who can authenticate by any means - and therefore [i]may[/i] include visitors from other networks.

-  

-  [*=Guest Access Token] This allows you to share a file, folder, photo, album, or channel with a specific person or group of people. They don't need to be Hubzilla members. You can set an expiration for the Access Token.

-

-  [*= Anybody on the internet ] Completely public. This permission will be approved for anybody at all.

-[/dl]

-[*= The individual permissions are:]

-[dl terms="i"]

-  [*= Can view my "public" stream and posts. ] This permision determines who can view your channel "stream" that is, the non-private posts that appear on the "home" tab when you're logged in.

-

-  [*= Can view my "public" channel profile. ] This permission determines who can view your channel's profile. This refers to the "about" tab

-

-  [*= Can view my "public" photo albums. ] This permission determines who can view your photo albums. Individual photographs may still be posted to a more private audience.

-

-  [*= Can view my "public" address book. ] This permission determines who can view your contacts. These are the connections displayed in the "View connections" section.

-

-  [*= Can view my "public" file storage. ] This permission determines who can view your public files stored in your cloud.

-

-  [*= Can view my "public" pages. ] This permission determines who can view your public web pages. 

-

-  [*= Can send me their channel stream and posts. ] This permission determines whose posts you will view. If your channel is a personal channel (ie, you as a person), you would probably want to set this to "anyone in my address book" at a minimum. A personal notes channel would probably want to choose "nobody except myself". Setting this to "Anybody in the network" will show you posts from complete strangers, which is a good form of discovery.

-

-  [*= Can post on my channel page ("wall"). ] This permission determines who can write to your wall when clicking through to your channel.

-

-  [*= Can comment on my posts. ] This permission determines who can comment on posts you create. Normally, you would want this to match your "can view my public stream and posts" permission

-

-  [*= Can send me private mail messages. ] This determines who can send you private messages (zotmail).

-

-  [*= Can post photos to my photo albums. ] This determines who can post photographs in your albums. This is very useful for forum-like channels where connections may not be connected to each other.

-

-  [*= Can forward to all my channel contacts via post tags. ] Using @- mentions will reproduce a copy of your post on the profile specified, as though you posted on the channel wall. This determines if people can post to your channel in this way.

-

-  [*= Can chat with me (when available). ] This determines who can join the public chat rooms created by your channel.

-

-  [*= Can write to my "public" file storage. ] This determines who can upload files to your public file storage, or 'cloud'.

-

-  [*= Can edit my "public" pages. ] This determines who can edit your webpages. This is useful for wikis or sites with multiple editors.

-

-  [*= Can administer my channel resources. ] This determines who can have full control of your channel. This should normally be set to "nobody except myself".

-[/dl][/dl]

-[i]Note:[/i]

-Plugins/addons may provide special permission settings, so you may be offered additional permission settings beyond what is described here.

-

-If you have set any of these permissions to "only those I specifically allow", you may specify indivudal permissions on the connnection edit screen.

-

-[b]Affinity[/b]

-

-The connection edit screen offers a slider to select a degree of friendship with the connnection (this tool is enabled through the "Extra Features" tab of your Settings page). Think of this as a measure of how much you like or dislike them. 1 is for people you like, whose posts you want to see all the time. 99 is for people you don't care for, and whose posts you might only wish to look at occasionally. Once you've assigned a value here, you can use the affinity tool on the matrix page to filter content based on this number.

-

-The slider on the matrix page has both a minimum and maximum value. Posts will only be shown from people who fall between this range. Affinity has no relation to permissions, and is only useful in conjunction with the affinity tool feature.

-

-#include doc/macros/main_footer.bb;

diff --git a/doc/registration.bb b/doc/registration.bb
deleted file mode 100644
index f656eeaa6..000000000
--- a/doc/registration.bb
+++ /dev/null
@@ -1,35 +0,0 @@
-[size=large][b]Registration[/b][/size]

-

-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 activate your account, to (optionally) send email notifications for incoming messages or items, [i]and to recover lost passwords[/i].

-

-[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 [zrl=[baseurl]/help/TermsOfService]Terms of Service[/zrl]. 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.

-

-See Also

-[zrl=[baseurl]/help/accounts_profiles_channels_basics]The Basics about Identities within $Projectname[/zrl]

-[zrl=[baseurl]/help/accounts]Accounts[/zrl]

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

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

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

-

-#include doc/macros/main_footer.bb;

-

diff --git a/doc/remove_account.bb b/doc/remove_account.bb
deleted file mode 100644
index 704f0b94c..000000000
--- a/doc/remove_account.bb
+++ /dev/null
@@ -1,27 +0,0 @@
-[b]Remove Channel or Account[/b]

-

-[b]Remove Channel[/b]

-

-Go to the bottom of your channel settings page or visit the URL:

-

-	[baseurl]/removeme 

-

-You will need to confirm your password and the channel you are currently logged into will be removed. 

-

-This is irreversible.

-

-If you have identity clones on other hubs this only removes  by default the channel instance which exists on this hub.

-

-[b]Remove Account[/b]

-

-Go to the bottom of your account settings page or visit the URL:

-

-	[baseurl]/removeaccount

-	

-You will need to confirm your password and the account you are currently logged into will be removed. 

-

-This is irreversible.

-

-All your channels will be deleted. If you have identity clones on other hubs this only removes by default the channels instances which exists on this hub.

-

-#include doc/macros/main_footer.bb;

diff --git a/doc/roles.md b/doc/roles.md
deleted file mode 100644
index a7608ff90..000000000
--- a/doc/roles.md
+++ /dev/null
@@ -1,66 +0,0 @@
-Account Permission Roles
-========================
-
-
-##Social
-
-**Mostly Public**
-
-The channel is a typical social networking profile. By default posts and published items are public, but one can over-ride this when creating the item and restrict it. You are listed in the directory. Your online presence and connections are visible to others. 
-
-
-**Restricted**
-
-By default all posts and published items are sent to your 'Friends' privacy group and not made public. New friends are added to this privacy group. You can over-ride this and create a public post or published item if you desire. You are listed in the directory. Your online presence (for chat) and your connections (friends) are visible to your profile viewers.
-
-**Private**
-
-By default all posts and published items are sent to your 'Friends' privacy group. New friends are added to this privacy group. You can over-ride this and create a public post or public item if you desire. You are NOT listed in the directory. Only your connections can see your other connections. Your online presence is hidden. 
-
-
-##Forum
-
-**Mostly Public**
-
-The channel is a typical forum. By default posts and published items are public. Members may post by @mention+ or wall-to-wall post. Posting photos and other published items is blocked. The channel is visible in the directory. Members are added automatically.
-
-
-**Restricted**
-
-By default all posts and published items are sent to the channel's 'Friends' privacy group. New friends are added to this privacy group. Members may post by @mention+ or wall-to-wall post, but posts and replies may also be seen by other receipients of the top-level post who are not members. The channel is visible in the directory. Members must be manually added by the forum owner. 
-
-**Private**
-
-By default all posts and published items are sent to your 'Friends' privacy group. New friends are added to this privacy group. The owner can over-ride this and create a public post or public item if desired. Members cannot. You are NOT listed in the directory. Only your connections can see your other connections. Your online presence is hidden. Members must be manually added by the forum owner. Posting by @mention+ is disabled. Posts can only be made via wall-to-wall posts, and sent to members of the 'Friends' privacy group. They are not publicly visible.  
-
-
-##Feed
-
-
-**Public**
-
-Similiar to Social - Mostly Public, but tailored for RSS feed sources. Items may be freely republished and sourced. Online presence is meaningless, therefore hidden. New connections are automatically approved.  
-
-
-**Restricted**
-
-Not listed in directory. Online presence is meaningless, therefore hidden. Feed is published only to members of the 'Friends' privacy group. New connections are automatically added to this privacy group. Members must be manually approved by the channel owner. 
-
-
-##Special
-
-**Celebrity/Soapbox**
-
-Listed in directory. Communications are by default public. Online presence is hidden. No commenting or feedback of any form is allowed, though connections have the ability to "like" your profile. 
-
-
-**Group Repository**
-
-A public forum which allows members to post files/photos/webpages. 
-
-
-##Custom/Expert Mode
-
-Set all the privacy and permissions manually to suit your specific needs. 
-
-#include doc/macros/main_footer.bb;
diff --git a/doc/troubleshooting.bb b/doc/troubleshooting.bb
deleted file mode 100644
index 023d3c8b1..000000000
--- a/doc/troubleshooting.bb
+++ /dev/null
@@ -1,22 +0,0 @@
-[h2]Troubleshooting[/h2]

-

-When reporting issues, please try to provide as much detail as may be necessary for developers to reproduce the issue and provide the complete text of all error messages.

-

-The system logfile is an extremely useful resource for tracking down things that go wrong. This can be enabled in the admin/log configuration page. A loglevel setting of LOGGER_DEBUG is preferred for stable production sites. Most things that go wrong with communications or storage are listed here. A setting of LOGGER_DATA provides [b]much[/b] more detail, but may fill your disk. In either case we recommend the use of logrotate on your operating system to cycle logs and discard older entries. 

-

-At the bottom of your .htconfig.php file are several lines (commented out) which enable PHP error logging. This reports issues with code syntax and executing the code and is the first place you should look for issues which result in a "white screen" or blank page. This is typically the result of code/syntax problems. 

-Database errors are reported to the system logfile, but we've found it useful to have a file in your top-level directory called dbfail.out which [b]only[/b] collects database related issues. If the file exists and is writable, database errors will be logged to it as well as to the system logfile.

-

-In the case of "500" errors, the issues may often be logged in your webserver logs, often /var/log/apache2/error.log or something similar. Consult your operating system documentation. 

-

-We encourage you to try to the best of your abilities to use these logs combined with the source code in your possession to troubleshoot issues and find their cause. The community is often able to help, but only you have access to your site logfiles and it is considered a security risk to share them.   

-

-If a code issue has been uncovered, please report it on the project bugtracker (https://github.com/redmatrix/hubzilla/issues). Again provide as much detail as possible to avoid us going back and forth asking questions about your configuration or how to duplicate the problem, so that we can get right to the problem and figure out what to do about it. You are also welcome to offer your own solutions and submit patches. In fact we encourage this as we are all volunteers and have little spare time available. The more people that help, the easier the workload for everybody. It's OK if your solution isn't perfect. Every little bit helps and perhaps we can improve on it.  

-

-[h3]Troubleshooting updates[/h3]

-[ul]

-[li][zrl=[baseurl]/help/problems-following-an-update]Problems following an update[/zrl][/li]

-[/ul]

-

-#include doc/macros/main_footer.bb;

-

diff --git a/doc/webpage-element-import.md b/doc/webpage-element-import.md
deleted file mode 100644
index 4330227c2..000000000
--- a/doc/webpage-element-import.md
+++ /dev/null
@@ -1,94 +0,0 @@
-## <a href="#webpage-element-import"></a>Webpage element import
-
-There are two methods of importing webpage elements: uploading a zip file or 
-referencing a local cloud files folder. Both methods require that the webpage 
-elements are specified using a specific folder structure. The import tool makes 
-it possible to import all the elements necessary to construct an entire website
-or set of websites. The goal is to accommodate external development of webpages 
-as well as tools to simplify and automate deployment on a hub.
-
-### Folder structure
-Element definitions must be stored in the repo root under folders called 
-
-	/pages/
-	/blocks/
-	/layouts/
-
-
-Each element of these types must be defined in an individual subfolder using two files: one JSON-formatted file for the metadata and one plain text file for the element content.
-
-### Page elements
-Page element metadata is specified in a JSON-formatted file called `page.json` with the following properties:
-
- * title
- * pagelink
- * mimetype
- * layout
- * contentfile
-
-**Example** 
-
-Files: 
-	
-	/pages/my-page/page.json
-	/pages/my-page/my-page.bbcode
-	
-Content of `page.json`:
-	
-	{
-		"title": "My Page",
-		"pagelink": "mypage",
-		"mimetype": "text/bbcode",
-		"layout": "my-layout",
-		"contentfile": "my-page.bbcode"
-	}
-	
-
-### Layout elements
-Layout element metadata is specified in a JSON-formatted file called `layout.json` with the following properties:
-
- * name
- * description
- * contentfile
-
-**Example** 
-
-Files:
-
-	/layouts/my-layout/layout.json
-	/layouts/my-layout/my-layout.bbcode
-	
-Content of `layout.json`:
-	
-	{
-		"name": "my-layout",
-		"description": "Layout for my project page",
-		"contentfile": "my-layout.bbcode"
-	}
-
-
-### Block elements
-Block element metadata is specified in a JSON-formatted file called `block.json` with the following properties:
-
- * name
- * title
- * mimetype
- * contentfile
-
-**Example** 
-
-Files:
-	
-	/blocks/my-block/block.json
-	/blocks/my-block/my-block.html
-
-Content of `block.json`:	
-
-	
-	{
-		"name": "my-block",
-		"title": "",
-		"mimetype": "text/html",
-		"contentfile": "my-block.html"
-	}
-	
\ No newline at end of file
diff --git a/doc/webpages.bb b/doc/webpages.bb
deleted file mode 100644
index 2b909dc63..000000000
--- a/doc/webpages.bb
+++ /dev/null
@@ -1,93 +0,0 @@
-[b]Creating Web Pages[/b]

-

-Hubzilla enables users to create static webpages.  To activate this feature, enable the web pages feature in your Additional Features section.

-

-Once enabled, a new tab will appear on your channel page labelled &quot;Webpages&quot;.  Clicking this link will take you to the webpage editor.

-Pages will be accessible at mydomain/page/username/pagelinktitle

-

-The &quot;page link title&quot; box allows a user to specify the &quot;pagelinktitle&quot; of this URL.  If no page link title is set, we will set one for you automatically, using the message ID of the item.  

-

-Beneath the page creation box, a list of existing pages will appear with an &quot;edit&quot; link.  Clicking this will take you to an editor, similar to that of the post editor, where you can make changes to your webpages.

-

-See also: 

-

-[zrl=[baseurl]/help/webpage-element-import]Webpage element import tool[/zrl]

-

-[b]Using Blocks[/b]

-

-Blocks can be parts of webpages. The basic HTML of a block looks like this

-[code]

-	<div>

-		Block Content

-	</div>

-

-[/code]

-

-If a block has text/html content type it can also contain menu elements. Sample content of

-[code]

-	<p>HTML block content</p> 

-	[menu]menuname[/menu]

-

-[/code]

-will produce HTML like this

-[code]

-	<div>

-		<p>HTML block content</p>

-		<div>

-			<ul>

-				<li><a href="#">Link 1</a></li>

-				<li><a href="#">Link 2</a></li>

-				<li><a href="#">Link 3</a></li>

-			</ul>

-		</div>

-	</div>

-

-[/code]

-

-Via the $content macro a block can also contain the actual webpage content. For this create a block with only

-[code]

-	$content

-

-[/code]as content.

-

-To make a block appear in the webpage it must be defined in the page layout inside a region.

-[code]

-	[region=aside]

-		[block]blockname[/block]

-	[/region]

-

-[/code]

-

-The block appearance can be manipulated in the page layout.

-

-Custom classes can be assigned

-[code]

-	[region=aside]

-		[block=myclass]blockname[/block]

-	[/region]

-

-[/code]

-will produce this HTML

-[code]

-	<div class="myclass">

-		Block Content

-	</div>

-

-[/code]

-

-Via the wrap variable a block can be stripped off its wrapping <div></div> tag

-[code]

-	[region=aside]

-		[block][var=wrap]none[/var]blockname[/block]

-	[/region]

-

-[/code]

-will produce this HTML

-[code]

-	Block Content

-

-[/code]

-

-

-#include doc/macros/main_footer.bb;

-

diff --git a/doc/webpages.md b/doc/webpages.md
deleted file mode 100644
index 05c16f2bb..000000000
--- a/doc/webpages.md
+++ /dev/null
@@ -1,17 +0,0 @@
-Creating Webpages
-=================
-
-Hubzilla enables users to create static webpages.  To activate this feature, enable the web pages feature in your Additional Features section.
-
-Once enabled, a new tab will appear on your channel page labelled "Webpages".  Clicking this link will take you to the webpage editor.  Here you can create a post using either BBCode or the rich text editor.
-
-Pages will be accessible at mydomain/page/username/pagelinktitle
-
-The "page link title" box allows a user to specify the "pagelinktitle" of this URL.  If no page link title is set, we will set one for you automatically, using the message ID of the item.  
-
-Beneath the page creation box, a list of existing pages will appear with an "edit" link.  Clicking this will take you to an editor, similar to that of the post editor, where you can make changes to your webpages.
-
-If you are the admin of a site, you can specify a channel whose webpages we will use at key points around the site.  Presently, the only place this is implemented is the home page.  If you specify the channel "admin" and then the channel called "admin" creates a webpage called "home", we will display it's content on your websites home page.  We expect this functionality to be extended to other areas in future.
-
-#include doc/webpage-element-import.md;
-#include doc/macros/main_footer.bb;
diff --git a/doc/what_is_zot.bb b/doc/what_is_zot.bb
deleted file mode 100644
index 9285f4ec6..000000000
--- a/doc/what_is_zot.bb
+++ /dev/null
@@ -1,61 +0,0 @@
-[b]What is Zot?[/b]

-

-Zot is the protocol that powers $Projectname, providing three core capabilities: Communications, Identity, and Access Control.

-

-The functionality it provides can also be described as follows: 

-

- - a relationship online is just a bunch of permissions

- - the internet is just another folder

-

-[b][size=20]Communications[/size][/b]

-

-Zot is a revolutionary protocol which provides [i]decentralised communications[/i] and [i]identity management[/i] across the grid. The resulting platform can provide web services comparable to those offered by large corporate providers, but without the large corporate provider and their associated privacy issues, insatiable profit drive, and walled-garden mentality.

-

-Communications and social networking are an integral part of the grid. Any channel (and any services provided by that channel) can make full use of feature-rich social communications on a global scale. These communications may be public or private - and private communications comprise not only fully encrypted transport, but also encrypted storage to help protect against accidental snooping and disclosure by rogue system administrators and internet service providers. 

-

-Zot allows a wide array of background services in the grid, from offering friend suggestions, to directory services. You can also perform other things which would typically only be possibly on a centralized provider - such as &quot;Wall to Wall&quot; posts. Private/multiple profiles can be easily created, and web content can be tailored to the viewer via the [i]Affinity Slider[/i]. 

-

-You won't find these features at all on other decentralized communication services. In addition to providing hub (server) decentralization, perhaps the most innovative and interesting Zot feature is its provision of [i]decentralized identity[/i] services.

-

-[b][size=20]Identity[/size][/b] 

-

-Zot's identity layer is unique. It provides [i]invisible single sign-on[/i] across all sites in the grid. 

-

-It also provides [i]nomadic identity[/i], so that your communications with friends, family, and or anyone else you're communicating with won't be affected by the loss of your primary communication node - either temporarily or permanently. 

-

-The important bits of your identity and relationships can be backed up to a thumb drive, or your laptop, and may appear at any node in the grid at any time - with all your friends and preferences intact. 

-

-Crucially, these nomadic instances are kept in sync so any instance can take over if another one is compromised or damaged. This protects you against not only major system failure, but also temporary site overloads and governmental manipulation or censorship. 

-

-Nomadic identity, single sign-on, and $Projectname's decentralization of hubs, we believe, introduce a high degree of degree of [i]resiliency[/i] and [i]persistence[/i] in internet communications, that are sorely needed amidst global trends towards corporate centralization, as well as mass and indiscriminate government surveillance and censorship.

-

-As you browse the grid, viewing channels and their unique content, you are seamlessly authenticated as you go, even across completely different server hubs. No passwords to enter. Nothing to type. You're just greeted by name on every new site you visit. 

-

-How does Zot do that? We call it [i]magic-auth[/i], because $Projectname hides the details of the complexities that go into single sign-on logins, and nomadic identities, from the experience of browsing on the grid.  This is one of the design goals of $Projectname: to increase privacy, and freedom on the web, while reducing the complexity and tedium brought by the need to enter new passwords and user names for every different sight that someone might visit online.

-

-You login only once on your home hub (or any nomadic backup hub you have chosen). This allows you to access any authenticated services provided anywhere in the grid - such as shopping, blogs, forums, and access to private information. This is just like the services offered by large corporate providers with huge user databases; however you can be a member of this community, as well as a server on this network using a $35 Rasberry Pi. Your password isn't stored on a thousand different sites, or even worse, only on a few sites like Google and Facebook, beyond your direct control.

-

-You cannot be silenced. You cannot be removed from the grid, unless you yourself choose to exit it.

-

-[b][size=20]Access Control[/size][/b]

-

-Zot's identity layer allows you to provide fine-grained permissions to any content you wish to publish - and these permissions extend across $Projectname. This is like having one super huge website made up of an army of small individual websites - and where each channel in the grid can completely control their privacy and sharing preferences for any web resources they create. 

-

-Currently, the grid supports communications, photo albums, events, and files. This will be extended in the future to provide content management services (web pages) and cloud storage facilities, such as WebDAV and multi-media libraries. Every object and how it is shared and with whom is completely under your control.

-

-This type of control is available on large corporate providers such as Facebook and Google, because they own the user database. Within the grid, there is no need for a huge user databaseon your machine - because the grid [i]is[/i] your user database. It has what is essentially infinite capacity (limited by the total number of hubs online across the internet), and is spread amongst hundreds, and potentially millions of computers. 

-

-Access can be granted or denied for any resource, to any channel, or any group of channels; anywhere within the grid. Others can access your content if you permit them to do so, and they do not even need to have an account on your hub. Your private photos cannot be viewed, because permission really work; they are not an addon that was added as an afterthought. If you aren't on the list of allowed viewers for a particular photo, you aren't going to look at it. 

-

-[b][size=18]Additional Resources and Links[/size][/b]

-

-For more detailed, technical information about Zot, check out the following links: 

-

- - [url=https://github.com/friendica/red/wiki/Zot---A-High-Level-Overview]A high level overview[/url]

-

- - [url=https://github.com/friendica/red/wiki/zot]Zot development specification[/url]

-

- - [url=https://github.com/redmatrix/hubzilla/blob/master/include/zot.php]Zot reference implementation in PHP[/url]

-

-

-#include doc/macros/main_footer.bb;

diff --git a/doc/zot.md b/doc/zot.md
deleted file mode 100644
index 06c4d6083..000000000
--- a/doc/zot.md
+++ /dev/null
@@ -1,405 +0,0 @@
-Intro to Zot
-============
-
-Zot is a JSON-based web framework for implementing secure decentralised communications and services.
-
-It differs from many other communication protocols by building communications on top of a decentralised identity and authentication framework. 
-
-The authentication component is similar to OpenID conceptually but is insulated from DNS-based identities. Where possible remote authentication is silent and invisible. This provides a mechanism for internet scale distributed access control which is unobtrusive.
-
-For example,
-
-Jaquelina wishes to share photos with Roberto from her blog at "jaquelina.com.xyz", but to nobody else. Roberto maintains his own family website at "roberto.com.xyz". Zot allows Jaquelina to create an access list containing "Roberto" and allow Roberto unhindered access to the photos but without allowing Roberto's brother Marco to see the photos.
-
-Roberto will only login once to his own website at roberto.com.xyz using his password. After this, no further passwords will be asked for. Marco may also have an account on roberto.com.xyz, but he is not allowed to see Jaquelina's photos.
-
-
-Additionally, zot allows Roberto to use another site - gadfly.com.xyz, and after login to gadfly.com.xyz he can also access Jaquelina's private photos. Jaquelina does not have to do anything extra to allow this, as she has already given access rights of her private photos to Roberto - no matter what site he is logged into.  
-
-Zot also allows basic messaging and communications with anybody else on the Zot network. 
-
-In order to provide this functionality, zot creates a decentralised globally unique identifier for each node on the network. This global identifier is not linked inextricably to DNS, providing the requisite mobility. Many existing decentralised communications frameworks provide the communication aspect, but do not provide remote access control and authentication. Additionally most of these are based on 'webfinger' such that in our example, Roberto would only be recognised if he accessed Jaquelina's photos from roberto.com.xyz - but not from gadfly.com.xyz.
-
-
-The primary issues zot addresses are 
-
-* completely decentralised communications
-* insulation from DNS based identity
-* node mobility
-* invisible or reduced "interaction" remote authentication
-* high performance
-
-We will rely on DNS-based user@host addresses as a "user-friendly" mechanism to let people know where you are, specifically on a named host with a given username, and communication will be carried out to DNS entities using TCP and the web.
-
-But the underlying protocol will provide an abstraction layer on top of this, so that a communications node (e.g. "identity") can move to an alternate DNS location and (to the best of our ability) gracefully recover from site re-locations and/or maintain pre-existing communication relationships. A side effect of this requirement is the ability to communicate from alternate/multiple DNS locations and service providers and yet maintain a single online identity.
-
-We will call this overlay network the "grid". Servers attached to this network are known as "hubs" and may support any number of individual identities. 
-
-An identity does not necessarily correspond to a person. It is just something which requires the ability to communicate within the grid. 
-
-The ability to recover will be accomplished by communication to the original location when creating a new or replacement identity, or as a fallback from a stored file describing the identity and their contacts in the case where the old location no longer responds. 
-
-At least on the short term, the mobility of existing content is not a top priority. This may or may not take place at a later stage. The most important things we want to keep are your identity and your friends.  
-
-Addresses which are shared amongst people are user@host, and which describe the **current** local account credentials for a given identity. These are DNS based addresses and used as a seed to locate a given identity within the grid. The machine communications will bind this address to a globally unique ID. A single globally unique ID may be attached or bound to any number of DNS locations. Once an identity has been mapped or bound to a DNS location, communications will consist of just knowing the globally unique address, and what DNS (url) is being used currently (in order to call back and verify/complete the current communication). These concepts will be specified in better detail. 
-
-In order for an identity to persist across locations, one must be able to provide or recover 
-
-* the globally unique ID for that identity
-* the private key assigned to that identity
-* (if the original server no longer exists) an address book of contacts for that identity.
-
-This information will be exportable from the original server via API, and/or downloadable to disk or thumb-drive. 
-
-We may also attempt to recover with even less information, but doing so is prone to account hijacking and will require that your contacts confirm the change. 
-
-In order to implement high performance communications, the data transfer format for all aspects of zot is JSON. XML communications require way too much overhead.
-
-Bi-directional encryption is based on RSA 4096-bit keys expressed in DER/ASN.1 format using the PKCS#8 encoding variant, with AES-256-CBC used for block encryption of variable length or large items.
-
-Some aspects of well known "federation protocols" (webfinger, salmon, activitystreams, portablecontacts, etc.) may be used in zot, but we are not tied to them and will not be bound by them. $Projectname project is attempting some rather novel developments in decentralised communications and if there is any need to diverge from such "standard protocols" we will do so without question or hesitation. 
-
-In order to create a globally unique ID, we will base it on a whirlpool hash of the identity URL of the origination node and a psuedo-random number, which should provide us with a 256 bit ID with an extremely low probability of collision (256 bits represents approximately 115 quattuorviginitillion or 1.16 X 10^77 unique numbers). This will be represented in communications as a base64url-encoded string. We will not depend on probabilities however and the ID must also be attached to a public key with public key cryptography used to provide an assurance of identity which has not been copied or somehow collided in whirlpool hash space.
-
-Basing this ID on DNS provides a globally unique seed, which would not be the case if it was based completely on psuedo-random number generation.  
-
-We will refer to the encoded globally unique uid string as zot_uid 
-
-As there may be more than one DNS location attached/bound to a given zot_uid identity, delivery processes should deliver to all of them - as we do not know for sure which hub instance may be accessed at any given time. However we will designate one DNS location as "primary" and which will be the preferred location to view web profile information.
-
-We must also provide the ability to change the primary to a new location. A look-up of information on the current primary location may provide a "forwarding pointer" which will tell us to update our records and move everything to the new location. There is also the possibility that the primary location is defunct and no longer responding. In that case, a location which has already been mapped to this zot_uid can seize control, and declare itself to be primary. In both cases the primary designation is automatically approved and moved. A request can also be made from a primary location which requests that another location be removed. 
-
-In order to map a zot_uid to a second (or tertiary) location, we require a secure exchange which verifies that the new location is in possession of the private key for this zot_uid. Security of the private key is thus essential to avoid hijacking of identities.
-
-Communications will then require
-
-* zot_uid (string)
-* uid_sig 
-* callback (current location zot endpoint url)
-* callback_sig
-* spec (int)
-
-passed with every communique. The spec is a revision number of the applicable zot spec so that communications can be maintained with hubs using older and perhaps incompatible protocol specifications. Communications are verified using a stored public key which was copied when the connection to this zot_uid was first established. 
-
-Key revocation and replacement must take place from the primary hub. The exact form for this is still being worked out, but will likely be a notification to all other bound hubs to "phone home" (to the primary hub) and request a copy of the new key. This communique should be verified using a site or hub key; as the original identity key may have been compromised and cannot be trusted.   
-
-In order to eliminate confusion, there should be exactly one canonical url for any hub, so that these can be indexed and referenced without ambiguity. 
-
-So as to avoid ambiguity of scheme, it is strongly encouraged that all addresses to be https with a "browser valid" cert and a single valid host component (either www.domain.ext or domain.ext, but not both), which is used in all communications. Multiple URLs may be provided locally, but only one unique URL should be used for all zot communications within the grid.
-
-Test installation which do not connect to the public grid may use non-SSL, but all traffic flowing over public networks should be safe from session-hijacking, preferably with a "browser recognised" cert.
-
-Where possible, zot encourages the use of "batching" to minimise network traffic between two hubs. This means that site 'A' can send multiple messages to site 'B' in a single transaction, and also consolidate deliveries of identical messages to multiple recipients on the same hub.
-
-Messages themselves may or may not be encrypted in transit, depending on the private nature of the messages. SSL (strongly encouraged) provides unconditional encryption of the data stream, however there is little point in encrypting public communications which have been designated as having unrestricted visibility. The encryption of data storage and so-called "end-to-end encryption" is outside the scope of zot. It is presumed that hub operators will take adequate safeguards to ensure the security of their data stores and these are functions of application and site integrity as opposed to protocol integrity. 
-
-
-## Messages
-
-Given the constraints listed previously, a zot communique should therefore be a json array of individual messages. These can be mixed and combined within the same transmission.
-
-Each message then requires:
-
-* type
-* (optional) recipient list
-
-Lack of a recipient list would indicate an unencrypted public or site level message. The recipient list would contain an array of zot_uid with an individual decryption key, and a common iv. The decryption key is encoded with the recipient identity's public key. The iv is encrypted with the sender's private key.
-
-All messages should be digitally signed by the sender.    
-
-The type can be one of (this list is extensible):
-
-* post (or activity)
-* mail
-* identity
-* authenticate
-
-Identity messages have no recipients and notify the system social graph of an identity update, which could be a new or deleted identity, a new or deleted location, or a change in primary hub. The signature for these messages uses system keys as opposed to identity-specific keys.
-
-Posts include many different types of activities, such as top-level posts, likes/dislikes, comments, tagging activities, etc. These types are indicated within the message sturcture.
-
-authenticate messages result in mutual authentication and browser redirect to protected resources on the remote hub such as the ability to post wall-to-wall messages and view private photo albums and events, etc.
-
-## Discovery
-
-A well-known url is used to probe a hub for zot capabilities and identity lookups, including the discovery of public keys, profile locations, profile photos, and primary hub location. 
-
-The location for this service is /.well-known/zot-info - and must be available at the root of the chosen domain.
-
-To perform a lookup, a POST request is made to the discovery location with the following parameters:
-
-Required:
-
-address  => an address on the target system such as "john"
-
-Optional
-
-target     => the zot "guid" of the observer for evaluating permissions
-
-target_sig => an RSA signature (base64url encoded) of the guid
-
-key        => The public key needed to verify the signature
-
-token      => a string (possibly random) chosen by the requesting service. If provided, an entry in the discovered packet will be provided called 'signed_token' which consists of the base64url_encoded RSA signature of the concatenation of the string 'token.' and the provided token using the private key of the discovered channel. This can be verified using the provided 'key' entry, and provides assurance that the server is in possession of the private key for the discovered identity. After 2017-01-01 it is **required** that a server provide a signed_token *if* a token was provided in the request.  
-
-With no target provided, the permissions returned will be generic permissions 
-for unknown or unauthenticated observers
-
-Example of discovery packet for 'mike@zothub.com'
-
-	{
-
-    "success": true,
-	"signed_token": "KBJrKTq1qrctNuxF3GwVh3GAGRqmgkirlXANPcJZAeWlvSt_9TMV097slR4AYnYCBEushbVqHEJ9Rb5wHTa0HzMbfRo8cRdl2yAirvvv5d98dtwHddQgX1jB0xEypXtmIYMdPGDLvhI1RNdIBhHkkrRcNreRzoy4xD--HM6m1W0-A8PJJJ9BcNxmGPcBtLzW08wzoP9trJ3M7DQ6Gkk6j7iwVsyApw1ZBaDvabGTdc_SFV-Iegtqw3rjzT_xXWsfzMlKBy-019MYn_KS-gu23YzjvGu5tS_zDfkQb8DMUlPLz5yyxM0yOMlUDtG2qQgIJAU2O0X6T5xDdJ6mtolNyhepg845PvFDEqBQGMIH1nc47CNumeudDi8IWymEALhjG_U8KAK7JVlQTJj2EKUb0au1g6fpiBFab5mmxCMtZEX3Jreyak5GOcFFz-WpxuXJD9TdSoIvaBfBFOoJnXkg2zE4RHXeQzZ2FotmrbBG5dm8B-_6byYGoHBc08ZsWze1K96JIeRnLpBaj6ifUDcVHxZMPcGHHT27dvU2PNbgLiBjlAsxhYqkhN5qOHN8XBcg2KRjcMBaI3V0YMxlzXz5MztmZq3fcB1p-ccIoIyMPMzSj3yMB7J9CEU2LYPSTHMdPkIeDE6GaCkQKviaQQJQde346tK_YjA2k7_SOBmvPYE",
-    "guid": "sebQ-IC4rmFn9d9iu17m4BXO-kHuNutWo2ySjeV2SIW1LzksUkss12xVo3m3fykYxN5HMcc7gUZVYv26asx-Pg",
-    "guid_sig": "Llenlbl4zHo6-g4sa63MlQmTP5dRCrsPmXHHFmoCHG63BLq5CUZJRLS1vRrrr_MNxr7zob_Ykt_m5xPKe5H0_i4pDj-UdP8dPZqH2fqhhx00kuYL4YUMJ8gRr5eO17vsZQ3XxTcyKewtgeW0j7ytwMp6-hFVUx_Cq08MrXas429ZrjzaEwgTfxGnbgeQYQ0R5EXpHpEmoERnZx77VaEahftmdjAUx9R4YKAp13pGYadJOX5xnLfqofHQD8DyRHWeMJ4G1OfWPSOlXfRayrV_jhnFlZjMU7vOdQwHoCMoR5TFsRsHuzd-qepbvo3pzvQZRWnTNu6oPucgbf94p13QbalYRpBXKOxdTXJrGdESNhGvhtaZnpT9c1QVqC46jdfP0LOX2xrVdbvvG2JMWFv7XJUVjLSk_yjzY6or2VD4V6ztYcjpCi9d_WoNHruoxro_br1YO3KatySxJs-LQ7SOkQI60FpysfbphNyvYMkotwUFI59G08IGKTMu3-GPnV1wp7NOQD1yzJbGGEGSEEysmEP0SO9vnN45kp3MiqbffBGc1r4_YM4e7DPmqOGM94qksOcLOJk1HNESw2dQYWxWQTBXPfOJT6jW9_crGLMEOsZ3Jcss0XS9KzBUA2p_9osvvhUKuKXbNztqH0oZIWlg37FEVsDs_hUwUJpv2Ar09k4",
-    "key": "-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA7QCwvuEIwCHjhjbpz3Oc\ntyei/Pz9nDksNbsc44Cm8jxYGMXsTPFXDZYCcCB5rcAhPPdZSlzaPkv4vPVcMIrw\n5cdX0tvbwa3rNTng6uFE7qkt15D3YCTkwF0Y9FVZiZ2Ko+G23QeBt9wqb9dlDN1d\nuPmu9BLYXIT/JXoBwf0vjIPFM9WBi5W/EHGaiuqw7lt0qI7zDGw77yO5yehKE4cu\n7dt3SakrXphL70LGiZh2XGoLg9Gmpz98t+gvPAUEotAJxIUqnoiTA8jlxoiQjeRK\nHlJkwMOGmRNPS33awPos0kcSxAywuBbh2X3aSqUMjcbE4cGJ++/13zoa6RUZRObC\nZnaLYJxqYBh13/N8SfH7d005hecDxWnoYXeYuuMeT3a2hV0J84ztkJX5OoxIwk7S\nWmvBq4+m66usn6LNL+p5IAcs93KbvOxxrjtQrzohBXc6+elfLVSQ1Rr9g5xbgpub\npSc+hvzbB6p0tleDRzwAy9X16NI4DYiTj4nkmVjigNo9v2VPnAle5zSam86eiYLO\nt2u9YRqysMLPKevNdj3CIvst+BaGGQONlQalRdIcq8Lin+BhuX+1TBgqyav4XD9K\nd+JHMb1aBk/rFLI9/f2S3BJ1XqpbjXz7AbYlaCwKiJ836+HS8PmLKxwVOnpLMbfH\nPYM8k83Lip4bEKIyAuf02qkCAwEAAQ==\n-----END PUBLIC KEY-----\n",
-    "name": "Mike Macgirvin",
-    "name_updated": "2012-12-06 04:59:13",
-    "address": "mike@zothub.com",
-    "photo_mimetype": "image/jpeg",
-    "photo": "https://zothub.com/photo/profile/l/1",
-    "photo_updated": "2012-12-06 05:06:11",
-    "url": "https://zothub.com/channel/mike",
-    "connections_url": "https://zothub.com/poco/mike",
-    "target": "",
-    "target_sig": "",
-    "searchable": false,
-    "permissions": {
-        "view_stream": true,
-        "view_profile": true,
-        "view_photos": true,
-        "view_contacts": true,
-        "view_storage": true,
-        "view_pages": true,
-        "send_stream": false,
-        "post_wall": false,
-        "post_comments": false,
-        "post_mail": false,
-        "post_photos": false,
-        "tag_deliver": false,
-        "chat": false,
-        "write_storage": false,
-        "write_pages": false,
-        "delegate": false
-    },
-    "profile": {
-        "description": "Freedom Fighter",
-        "birthday": "0000-05-14",
-        "next_birthday": "2013-05-14 00:00:00",
-        "gender": "Male",
-        "marital": "It's complicated",
-        "sexual": "Females",
-        "locale": "",
-        "region": "",
-        "postcode": "",
-        "country": "Australia"
-    },
-    "locations": [
-        {
-            "host": "zothub.com",
-            "address": "mike@zothub.com",
-            "primary": true,
-            "url": "https://zothub.com",
-            "url_sig": "eqkB_9Z8nduBYyyhaSQPPDN1AhSm5I4R0yfcFxPeFpuu17SYk7jKD7QzvmsyahM5Kq7vDW6VE8nx8kdFYpcNaurqw0_IKI2SWg15pGrhkZfrCnM-g6A6qbCv_gKCYqXvwpSMO8SMIO2mjQItbBrramSbWClUd2yO0ZAceq3Z_zhirCK1gNm6mGRJaDOCuuTQNb6D66TF80G8kGLklv0o8gBfxQTE12Gd0ThpUb5g6_1L3eDHcsArW_RWM2XnNPi_atGNyl9bS_eLI2TYq0fuxkEdcjjYx9Ka0-Ws-lXMGpTnynQNCaSFqy-Fe1aYF7X1JJVJIO01LX6cCs-kfSoz29ywnntj1I8ueYldLB6bUtu4t7eeo__4t2CUWd2PCZkY3PKcoOrrnm3TJP5_yVFV_VpjkcBCRj3skjoCwISPcGYrXDufJxfp6bayGKwgaCO6QoLPtqqjPGLFm-fbn8sVv3fYUDGilaR3sFNxdo9mQ3utxM291XE2Pd0jGgeUtpxZSRzBuhYeOybu9DPusID320QbgNcbEbEImO8DuGIxuVRartzEXQF4WSYRdraZzbOqCzmU0O55P836JAfrWjgxTQkXlYCic-DBk-iE75JeT72smCtZ4AOtoFWCjZAABCw42J7JELY9APixZXWriKtjy6JI0G9d3fs6r7SrXr1JMy0",
-            "callback": "https://zothub.com/post",
-            "sitekey": "-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA1IWXwd/BZuevq8jzNFoR\n3VkenduQH2RpR3Wy9n4+ZDpbrUKGJddUGm/zUeWEdKMVkgyllVA/xHdB7jdyKs1X\nuIet9mIdnzvhdLO/JFD5hgbNG2wpSBIUY6aSNeCFTzszqXmuSXMW5U0Ef5pCbzEA\nnhoCoGL1KAgPqyxnGKUlj7q2aDwC9IRNtAqNyFQL67oT91vOQxuMThjlDhbR/29Q\ncYR4i1RzyahgEPCnHCPkT2GbRrkAPjNZAdlnk9UesgP16o8QB3tE2j50TVrbVc/d\nYRbzC56QMPP9UgUsapNeSJBHji75Ip/E5Eg/kfJC/HEQgyCqjCGfb7XeUaeQ7lLO\nqc7CGuMP+Jqr/cE54/aSHg8boTwxkMp11Ykb+ng17fl57MHTM2RJ99qZ1KBkXezR\nuH1lyvjzeJPxEFr9rkUqc4GH74/AgfbgaFvQc8TS7ovEa5I/7Pg04m7vLSEYc6UF\nYJYxXKrzmZT2TDoKeJzaBBx5MFLhW19l68h9dQ8hJXIpTP0hJrpI+Sr6VUAEfFQC\ndIDRiFcgjz6j7T/x8anqh63/hpsyf2PMYph1+4/fxtSCWJdvf+9jCRM8F1IDfluX\n87gm+88KBNaklYpchmGIohbjivJyru41CsSLe0uinQFvA741W00w6JrcrOAX+hkS\nRQuK1dDVwGKoIY85KtTUiMcCAwEAAQ==\n-----END PUBLIC KEY-----\n"
-        }
-    ],
-    "site": {
-        "url": "https://zothub.com",
-        "directory_mode": "primary",
-        "directory_url": "https://zothub.com/dirsearch"
-    }
-
-	}
-
-
-
-Discovery returns a JSON array with the following components:
-
-'success' => ('1' or '')  Operation was successful if '1'. Otherwise an optional 'message' may be present indicating the source of error.
-
-'signed_token' => If a token parameter was provided in the request, it is prepended with the text 'token.' and then RSA signed with the channel private key and base64url encoded and returned as 'signed_token'.
-
-'guid' => the guid of the address on the target system
-
-'guid_sig' => the base64url encoded RSA signature of the guid, signed with the private key associated with that guid.
-
-'key' => the public key associated with that guid
-
-'name' => channel name
-
-'name_updated' => MySQL style timestamp '2012-01-01 00:00:00' when the name was last changed (UTC)
-
-'address' => "webbie" or user@host address associated with this channel
-
-'photo' => URL of a profile photo for this channel (ideally 175x175)
-
-'photo_mimetype' => content-type of the profile photo
-
-'photo_updated' => MySQL style timestamp when photo was last updated (UTC)  
-
-'url' => location of channel homepage
-
-'connections_url' => location of Portable Contacts (extended for zot) URL for this channel
-
-'target' => if a permissions target was specified, it is mirrored
-
-'target_sig' => if a permissions target was specified, the signature is mirrored.
-    
-'searchable' => ('1' or '') '1' indicates this entry can be searched in a directory
-
-###Permissions
-
-
-'permisssions' => extensible array of permissions appropriate to this target, values are '1' or ''
-
-  Permissions may include:
-
-* view_stream
-
-* view_profile
-
-* view_photos
-
-* view_contacts
-
-* view_storage
-
-* view_pages
-
-* send_stream
-
-* post_wall
-
-* post_comments
-
-* post_mail
-
-* post_photos
-
-* tag_deliver
-
-* chat
-
-* write_storage
-
-* write_pages
-
-* delegate
-
-
-
-###Profile
-
-
-'profile' => array of important profile fields
-
-* description
-
-* birthday YYYY-MM-DD , all fields are optional, any field (such as year) may be zero
-
-* next_birthday => MySQL datetime string representing the next upcoming birthday, converted from the channel's default timezone to UTC. 
-
-* gender (free form)
-
-* marital (marital status)
-
-* sexual (preference)
-
-* locale (city)
-
-* region (state)
-
-* postcode
-
-* country
-
-
-###Locations
-
-
-'locations' => array of registered locations (DNS locations) this channel may be visible or may be posting from
-
-Each location is an array of
-
-'host' => DNS hostname, e.g. example.com
-
-'address' => the webbie or user@host identifier associated with this location
-
-'primary' => ('1' or '') whether or not this is the primary location for this channel where files and web pages are generally found
-
-'url' => url of the root of this DNS location e.g. https://example.com
-
-'url_sig' => base64url encoded RSA signature of the URL, signed with the channel private key
-
-'callback' => zot communications endpoint on this site, usually https://example.com/post
-
-'sitekey' => public key of this site/host
-
-
-###Site
-
-
-'site' => array providing the directory role of the site responding to this request
-
-'url' => url of this site e.g. https://example.com
-
-'directory_mode' => one of 'primary', 'secondary', 'normal', or 'standalone'
-
-'directory_url' => if this is a directory server or standalone, the URL for the directory search module
-
-
-
-Magic Auth
-==========
-
-
-So-called "magic auth" takes place by a special exchange. On the remote computer, a redirection is made to the zot endpoint with special GET parameters.
-
-Endpoint: https://example.com/post/name
-
-where 'name' is the left hand side of the channel webbie, for instance 'mike' where the webbie is 'mike@zothub.com'
-
-Additionally four parameters are supplied:
-
-* auth => the webbie of the person requesting access
-* dest => the desired destination URL (urlencoded)
-* sec  => a random string which is also stored locally for use during the verification phase. 
-* version => the zot revision
-
-When this packet is received, a zot message is initiated to the auth identity:
-
-
-    {
-      "type":"auth_check",
-      "sender":{
-        "guid":"kgVFf_1_SSbyqH-BNWjWuhAvJ2EhQBTUdw-Q1LwwssAntr8KTBgBSzNVzUm9_RwuDpxI6X8me_QQhZMf7RfjdA",
-        "guid_sig":"PT9-TApzpm7QtMxC63MjtdK2nUyxNI0tUoWlOYTFGke3kNdtxSzSvDV4uzq_7SSBtlrNnVMAFx2_1FDgyKawmqVtRPmT7QSXrKOL2oPzL8Hu_nnVVTs_0YOLQJJ0GYACOOK-R5874WuXLEept5-KYg0uShifsvhHnxnPIlDM9lWuZ1hSJTrk3NN9Ds6AKpyNRqf3DUdz81-Xvs8I2kj6y5vfFtm-FPKAqu77XP05r74vGaWbqb1r8zpWC7zxXakVVOHHC4plG6rLINjQzvdSFKCQb5R_xtGsPPfvuE24bv4fvN4ZG2ILvb6X4Dly37WW_HXBqBnUs24mngoTxFaPgNmz1nDQNYQu91-ekX4-BNaovjDx4tP379qIG3-NygHTjFoOMDVUvs-pOPi1kfaoMjmYF2mdZAmVYS2nNLWxbeUymkHXF8lT_iVsJSzyaRFJS1Iqn7zbvwH1iUBjD_pB9EmtNmnUraKrCU9eHES27xTwD-yaaH_GHNc1XwXNbhWJaPFAm35U8ki1Le4WbUVRluFx0qwVqlEF3ieGO84PMidrp51FPm83B_oGt80xpvf6P8Ht5WvVpytjMU8UG7-js8hAzWQeYiK05YTXk-78xg0AO6NoNe_RSRk05zYpF6KlA2yQ_My79rZBv9GFt4kUfIxNjd9OiV1wXdidO7Iaq_Q",
-        "url":"http:\/\/podunk.edu",
-        "url_sig":"T8Bp7j5DHHhQDCFcAHXfuhUfGk2P3inPbImwaXXF1xJd3TGgluoXyyKDx6WDm07x0hqbupoAoZB1qBP3_WfvWiJVAK4N1FD77EOYttUEHZ7L43xy5PCpojJQmkppGbPJc2jnTIc_F1vvGvw5fv8gBWZvPqTdb6LWF6FLrzwesZpi7j2rsioZ3wyUkqb5TDZaNNeWQrIEYXrEnWkRI_qTSOzx0dRTsGO6SpU1fPWuOOYMZG8Nh18nay0kLpxReuHCiCdxjXRVvk5k9rkcMbDBJcBovhiSioPKv_yJxcZVBATw3z3TTE95kGi4wxCEenxwhSpvouwa5b0hT7NS4Ay70QaxoKiLb3ZjhZaUUn4igCyZM0h6fllR5I6J_sAQxiMYD0v5ouIlb0u8YVMni93j3zlqMWdDUZ4WgTI7NNbo8ug9NQDHd92TPmSE1TytPTgya3tsFMzwyq0LZ0b-g-zSXWIES__jKQ7vAtIs9EwlPxqJXEDDniZ2AJ6biXRYgE2Kd6W_nmI7w31igwQTms3ecXe5ENI3ckEPUAq__llNnND7mxp5ZrdXzd5HHU9slXwDShYcW3yDeQLEwAVomTGSFpBrCX8W77n9hF3JClkWaeS4QcZ3xUtsSS81yLrp__ifFfQqx9_Be89WVyIOoF4oydr08EkZ8zwlAsbZLG7eLXY"
-      },
-      "recipients":{
-        {
-        "guid":"ZHSqb3yGar3TYV_o9S-JkD-6o_V4DhUcxtv0VeyX8Kj_ENHPI_M3SyAUucU835-mIayGMmTpqJz3ujPkcavVhA",
-        "guid_sig":"JsAAXigNghTkkbq8beGMJjj9LBKZn28hZ-pHSsoQuwYWvBJ2lSnfc4r9l--WgO6sucH-SR6RiBo78eWn1cZrh_cRMu3x3LLx4y-tjixg-oOOgtZakkBg4vmOhkKPkci0mFtzvUrpY4YHySqsWTuPwRx_vOlIYIGEY5bRXpnkNCoC8J4EJnRucDrgSARJvA8QQeQQL0H4mWEdGL7wlsZp_2VTC6nEMQ48Piu6Czu5ThvLggGPDbr7PEMUD2cZ0jE4SeaC040REYASq8IdXIEDMm6btSlGPuskNh3cD0AGzH2dMciFtWSjmMVuxBU59U1I6gHwcxYEV6BubWt_jQSfmA3EBiPhKLyu02cBMMiOvYIdJ3xmpGoMY1Cn__vhHnx_vEofFOIErb6nRzbD-pY49C28AOdBA5ffzLW3ss99d0A-6GxZmjsyYhgJu4tFUAa7JUl84tMbq28Tib0HW6qYo6QWw8K1HffxcTpHtwSL5Ifx0PAoGMJsGDZDD1y_r9a4vH5pjqmGrjL3RXJJUy-m4eLV5r7xMWXsxjqu3D8r04_dcw4hwwexpMT1Nwf8CTB0TKb8ElgeOpDFjYVgrqMYWP0XdhatcFtAJI7gsS-JtzsIwON9Kij66-VAkqy_z1IXI0ziyqV1yapSVYoUV1vMScRZ_nMqwiB5rEDx-XLfzko"
-        }
-      }
-      "callback":"\/post",
-      "version":1,
-      "secret":"1eaa6613699be6ebb2adcefa5379c61a3678aa0df89025470fac871431b70467",
-      "secret_sig":"eKV968b1sDkOVdSMi0tLRtOhQw4otA8yFKaVg6cA4I46_zlAQGbFptS-ODiZlSAqR7RiiZQv4E2uXCKar52dHo0vvNKbpOp_ezWYcwKRu1shvAlYytsflH5acnDWL-FKOOgz5zqLLZ6cKXFMoR1VJGG_Od-DKjSwajyV9uVzTry58Hz_w0W2pjxwQ-Xv11rab5R2O4kKSW77YzPG2R5E6Q7HN38FrLtyWD_ai3K9wlsFOpwdYC064dk66X7BZtcIbKtM6zKwMywcfJzvS5_0U5yc5GGbIY_lY6SViSfx9shOKyxkEKHfS29Ynk9ATYGnwO-jnlMqkJC7t149H-sI9hYWMkLuCzaeLP56k2B2TmtnYvE_vHNQjzVhTwuHCIRVr-p6nplQn_P3SkOpYqPi3k_tnnOLa2d3Wtga8ClEY90oLWFJC3j2UkBf_VEOBNcg-t5XO3T-j9O4Sbk96k1Qoalc-QlznbGx4bOVsGkRBBMiH4YUqiiWB_OkFHtdqv7dqGeC-u-B4u9IxzYst46vvmyA3O-Q4APSZ1RY8ITUH0jLTbh6EAV7Oki8pIbOg0t56p-8RlanOZqmFvR-grVSc7Ak1ZcD8NACmvidUpa1B7WEvRcOeffx9lype0bt5XenDnMyx6szevwxZIiM8qGM2lsSk4fu8HI9cW0mLywzZT0"
-    }
-
-
-auth_check messages MUST be encrypted with AES256CBC. This message is sent to the origination site, which checks the 'secret' to see if it is the same as the 'sec' which it passed originally. It also checks the secret_sig which is the secret signed by the destination channel's private key and base64url encoded. If everything checks out, a json packet is returned:
-
-    { 
-      "success":1, 
-      "confirm":"q0Ysovd1uQRsur2xG9Tg6bC23ynzw0191SkVd7CJcYoaePy6e_v0vnmPg2xBUtIaHpx_aSuhgAkd3aVjPeaVBmts6aakT6a_yAEy7l2rBydntu2tvrHhoVqRNOmw0Q1tI6hwobk1BgK9Pm0lwOeAo8Q98BqIJxf47yO9pATa0wktOg6a7LMogC2zkkhwOV5oEqjJfeHeo27TiHr1e2WaphfCusjmk27V_FAYTzw05HvW4SPCx55EeeTJYIwDfQwjLfP4aKV-I8HQCINt-2yxJvzH7Izy9AW-7rYU0Il_gW5hrhIS5MTM12GBXLVs2Ij1CCLXIs4cO0x6e8KEIKwIjf7iAu60JPmnb_fx4QgBlF2HLw9vXMwZokor8yktESoGl1nvf5VV5GHWSIKAur3KPS2Tb0ekNh-tIk9u-xob4d9eIf6tge_d3aq1LcAtrDBDLk8AD0bho5zrVuTmZ9k-lBVPr_DRHSV_dlpu088j3ThaBsuV1olHK3vLFRhYCDIO0CqqK5IuhqtRNnRaqhlNN6fQUHpXk2SwHiJ2W36RCYMTnno6ezFk_tN-RA2ly-FomNZoC5FPA9gFwoJR7ZmVFDmUeK3bW-zYTA5vu15lpBPnt7Up_5rZKkr0WQVbhWJmylqOuwuNWbn3SrMQ8rYFZ23Tv300cOfKVgRBaePWQb4" 
-    }
-
-'confirm' in this case is the base64url encoded RSA signature of the concatenation of 'secret' with the base64url encoded whirlpool hash of the source guid and guid_sig; signed with the source channel private key. This prevents a man-in-the-middle from inserting a rogue success packet. Upon receipt and successful verification of this packet, the destination site will redirect to the original destination URL and indicate a successful remote login. 
-   
-#include doc/macros/main_footer.bb;
diff --git a/doc/zot_structures.md b/doc/zot_structures.md
deleted file mode 100644
index e8a65ff1f..000000000
--- a/doc/zot_structures.md
+++ /dev/null
@@ -1,62 +0,0 @@
-Zot Structures
-==============
-
-**Zot signatures**
-All signed data in zot is accomplished by performing an RSA sign operation using the private key of the initiator. The binary result is then base64url encoded for transport.
-
-**Zot encryption**
-
-Encryption is currently provided by AES256CBC, though additional algorithms MAY be supported. A 32-octet key and 16-octet initialisation vector are randomly generated. The desired data is then encrypted using these generated strings and the result base64url encoded. Then we build an array:
-
-    data: the base64url encoded encrypted data
-    alg: The chosen algorithm, in this case the string 'aes256cbc'.
-    key: The randomly generated key, RSA encrypted using the recipients public key, and the result base64url encoded
-    iv: The randomly generated IV, RDSA encrypted using the recipient's public key, and the result base64url encoded
-
-
-
-**The zot basic packet**
-
-Used for initiating a dialogue with another zot site. This packet MAY be encrypted. The presence of an array element 'iv' indicates encryption has been applied. When sending an 'auth_check' packet type, this packet MUST be encrypted, using the public key of the destination site (the site key, as opposed to a sender key).  
-
-
-    {
-      "type":"notify",
-      "sender":{
-        "guid":"kgVFf_1_SSbyqH-BNWjWuhAvJ2EhQBTUdw-Q1LwwssAntr8KTBgBSzNVzUm9_RwuDpxI6X8me_QQhZMf7RfjdA",
-        "guid_sig":"PT9-TApzpm7QtMxC63MjtdK2nUyxNI0tUoWlOYTFGke3kNdtxSzSvDV4uzq_7SSBtlrNnVMAFx2_1FDgyKawmqVtRPmT7QSXrKOL2oPzL8Hu_nnVVTs_0YOLQJJ0GYACOOK-R5874WuXLEept5-KYg0uShifsvhHnxnPIlDM9lWuZ1hSJTrk3NN9Ds6AKpyNRqf3DUdz81-Xvs8I2kj6y5vfFtm-FPKAqu77XP05r74vGaWbqb1r8zpWC7zxXakVVOHHC4plG6rLINjQzvdSFKCQb5R_xtGsPPfvuE24bv4fvN4ZG2ILvb6X4Dly37WW_HXBqBnUs24mngoTxFaPgNmz1nDQNYQu91-ekX4-BNaovjDx4tP379qIG3-NygHTjFoOMDVUvs-pOPi1kfaoMjmYF2mdZAmVYS2nNLWxbeUymkHXF8lT_iVsJSzyaRFJS1Iqn7zbvwH1iUBjD_pB9EmtNmnUraKrCU9eHES27xTwD-yaaH_GHNc1XwXNbhWJaPFAm35U8ki1Le4WbUVRluFx0qwVqlEF3ieGO84PMidrp51FPm83B_oGt80xpvf6P8Ht5WvVpytjMU8UG7-js8hAzWQeYiK05YTXk-78xg0AO6NoNe_RSRk05zYpF6KlA2yQ_My79rZBv9GFt4kUfIxNjd9OiV1wXdidO7Iaq_Q",
-        "url":"http:\/\/podunk.edu",
-        "url_sig":"T8Bp7j5DHHhQDCFcAHXfuhUfGk2P3inPbImwaXXF1xJd3TGgluoXyyKDx6WDm07x0hqbupoAoZB1qBP3_WfvWiJVAK4N1FD77EOYttUEHZ7L43xy5PCpojJQmkppGbPJc2jnTIc_F1vvGvw5fv8gBWZvPqTdb6LWF6FLrzwesZpi7j2rsioZ3wyUkqb5TDZaNNeWQrIEYXrEnWkRI_qTSOzx0dRTsGO6SpU1fPWuOOYMZG8Nh18nay0kLpxReuHCiCdxjXRVvk5k9rkcMbDBJcBovhiSioPKv_yJxcZVBATw3z3TTE95kGi4wxCEenxwhSpvouwa5b0hT7NS4Ay70QaxoKiLb3ZjhZaUUn4igCyZM0h6fllR5I6J_sAQxiMYD0v5ouIlb0u8YVMni93j3zlqMWdDUZ4WgTI7NNbo8ug9NQDHd92TPmSE1TytPTgya3tsFMzwyq0LZ0b-g-zSXWIES__jKQ7vAtIs9EwlPxqJXEDDniZ2AJ6biXRYgE2Kd6W_nmI7w31igwQTms3ecXe5ENI3ckEPUAq__llNnND7mxp5ZrdXzd5HHU9slXwDShYcW3yDeQLEwAVomTGSFpBrCX8W77n9hF3JClkWaeS4QcZ3xUtsSS81yLrp__ifFfQqx9_Be89WVyIOoF4oydr08EkZ8zwlAsbZLG7eLXY"
-      },
-      "callback":"\/post",
-      "version":1,
-      "secret":"1eaa6613699be6ebb2adcefa5379c61a3678aa0df89025470fac871431b70467",
-      "secret_sig":"0uShifsvhHnxnPIlDM9lWuZ1hSJTrk3NN9Ds6AKpyNRqf3DUdz81-Xvs8I2kj6y5vfFtm-FPKAqu77XP05r74vGaWbqb1r8zpWC7zxXakVVOHHC4plG6rLINjQzvdSFKCQb5R_xtGsPPfvuE24bv4fvN4ZG2ILvb6X4Dly37WW_HXBqBnUs24mngoTxFaPgNmz1nDQNYQu91-ekX4-BNaovjDx4tP379qIG3-NygHTjFoOMDVUvs-pOPi1kfaoMjmYF2mdZAmVYS2nNLWxbeUymkHXF8lT_iVsJSzyaRFJS1Iqn7zbvwH1iUBjD_pB9EmtNmnUraKrCU9eHES27xTwD-yaaH_GHNc1XwXNbhWJaPFAm35U8ki1Le4WbUVRluFx0qwVqlEF3ieGO84PMidrp51FPm83B_oGt80xpvf6P8Ht5WvVpytjMU8UG7-js8hAzWQeYiK05YTXk-78xg0AO6NoNe_RSRk05zYpF6KlA2yQ_My79rZBv9GFt4kUfIxNjd9OiV1wXdidO7Iaq_Q"
-    }
-
-
-Type: is the message type. One of 'notify', 'purge' refresh' 'force_refresh', 'auth_check', 'ping' or 'pickup'. The packet contents vary by message type. Here we will describe the 'notify' packet. 
-
-Sender is an array of four components. 
-
-The guid of the sender is typically a 64 character base64url encoded string. This is generated when an identity is created and an attempt is made that it be unique; though this isn't required.
-
-The guid_sig is the RSA signature of the guid, signed by the sender's private key.
-
-url is the base url of the location this post is originating from.
-
-url_sig is the RSA signature of url, signed by the sender's private key.
-
-
-These four elements provide a portable identity. We can contact the URL provided and download a zot info packet to obtain the public key of the sender, and use that to verify the sender guid and the posting URL signatures. 
-
-
-callback is a string to be appended onto the url which identifies the zot communications endpoint on this system. It is typically the string "/post".
-
-version is the zot protocol identifier, to allow future protocol revisions to co-exist. 
-
-secret is a 64-char string which is randomly generated by the sending site.
-
-secret_sig is the RSA signature of the secret, signed with the sender's private key. 
-
-#include doc/macros/main_footer.bb;