This is the Zot! social communications protocol.
Specification revision: 1
-01 September 2011
+2 October 2011
Mike Macgirvin
This specification is public domain.
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
+(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 both salmon and zot endpoints.
+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>
*******
A suitable randomly generated encyption key of length 32 octets for encrypting
-the envelope and salmon packet. This is then encrypted with the sender's
-private key and base64url encoded.
+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 envelope and salmon packet. This is then encrypted with the
-sender's private key and base64url encoded.
+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). Example:
+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:
-From: bob@example.com
-Sender: bob@example.com
-To: alice@example.com
+Z-From: zot:bob@example.com
+Z-Sender: zot:bob@example.com
+Z-To: zot:alice@example.com
-Both "From:" and "Sender:" MUST be provided, and represent a webfinger
-address of the author and sender respectively. The webfinger address for
-the From address MUST contain a discoverable salmon public key that
-is needed to verify the enclosed salmon data. Sender is used to indicate
+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.
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'.
+information as 'Sender' when posting a followup message.
-A reply to a given message MUST be sent to the original From address, and MAY
-be sent to any additional addresses in the recipient list. The original 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.
+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.
+signature fails to validate. Rejected messages for one of these reasons SHOULD
+be indicated with a "400 Bad Request" HTTP response.
-To: *
+Z-To: *
indicates a public message with no specifically enumerated recipients.
-The fields To:, Cc:, and/or Bcc: MAY be present. At least one recipient field
-MUST be present. These fields may use the entire syntax specified by RFC822,
-for example:
+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
-To: "Bob Smith" <bob@example.com>, "Alice Jones" <alice@example.com>
+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.
-is a valid entry. A zot envelope is UTF-8 encoded, which differs from RFC822.
-The host component MUST be US-ASCII, with punycode translation of
-internationalised domain names applied.
+In cases where an address may contain either a webfinger or LRDD address, the
+webfinger address SHOULD be used preferentially.
-The entire envelope is encrypted with alg using key and iv. Only AES-256-CBC
-is defined as an algorithm in this specification. The encrypted envelope is
-then base64url encoded for transmission.
-The zot envelope MAY include remote addresses. A zot delivery agent MUST parse
-all addresses and determine whether a delivery address to the current endpoint
-is valid. This may be the result of:
+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 To:, Cc:, or Bcc: addresses matches the webfinger address of
+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
Discover of the zot endpoint is based on webfinger XRD:
-<link rel="http://purl.org/zot/1.0/post"
+<Link rel="http://purl.org/zot/1.0/post"
href="http://example/org/zot-endpoint" />
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 xmlns:zot="http://purl.og/zot/1.0"
- type="http://purl.org/zot/1.0/version"
- zot:version="1" />
+<Property type="http://purl.org/zot/1.0/version">1</Property>
+<Property type="http://purl.org/zot/1.0/accept">application/atom+xml</Property>
-<Property xmlns:zot="http://purl.og/zot/1.0"
- type="http://purl.org/zot/1.0/accept"
- zot:accept="application/atom+xml" />
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.
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, the delivery MUST be terminated/cancelled.
+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 authentication *
-**********************
+
+*******************************
+* 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
This can be used to provide access control of any web resource to any
webfinger identity on the internet.
+
*********
* Links *
*********
projects / friendica.git / blobdiff