suggestion widget tweaked to make it comanche capable. Remove old versions of specs that are so obsolete it isn't funny. Zot protocol reference is in red's github wiki, and in the code. We should move the github copy to /doc once it is updated to match the code. There's no point in documenting dfrn in the red code base.

5 files changed, 0 insertions, 406 deletions

diff --git a/spec/dfrn-snap2.jpg b/spec/dfrn-snap2.jpg
deleted file mode 100644
index ee00f5654..000000000
--- a/spec/dfrn-snap2.jpg
+++ /dev/null
diff --git a/spec/dfrn2.odt b/spec/dfrn2.odt
deleted file mode 100644
index 390fc4bb8..000000000
--- a/spec/dfrn2.odt
+++ /dev/null
diff --git a/spec/dfrn2.pdf b/spec/dfrn2.pdf
deleted file mode 100644
index e46225f7e..000000000
--- a/spec/dfrn2.pdf
+++ /dev/null
diff --git a/spec/zot-2012.txt b/spec/zot-2012.txt
deleted file mode 100644
index d01af5c87..000000000
--- a/spec/zot-2012.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-
-Initial cut at Zot-2012 protocol. This is a very rough draft of some very rough ideas and concepts. 
-It is not yet intended to be a definitive specification and many things like the security handshakes are yet to be specified precisely. 
-
-All communications are https
-
-
-First create a global unique channel and assign a location
-
-Site id is 'https://macgirvin.com'
-Site channel-id is 'https://macgirvin.com/channel/1'
-
-$guid = base64url_encode(hash('whirlpool','https://macgirvin.com/channel/1.' . mt_rand(1000000,9999999),1);
-
-$guid_sig = base64_urlencode(rsa_sign($guid,$myprivatekey));
-
-$location = Site id
-$location_sig = base64_urlencode(rsa_sign($location,$myprivatekey));
-
-
-This information will identify a channel+site pair in the future. When contact is made initially, a lookup is performed to a well known URL at this site to verify the signatures of both the guid and the site. After this information has been verified, it is stored and we can use them to uniquely identify a channel/location pair in the future. 
-
-If a new location is provided, this process is repeated but only the new location needs to be verified and stored.
-
-Messages are sent by providing this information in an HTTP post (*) to the other site, along with a protocol version specifier and type of message and a verification token. For message types which do not require identity validation, the message may be included. Others will require a security handshake with the remote site calling back the original to verify the identity assertion and the message is only collected at that time. 
-
-Multiple messages may be sent, and a callback may  result in the collection of multiple messages destined for this site, not necessarily limited to the channel/location which was asserted. 
- 
-
-(*) A POST method is used for many protocol transactions as site "hardening" tools may place overly restrictive length limits on GET data. We are typically sending several encoded/encrypted strings and these requests are likely to fail on some sites and become a nagging support issue if a GET request is used.
-
-The verification token is signed by the remote site and the signed token returned during the callback. This verifies the identity of the callback - by matching with known tokens. 
-
-
-Permissions:
-
-Permissions are available for several different activities. This list is enumerated by a POST to the permissions service with the above channel+location information. An array of permissions will be returned. If no identity assertion is made, a list of the default channel permissions is returned. 
-
-
-
-
-
-
-
diff --git a/spec/zot.txt b/spec/zot.txt
deleted file mode 100644
index 2c3bbb180..000000000
--- a/spec/zot.txt
+++ /dev/null
@@ -1,362 +0,0 @@
-This is the Zot! social communications protocol. 
-
-Specification revision: 1
-2 October 2011
-
-Mike Macgirvin
-This specification is public domain.
-
-Zot is a framework for secure delivery of messages on the web based on 
-webfinger and encapsulating salmon.
-
-First read the salmon and salmon magic envelope specifications. Zot also 
-makes use of webfinger and ActivityStreams and several concepts from RFC822
-(email). Zot encompasses the zot delivery framework and the zid remote
-access protocol.
-
-The current specification revision (1) is frozen until a reference 
-implementation is available. After that, any protocol changes will require a 
-change to the revision number.  
-
-****************
-* Zot delivery *
-****************
-
-Format of a zot wrapper. This completely encapsulates a salmon magic envelope 
-and provides privacy protection, while defining a delivery envelope - a 
-concept familiar to email systems. All addresses in zot are webfinger 
-resolvable addresses containing zot endpoints and salmon public keys (zot 
-is a superset of salmon). 
-
-
-<?xml version='1.0' encoding='UTF-8'?>
-<zot:msg xmlns:zot='http://purl.org/zot/1.0'>
- <zot:key>((key))</zot:key>
- <zot:iv>((iv))</zot:iv>
- <zot:env_key>((env_key))</zot:env_key>
- <zot:env_iv>((env_iv))</zot:env_iv>
- <zot:env>((envelope))</zot:env>
- <zot:sig key_id="xxx">((sender signature))</zot:sig>
- <zot:alg>AES-256-CBC</zot:alg>
- <zot:data type='application/magic-envelope+xml'>((salmon))</zot:data>
-</zot:msg>
-
-
-zot:key
-*******
-
-A suitable randomly generated encyption key of length 32 octets for encrypting 
-the salmon packet. This is then encrypted with the sender's private key and 
-base64url encoded.
-
-zot:iv
-******
-
-A suitable randomly generated initialisation vector of length 16 octets for 
-encrypting the salmon packet. This is then encrypted with the sender's private 
-key and base64url encoded.
-
-zot:env_key
-***********
-
-A suitable randomly generated encyption key of length 32 octets for encrypting 
-the envelope. This is then encrypted with the recipient's public key and 
-base64url encoded. For bulk deliveries, it is encrypted with the site bulk 
-delivery public key.
-
-
-zot:env_iv
-**********
-
-A suitable randomly generated initialisation vector of length 16 octets for 
-encrypting the envelope. This is then encrypted with the recipient's public
-key and base64url encoded. For bulk deliveries, it is encrypted with the site 
-bulk delivery public key.
-
-
-zot:env
-*******
-
-This consists of RFC822-style header fields representing the sender and 
-recipient(s). Line lengths have no defined limit and RFC822 continuation
-lines are not supported. If an inbound server is not able to process an
-envelope or post due to size constraints, it SHOULD return a 
-"413 Entity too large" HTTP response. 
-
-Example:
-
-Z-From: zot:bob@example.com
-Z-Sender: zot:bob@example.com
-Z-To: zot:alice@example.com
-
-Both "Z-From:" and "Z-Sender:" MUST be provided, and represent a single 
-webfinger address of the author and sender respectively. The webfinger
-address for the From address MUST contain a discoverable salmon public key 
-which is needed to verify the enclosed salmon data. Sender is used to indicate
-the webfinger identity responsible for transmitting this message. From
-indicates the message author. 
-
-In web-based social systems, a reply to a message SHOULD be conveyed to all of 
-the original message participants. Only the author of the original message 
-may know all the recipients (such as those contained in Bcc: elements). The 
-author of a message always provides 'From'. They MUST duplicate this 
-information as 'Sender' when posting a followup message.
-
-A reply to a given message MUST be sent to the From address of the original
-post, and MAY be sent to any additional addresses in the recipient list. The
-original post author MUST send the reply to all known recipients of the 
-original message, with their webfinger identity as Sender, and the 
-comment/reply author as From.   
-
-Receiving agents SHOULD validate the From identity as the signer of the salmon
-magic envelope, and MAY reject it. They SHOULD also verify the Sender signature
-of the zot packet if it is different than the salmon signature. They MAY 
-reject the message if the Sender is not allowed in their "friend list", or if 
-they do not have a suitable relationship with the Sender, or if either
-signature fails to validate. Rejected messages for one of these reasons SHOULD 
-be indicated with a "400 Bad Request" HTTP response.   
-
-
-Z-To: *
-
-indicates a public message with no specifically enumerated recipients.
-
-The fields Z-To: and/or Z-Bcc: MAY be present. At least one recipient field
-MUST be present.
-
-Z-To: zot:bob@example.com, zot:alice@example.com, mailto:dave@example.com 
-Z-Bcc: zot:https://example.com/profile/richard
-
-are valid entries. Adresses are comma separated and individual entries MUST NOT
-contain commas. There MAY be any number of ASCII space characters between
-entries for legibility. Header lines are terminated with a linefeed character
-(ASCII 0x0A). 
-
-This specification provides the following protocol address prefixes
-for use in Z-To: or Z-Bcc: elements:
-
-zot: - normal zot delivery using webfinger or LRDD resolvable address
-dfrn: - legacy DFRN mode delivery using webfinger or LRDD resovable address
-ostatus: - normal OStatus delivery using webfinger or LRDD resovable address
-diaspora: - Diaspora network delivery using webfinger address
-facebook: - Facebook profile page URL
-twitter: - Twitter personal page URL without AJAX '#!' fragment
-mailto: - email RFC822/ESMTP address
-
-Examples:
-
-twitter:http://twitter.com/bjensen
-facebook:http://facebook.com/profile.php?id=000000001
-
-Foreign protocol addresses which have not been defined in this specification 
-or future revisions of this specification and which are unknown to the
-recipient delivery process MAY be ignored.
-
-In cases where an address may contain either a webfinger or LRDD address, the
-webfinger address SHOULD be used preferentially. 
-
-
-Z-Bcc:
-******
-
-The Z-Bcc element may contain one or more addresses which are hidden from end
-user presentation. A zot receiving system MUST NOT store or allow for
-the display of the Bcc information. Implementations which require extreme
-privacy SHOULD send individual posts to each of the Bcc: recipients containing
-only a single address. They MAY send all Bcc: posts using bulk delivery, 
-however this may have privacy implications as there is no guarantee a
-receiving system will not log, store, or otherwise reveal the contents of the
-Bcc recipient list.
-
-Z-To: addresses MAY be shown to an end user.   
- 
-
-Envelope encryption
-*******************
-
-
-The entire envelope is encrypted using alg with env_key and env_iv and
-base64url encoded for transmission.
-
-The zot envelope MAY include remote addresses. A zot inbound delivery agent
-MUST parse the envelope and determine whether a delivery address to the
-current endpoint is valid. This may be the result of:
-
-	1. An address contains the public message wildcard '*'
-
-	2. The current endpoint is a personal endpoint and one of the recipients
-listed in the Z-To: or Z-Bcc: addresses matches the webfinger address of
-the "owner" of the endpoint.
-
-	3. The current endpoint is a bulk delivery endpoint. The bulk delivery
-endpoint is defined elsewhere in this document. The bulk delivery agent
-will deliver to all local addresses found in the address lists. 
-
-zot:sig
-*******
-
-The Sender of the message signs the underlying salmon data in the manner 
-prescribed by salmon. If the Sender and From address are identical, the
-signature will be identical to the signature of the underlying salmon packet. 
-If they are different, this signature is verified with the Sender's public 
-key to verify the Sender. 
-
-zot:alg
-*******
-
-Currently the only valid choice for alg is "AES-256-CBC". 
-
-
-zot:data
-********
-
-The data field is a salmon magic envelope. This is encrypted with alg using 
-key and iv. The result is then base64url encoded for transmission.
-
-For the first release of this specification, the data format of the enclosed
-salmon SHOULD be 'application/atom+xml' representing an Atom formatted
-ActivityStream. Future revisions MAY allow other alternate data formats.
-All acceptable formats MUST be listed in an XRD property (described elsewhere
-in this document).  
-
-
-Delivery
-********
-
-The zot message is then POSTed to the zot endpoint URL as 
-application/text+xml and can be decoded/decrypted by the recipient using 
-their private key.
-
-The normal salmon endpoint for a service MAY be used as an alternate
-delivery method for non-encrypted (e.g. public) messages. 
-
-Discover of the zot endpoint is based on webfinger XRD:
-
-<Link rel="http://purl.org/zot/1.0/post" 
-	href="http://example/org/zot-endpoint" />
-
-
-Bulk Delivery
-*************
-
-A site MAY provide a bulk delivery endpoint, which MAY be used to avoid
-multiple encryptions of the same data for a single destination.
-This is discoverable by providing a zot endpoint with a corresponding
-salmon public key in the site's .well-known/host-meta file.
-A delivery to this endpoint will deliver to all local recipients provided
-within the zot envelope. 
-
-
-Extensibility
-*************
-
-This specification is subject to change. The current version which is in
-effect at a given site may be noted by XRD properties. The following 
-properties MUST be present in the XRD providing the relevant endpoint:
-
-<Property type="http://purl.org/zot/1.0/version">1</Property>
-<Property type="http://purl.org/zot/1.0/accept">application/atom+xml</Property>
-
-
-Version is specified in this document and indicates the current revision.
-Version is an increasing non-zero integer value. There are no minor versions. 
-Implementations MAY provide compatibility to multiple incompatible versions
-by using this version indication. The "accept" indicates a range of document
-content types which may be enclosed in the underlying salmon magic envelope.
-We anticipate this specification will in the future allow for a close variant
-of "message/rfc822" and which may include MIME. This may also be used to 
-embed alternate message formats and protocols such as 
-"application/x-diaspora+xml". If a delivery agent is unable to provide any
-acceptable data format to the remote system, the delivery to that system MUST
-be terminated/cancelled. 
-
-Foreign Messages
-****************
-
-Messages MAY be imported from other networks and systems which have no 
-knowledge of salmon signatures. The salmon signature in this case MUST be the
-exact string 'NOTSIGNED' to indicate that the author (From address) cannot be 
-validated using salmon verification. This message MUST be relayed by a Sender
-who can provide a valid salmon signature of the message via zot:sig. Delivery
-systems MAY reject foreign messages.  
-
-
-
-
-
-*******************************
-* Zid (Zot-ID) authentication *
-*******************************
-
-This section of the document is considered separate from the delivery 
-specification precding it and represents a different protocol, which is
-currently incomplete. This will be split off into another document in the
-future, but is presented here as a synergistic component of the Zot network
-model. 
-
-
-URLs may be present within a zot message which refer to private and/or
-protected resources. Zid uses OpenID to gain access to these protected
-resources. These could be private photos or profile information - or *any*
-web accessible resource. Using zid, these can have access controls which 
-extends to any resolvable webfinger address.
-
-Zid authentication relies on the presence of an OpenID provider element in
-webfinger, and a URL template which is applied to protected resources within
-a zot message.
-
-The template is designated with the characters "{zid=}" within a URL of a zot
-message. When the page is rendered for viewing to an observer, this template
-is replaced with the webfinger address of the viewer (if known), or an empty
-string if the webfinger address of the viewer cannot be determined.
-
-For example in a message body:
-
-http://example.com/photos/bob/picture.jpg?{zid=}
-
-refers to a private photo which is only visible to alice@example.com.
-
-If Alice is viewing the page, the link is rendered with
-
-http://example.com/photos/bob/picture.jpg?zid=alice@example.com
-
-If the page viewer is unknown, it is rendered as
-
-http://example.com/photos/bob/picture.jpg?zid=
-
-
-When the link is visited, the web server at example.com notes the presence of 
-the zid parameter and uses information from webfinger to locate the OpenID 
-provider for the zid webfinger address. It then redirects to the OpenID 
-server and requests authentication of the given person. If this is successful,
-access to the protected resource is granted.
-
-A browser cookie may be provided to avoid future authentication redirects
-and allow authenticated browsing to other resources on the website.
-
-Only authentication via OpenID is defined in this version of the specification.
-
-This can be used to provide access control of any web resource to any 
-webfinger identity on the internet.
-
-
-*********
-* Links *
-*********
-
-Salmon Protocol
-	http://www.salmon-protocol.org/salmon-protocol-summary
-
-Salmon Magic Envelope
-	http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-01.html
-
-Atom Activity Stream Draft
-	http://activitystrea.ms/specs/atom/1.0/
-
-Activty Stream Base Schema
-	http://activitystrea.ms/head/activity-schema.html
-
-WebFinger Protocol
-	http://code.google.com/p/webfinger/wiki/WebFingerProtocol
-
-