Blog Protocol
Design a protocol to be used for blog.
It should also be documented in the wiki.
Message types
Each blog has its own group. For exchanging invitations, the client uses a separate group for each pair of contacts.
Blog Group
The group descriptor is a BDF list with three elements: name
(string), author_name
(string) and public_key
(raw). Posts are signed with the corresponding private key.
0: POST - The content is a BDF list with two elements: content
(list) and signature
(raw).
content
is a list with six elements: parent_id
(raw or null), content_type
(string), title
(string or null), body
(raw), and attachments
(dictionary or null). parent_id
is the identifier of a post to which this is a follow-up. This parent post needs to be in the same blog group as this post. A blog clients must support a content_type
of 'text/plain' for posts. 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 three elements: group_id
(raw), timestamp
(int), and content
(list). group_id
and timestamp
are taken from the message header. content
is described above.
1: ATTACHMENT - The content is raw data.
Invitation Group
The group descriptor is a BDF list containing the unique IDs of the contacts' identities, sorted in ascending order as byte strings.
0: INVITATION - The content is a BDF list with four elements: name
(string), description
(string), author
(list), and message
(string or null).
The author
is a list with two elements: author_name
(string) and public_key
(raw).
The identifier of the blog group to which the invitation refers can be calculated from name
, author_name
and public_key
, as described above. message
is an optional message from the inviter to the invitee.
1: ACCEPT RESPONSE - Response that indicates the peer wants to subscribe to the blog. The content is a BDF list with one element: invitation_id
(raw) which is the identifier of an invitation created by the opposite peer.
2: DECLINE RESPONSE - Response that indicates the peer does not want to subscribe to the blog. The content is a BDF list with one element: invitation_id
(raw) which is the identifier of an invitation created by the opposite peer.
3: LEAVE - The content is a BDF list with one element: invitation_id
(raw), which is the identifier of an invitation created by either peer.
Open Questions
Who can invite to blogs? Only the creator or everybody who subscribes to the blog?
- Every subscriber can invite others.
Who can send a LEAVE message? Only subscribers or the creator as well?
- Both, the creator and the subscribers can send LEAVE messages at any time.
How can we enforce that only the creator can post to the blog group? Should other clients reject message based on signature? If so, how do they verify?
- The signature on blog posts is verified using the public_key of the blog.
- Which key pair is used for the blog? The long-term key-pair of its creator or a special blog key-pair?
- What will be the
content_type
of blog posts? Are we going to support HTML initially? How will people create/edit the HTML?
- This has been outsourced to #421, but we need to know what kind of content type to accept and validate for the protocol.
- All blog clients should support
text/html
for the content type.
Should blog posts not have a title as well? It is currently not part of the POST message.
- A
title
has been added to the POST message.
Do we really need a note/message to be send along with the response?
- No! It has been removed from both responses.
- Will blog authors be able to edit their post after they have published it already? If so, how? Special update message or re-use of
MessageId
?
- For the first phase, we'll assume that blog authors cannot edit published posts
- Are we really going to use the 'sharing as action' paradigm for blogs? Maybe 'sharing as state' would be more suitable and allow for blogs to be available to more people more easily. (discussion)
- akwizgran decided to do sharing as action as with forums, because this is easier to understand for users due to familiar metaphors.
- later we can add automatic sharing on top of the current mechanism
- Should there be an option/flag that signals contacts you share the blog with that they automatically should share it with all of their contacts? (metadata leak?)
- If we do sharing as action, then no. At least, initially. Later we can add automatic sharing, but don't necessarily need a flag for it.
- Are we going to support comments initially? If not, it might still be worth looking into how they could work, so the protocol does not need to be changed too much later on.
- WordPress-style comments won't be supported
- However, we could support Tumblr-style "reblog and add your own text" comments
- Reblogging would not be a phase 1 feature however
- How do we tie the creator's identity to the blog (and its key pair)?
- the blog descriptor includes the creator's public key and she uses her private key to sign all posts.
- Should the blog description be part of the group descriptor? If yes, it can never be changed, if no, it could be changed by sharers.