friendica
/
friendica
mirror of https://github.com/friendica/friendica.git
4
7
Fork 3
Code Issues Releases 15 Wiki Activity
Browse Source

zot protocol update

pull/1/head
Friendika 11 years ago
parent
0ad9e7b5f4
commit
96e735fdd2
2 changed files with 93 additions and 33 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 2
      boot.php
  2. 124
      zot.txt

2
boot.php
Unescape View File

@ -8,7 +8,7 @@ require_once("include/pgettext.php");
require_once('include/nav.php');
define ( 'FRIENDIKA_PLATFORM', 'Free Friendika');
define ( 'FRIENDIKA_VERSION', '2.3.1120' );
define ( 'FRIENDIKA_VERSION', '2.3.1121' );
define ( 'DFRN_PROTOCOL_VERSION', '2.21' );
define ( 'DB_UPDATE_VERSION', 1093 );

124
zot.txt
Unescape View File

@ -1,7 +1,7 @@
This is the Zot! social communications protocol.
Specification revision: 1
15 September 2011
2 October 2011
Mike Macgirvin
This specification is public domain.
@ -78,16 +78,21 @@ 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.
From: bob@example.com
Sender: bob@example.com
To: alice@example.com
Example:
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
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.
@ -95,46 +100,91 @@ 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'.
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 foreign protocol address prefixes
for use in Z-To: or Z-Bcc: elements:
zot: - normal zot delivery using webfinger or LRDD resolvable 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.
To: "Bob Smith" <bob@example.com>, "Alice Jones" <alice@example.com>
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.
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 then encrypted using alg with env_key and env_iv and
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 delivery agent MUST parse
all addresses and determine whether a delivery address to the current endpoint
is valid. This may be the result of:
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
@ -219,7 +269,8 @@ 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, the delivery MUST be terminated/cancelled.
acceptable data format to the remote system, the delivery to that system MUST
be terminated/cancelled.
Foreign Messages
****************
@ -233,9 +284,18 @@ 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

Write Preview
Loading…
Cancel
Save