From 2a38d07bd36826cb44b7990b0c017f8245748cf8 Mon Sep 17 00:00:00 2001 From: akwizgran Date: Wed, 20 Jan 2016 17:38:05 +0000 Subject: [PATCH] s/channel/group/g --- BlogClient.markdown | 60 --------------------------------------------- BlogClient.md | 60 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 60 insertions(+), 60 deletions(-) delete mode 100644 BlogClient.markdown create mode 100644 BlogClient.md diff --git a/BlogClient.markdown b/BlogClient.markdown deleted file mode 100644 index 135a86f..0000000 --- a/BlogClient.markdown +++ /dev/null @@ -1,60 +0,0 @@ -BlogClient is a [BSP client](BSP) that synchronises blog posts among groups of devices. Any subscriber to a blog can invite new subscribers, but only the creator of the blog can post. - -> Implementation note: We propose to use Ed25519 for signatures. - -### Channel identifiers - -BlogClient uses the following client identifer: -`dafb e56f 0c89 7136 5cea 4bb5 f08e c9a6 1d68 6e05 8b94 3997 b6ff 259b a423 f613` - -Each blog has its own channel, and there is a single invitation channel shared by all blogs. The [channel descriptor](BSP#channel-identifiers) for the invitation channel is an empty [BDF list](BDF). - -The descriptor for a blog channel is a list with two elements: `title` (string) and `public_key` (raw). Posts are signed with the corresponding private key. - -### Message types - -**0: INVITATION** - The content is a list with three elements: `title` (string), `public_key` (raw), and `note` (string or null). The channel identifier can be calculated from `title` and `public_key`, as described above. `note` is an optional note from the inviter to the invitee. - -**1: RESPONSE** - The content is a list with three elements: `invitation_id` (raw), `decision` (boolean), and `note` (string or null). `invitation_id` is the identifier of an invitation created by the opposite peer. `decision` indicates whether the invitee wishes to subscribe. `note` is an optional note from the invitee to the inviter. - -**2: DEPARTURE** - The content is a list with one element: `invitation_id` (raw), which is the identifier of an invitation created by either peer. - -**3: POST** - The content is a list with two elements: `content` (list) and `signature` (raw). - -`content` is a list with four elements: `parent_id` (raw or null), `subject` (string), `body` (string), and `attachments` (dictionary or null). `parent_id` is the identifier of a post to which this is a follow-up. Each key in `attachments` is the name of an attachment, and the value is a list with two elements: `mime_type` (string) and `message_id` (raw). - -`signature` is a signature over a list with four elements: `channel_id` (raw), `salt` (raw), `timestamp` (int), and `content` (list). `channel_id`, `salt` and `timestamp` are taken from the [message header](BSP#message-format). `content` is described above. - -**4: ATTACHMENT** - The content is raw data. - -### Validity policy - -* An invitation or response must belong to the invitation channel. -* A post or attachment must belong to a blog channel. -* An invitation is valid if it is well-formed. -* A response is valid if it is well-formed and it references a valid invitation created by the opposite peer. -* A departure is valid if it is well-formed and it references a valid invitation created by either peer. -* A post is valid if it is well-formed, its parent (if any) is a valid post, and it carries a valid signature. -* An attachment is always valid. - -Note that a post can be validated before its attachments have been received, and an attachment can be validated before it has been completely received. - -### Storage policy - -For the invitation channel: -* All local messages are stored. -* All remote messages are stored. - -For forum channels: -* Local messages are stored while the local per subscribes to the blog. -* Remote messages are stored while the local peer subscribes to the blog. - -### Sharing policy - -For the invitation channel: -* Each local message is shared with one remote peer. -* Each remote message is shared with the remote peer that created it. - -For forum channels: -* Local messages are shared with all remote peers that subscribe to the blog. -* Remote messages are shared with all remote peers that subscribe to the blog. diff --git a/BlogClient.md b/BlogClient.md new file mode 100644 index 0000000..a2da210 --- /dev/null +++ b/BlogClient.md @@ -0,0 +1,60 @@ +BlogClient is a [BSP client](BSP) that synchronises blog posts among groups of devices. Any subscriber to a blog can invite new subscribers, but only the creator of the blog can post. + +> Implementation note: We propose to use Ed25519 for signatures. + +### Group identifiers + +BlogClient uses the following client identifer: +`dafb e56f 0c89 7136 5cea 4bb5 f08e c9a6 1d68 6e05 8b94 3997 b6ff 259b a423 f613` + +Each blog has its own group. The [group descriptor](BSP#group-identifiers) is a [BDF list](BDF) with two elements: `title` (string) and `public_key` (raw). Posts are signed with the corresponding private key. + +For exchanging invitations, the client uses a separate group for each pair of contacts. The group descriptor is a BDF list containing the unique IDs of the contacts' identities, sorted in ascending order as byte strings. + +### Message types + +**0: INVITATION** - The content is a BDF list with three elements: `title` (string), `public_key` (raw), and `note` (string or null). The identifier of the blog group to which the invitation refers can be calculated from `title` and `public_key`, as described above. `note` is an optional note from the inviter to the invitee. + +**1: RESPONSE** - The content is a BDF list with three elements: `invitation_id` (raw), `decision` (boolean), and `note` (string or null). `invitation_id` is the identifier of an invitation created by the opposite peer. `decision` indicates whether the invitee wishes to subscribe. `note` is an optional note from the invitee to the inviter. + +**2: DEPARTURE** - The content is a BDF list with one element: `invitation_id` (raw), which is the identifier of an invitation created by either peer. + +**3: POST** - The content is a BDF list with two elements: `content` (list) and `signature` (raw). + +`content` is a list with four elements: `parent_id` (raw or null), `content_type` (string), `body` (raw), and `attachments` (dictionary or null). `parent_id` is the identifier of a post to which this is a follow-up. Each key in `attachments` is the name of an attachment, and the value is a list with two elements: `content_type` (string) and `message_id` (raw). + +`signature` is a signature over a list with four elements: `group_id` (raw), `timestamp` (int), and `content` (list). `group_id` and `timestamp` are taken from the [message header](BSP#message-format). `content` is described above. + +**4: ATTACHMENT** - The content is raw data. + +### Validity policy + +* An invitation or response must belong to an invitation group. +* A post or attachment must belong to a blog group. +* An invitation is valid if it is well-formed. +* A response is valid if it is well-formed and it references a valid invitation created by the opposite peer. +* A departure is valid if it is well-formed and it references a valid invitation created by either peer. +* A post is valid if it is well-formed, its parent (if any) is a valid post, and it carries a valid signature. +* An attachment is always valid. + +Note that a post can be validated before its attachments have been received, and an attachment can be validated before it has been completely received. + +### Storage policy + +For invitation groups: +* All local messages are stored. +* All remote messages are stored. + +For blog groups: +* All local messages are stored. +* All remote messages are stored. + +### Sharing policy + +For invitation groups: +* All local messages are shared. +* All remote messages are shared. + +For blog groups: +* All local messages are shared. +* All remote messages are shared.