Skip to content
GitLab
Closed
Issue created by Torsten Grote@groteOwner

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.

blog-sharing

Open Questions

  1. Who can invite to blogs? Only the creator or everybody who subscribes to the blog?
  • Every subscriber can invite others.
  1. 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.
  1. 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.
  1. Which key pair is used for the blog? The long-term key-pair of its creator or a special blog key-pair?
  2. 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.
  1. 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.
  1. Do we really need a note/message to be send along with the response?
  • No! It has been removed from both responses.
  1. 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
  1. 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
  1. 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.
  1. 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
  1. 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.
  1. 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.