Tupambae_Org/friendica_2021-01
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

zot protocol update

Browse source
This commit is contained in:
Friendika 2011-10-01 18:54:48 -07:00
parent 0ad9e7b5f4
commit 96e735fdd2
2 changed files with 93 additions and 33 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
boot.php
View file

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

124
zot.txt
View file

@ -1,7 +1,7 @@
This is the Zot! social communications protocol. This is the Zot! social communications protocol.
Specification revision: 1 Specification revision: 1
15 September 2011 2 October 2011
Mike Macgirvin Mike Macgirvin
This specification is public domain. This specification is public domain.
@ -78,16 +78,21 @@ zot:env
******* *******
This consists of RFC822-style header fields representing the sender and 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 Example:
Sender: bob@example.com
To: alice@example.com
Both "From:" and "Sender:" MUST be provided, and represent a webfinger Z-From: zot:bob@example.com
address of the author and sender respectively. The webfinger address for Z-Sender: zot:bob@example.com
the From address MUST contain a discoverable salmon public key that Z-To: zot:alice@example.com
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 the webfinger identity responsible for transmitting this message. From
indicates the message author. 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 the original message participants. Only the author of the original message
may know all the recipients (such as those contained in Bcc: elements). The may know all the recipients (such as those contained in Bcc: elements). The
author of a message always provides 'From'. They MUST duplicate this 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 A reply to a given message MUST be sent to the From address of the original
be sent to any additional addresses in the recipient list. The original author post, and MAY be sent to any additional addresses in the recipient list. The
MUST send the reply to all known recipients of the original message, with original post author MUST send the reply to all known recipients of the
their webfinger identity as Sender, and the comment/reply author as From. 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 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 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 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 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 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. indicates a public message with no specifically enumerated recipients.
The fields To:, Cc:, and/or Bcc: MAY be present. At least one recipient field The fields Z-To: and/or Z-Bcc: MAY be present. At least one recipient field
MUST be present. These fields may use the entire syntax specified by RFC822, MUST be present.
for example:
To: "Bob Smith" <bob@example.com>, "Alice Jones" <alice@example.com> Z-To: zot:bob@example.com, zot:alice@example.com, mailto:dave@example.com
Z-Bcc: zot:https://example.com/profile/richard
is a valid entry. A zot envelope is UTF-8 encoded, which differs from RFC822. are valid entries. Adresses are comma separated and individual entries MUST NOT
The host component MUST be US-ASCII, with punycode translation of contain commas. There MAY be any number of ASCII space characters between
internationalised domain names applied. entries for legibility. Header lines are terminated with a linefeed character
(ASCII 0x0A).
The entire envelope is then encrypted using alg with env_key and env_iv and 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.
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. base64url encoded for transmission.
The zot envelope MAY include remote addresses. A zot delivery agent MUST parse The zot envelope MAY include remote addresses. A zot inbound delivery agent
all addresses and determine whether a delivery address to the current endpoint MUST parse the envelope and determine whether a delivery address to the
is valid. This may be the result of: current endpoint is valid. This may be the result of:
1. An address contains the public message wildcard '*' 1. An address contains the public message wildcard '*'
2. The current endpoint is a personal endpoint and one of the recipients 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. the "owner" of the endpoint.
3. The current endpoint is a bulk delivery endpoint. The bulk delivery 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 of "message/rfc822" and which may include MIME. This may also be used to
embed alternate message formats and protocols such as embed alternate message formats and protocols such as
"application/x-diaspora+xml". If a delivery agent is unable to provide any "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 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 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 protected resources. Zid uses OpenID to gain access to these protected