?

Log in

Distributed commenting protocol - distributed blogs [entries|archive|friends|userinfo]
distributed blogs

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Distributed commenting protocol [Mar. 22nd, 2008|11:43 pm]
distributed blogs

d_blogs

[vitus_wagner]
I've written a description of protocol for distributed blog commenting, vaguely modelled after IETF drafts.

http://vitus.wagner.pp.ru/distributed-comments.txt

Any comments, suggestions, clarifications, language improvements are welcome.
LinkReply

Comments:
From: ex_ex_zhuzh
2008-03-22 08:57 pm (UTC)
я тут посидел, подумал. ну ведь есть же NNTP, может быть, внести туда немного модификаций?
(Reply) (Thread)
[User Picture]From: vitus_wagner
2008-03-22 09:01 pm (UTC)
Мне кажется, что использование NNTP в данном случае - умножение сущностей без необходимости. Во-первых, лишний порт, который могут на файрволлах резать, во-вторых, нам не нужна ВСЯ мощь NNTP. Задача несколько более ограниченная. В третьих, блог и тематическая ньюсгруппа - все же разные вещи.

Да, кстати, забыл в своем протоколе понятия community и moderator.
(Reply) (Parent) (Thread)
From: ex_ex_zhuzh
2008-03-22 09:06 pm (UTC)
NNTP как протокол обмена между серверами, а с клиентом можно и по HTTP общаться.
(Reply) (Parent) (Thread)
[User Picture]From: vitus_wagner
2008-03-23 05:52 am (UTC)
NNTP - премущественно PUSH протокол. Режим PULL там считается опциональным, только для читалок (команда MODE READER). А я считаю что протокол обмена между блог-серверами должен быть в первую очередь PULL. Поэтому я из NNTP взял только идею хэндшейка IHAVE/SENDME.
(Reply) (Parent) (Thread)
[User Picture]From: poige
2008-03-22 09:08 pm (UTC)

> я тут посидел, подумал. ну ведь есть же NNTP

ага, и вообще mail lists есть… ;-)
(Reply) (Parent) (Thread)
From: ex_ex_zhuzh
2008-03-22 09:33 pm (UTC)

Re: > я тут посидел, подумал. ну ведь есть же NNTP

не надо недооценивать. в nntp есть и модерация, и делеты, и апдейты.
(Reply) (Parent) (Thread)
[User Picture]From: yurikhan
2008-03-23 04:40 pm (UTC)

* s/recieve/receive/g

2.1 The term “blog post” should be defined explicitly.

2.2[.*] s/propriety/property/g

2.2.7 Users can delete their own comments. This is evident from 4.3 but not from 2.2.7.

3.1.1 It is not clear whether this paragraph refers to blogs of multiple users hosted on a single server or to blog posts belonging to one blog.

3.1.3 Shouldn’t the POST request body format be specified as text/plain?

(Reply) (Thread)
[User Picture]From: vitus_wagner
2008-03-23 05:00 pm (UTC)
As to 3.1.1 - it's said that page lists blogs, not posts. It should include any blog which can be commented on this site - either locally originated or retrieved from other sites to be displayed as friends tape. If I can think out proper definition for blog post as you've suggested, it would become clear.
(Reply) (Parent) (Thread)
[User Picture]From: yurikhan
2008-03-23 04:49 pm (UTC)

Format of timestamps

3.1.2 The format of the timestamp should be strictly defined. I propose ISO-8601, with a requirement that the time zone MUST be specified (no “local-in-unknown-pick-your-favorite-time-zone” times).

Since the topic of timestamps will arise several times in this specification, it makes sense to dedicate a separate paragraph that will establish the timestamp format once and for all.

(Reply) (Thread)
[User Picture]From: vitus_wagner
2008-03-23 05:03 pm (UTC)

Re: Format of timestamps

Since the topic of timestamps will arise several times in this specification, it makes sense to dedicate a separate paragraph that will establish the timestamp format once and for all.

There are really two different timestamps here. In the XML there is well-defined XML datatype for timestamp. And it should be used. In all other cases timestamp is integer number of seconds since Unix epoch.
(Reply) (Parent) (Thread)
[User Picture]From: yurikhan
2008-03-23 05:15 pm (UTC)

Re: Format of timestamps

Why have two formats for timestamps, seeing as they both apply to comment creation/modification time and will always be used together? Ease of implementation (atoi vs. parse_date_iso_8601) at the expense of protocol legibility?
(Reply) (Parent) (Thread)
[User Picture]From: yurikhan
2008-03-23 04:53 pm (UTC)

skip=number

3.1.2, 3.3.2 Why use the skip=n scheme for accessing older sections of the comment list? The position of each comment in a timestamp-sorted list is volatile and a subscribing client will be forced to request pages of the comment list until it finds a comment already retrieved in a previous session. Therefore, I propose a scheme that just outputs the whole list of new comments since a particular time.

The client requests the comment list URL via GET method with an optional parameter of the form since=timestamp. (What if the parameter is omitted? List all comments since the beginning of time, N most recent comments or all comments made during the last N days?) The server then responds with a list of comments made since the specified timestamp by the server’s clock and the current time. The client SHOULD record the server’s current timestamp as the initial value for subsequent synchronizations.

(Reply) (Thread)
[User Picture]From: yurikhan
2008-03-23 04:58 pm (UTC)

Comment XHTML validity

4 At some later time, an XML namespace URL should be assigned and a DTD or XSD published. All elements pertaining to distributed commenting should belong to that DTD and namespace.

4.2 Some users will want to post comments containing tag soup that is invalid XHTML. What do we do about them? (In the current form I interpret the specification that the commenting server MUST validate the user’s input as XHTML and either reject invalid comments, fix them using some DWIM-like heuristics such as Tidy, or treat them as plain text (escaping each < > " & as XML entities, the way LJ treats critically invalid markup). I also think it would be the Right Thing to require that sites that display comments SHOULD NOT (or, even more strictly, MUST NOT) interpret XML-encoded invalid HTML the way RSS does.)

4.2 Unresolved forward reference.

(Reply) (Thread)
[User Picture]From: vitus_wagner
2008-03-23 05:06 pm (UTC)

Re: Comment XHTML validity

At some later time, an XML namespace URL should be assigned and a DTD or XSD published. All elements pertaining to distributed commenting should belong to that DTD and namespace.
.. except when other standard namespaces like XHTML, XLink or XMLDSig are used. In this cases these namespaces should be properly imported into document.
Some users will want to post comments containing tag soup that is invalid XHTML.
Then server where this comment is posted first time, should do its best to fix this XHTML.

Really you've raised excellent questions! Thanks.
(Reply) (Parent) (Thread)
[User Picture]From: yurikhan
2008-03-23 05:04 pm (UTC)

Comment XHTML security

There should be a paragraph or even a chapter dedicated to security. Case in point: A malicious commenting server sends a comment containing client-side scripting. The original blog server displays the comment to its users who then have their browsers hijacked, cookies stolen and other bad things.

As a minimum, when receiving comments, each server SHOULD sanitize the comment XHTML from scripting elements and attributes, and also clean out any non-standard IE expression CSS rules.

(Reply) (Thread)
[User Picture]From: vitus_wagner
2008-03-23 05:10 pm (UTC)

Re: Comment XHTML security

There should be a paragraph or even a chapter dedicated to security.
Yes. Really, there should be analysis of various threats to the system. Malicious client-side script embedded in the comment is one of least important of those, because most servers do input sanitizing anyway. There are problems of malicious comment editing, spamming blogs using automated clients of this protocol etc.
(Reply) (Parent) (Thread)
[User Picture]From: nchaly
2008-04-03 08:55 pm (UTC)
приятно видеть опять активность)
у меня пару вопросов есть.

  • 3.1.2 - почему бы не использовать опять же rss (или разновидность) для получения комментариев? (смущает меня необходимость для вызывающей стороны листать страницы. может просто - modified since?)


  • 3.1.4 Otherwise it should respond with 200 response and immediately
    initiate procedure of recieving comment from the site which sent
    request.

    - тут наверное, можно про безопасность, вижу, уже упоминалось.


  • 3.1.4 ...only if comment was posted on the site to the blog originating on the site
    where request is sent, unless it is behind firewall or proxy.

    - вв этом предложении смысл неуловимо ускользает(, сайт в первом и втором случае - это что за они?


  • описка в 3.1.4 - connection cannot to it cannot be stablished


  • описка в 3.3.3.- as text/plain resoponse to the POST request.


  • 3.1.4 ...If notifying site is behind NAT or firewall and connection cannot to
    it cannot be stablished, reverse protocol described in section 3.3.3
    could be used.

    Почему-то я думал, что для "Posting notification" надо использовать push по умолчанию. Это не так? Тогда не совсем понятно, кто кого уведомляет, и как-то более описать этот нюанс.



Спасибо
(Reply) (Thread)
[User Picture]From: vitus_wagner
2008-04-04 06:18 am (UTC)

# 3.1.2 - почему бы не использовать опять же rss (или разновидность) для получения комментариев? (смущает меня необходимость для вызывающей стороны листать страницы. может просто - modified since?)
Потому что у разных вызывающих сторон потребности разные. В 90% случаев интересны комментарии за последние несколько минут или первые часы. Но иногда вылезает в сеть хост, который до этого неделю лежал.

Кроме того, возможно он уже сходил на какой-нибудь другой хост, на котором есть тот же блог, и ему интересны только те комментарии, которые в тот блог попасть не успели.

* Почему-то я думал, что для "Posting notification" надо использовать push по умолчанию. Это не так? Тогда не совсем понятно, кто кого уведомляет, и как-то более описать этот нюанс.

Я разрабатывал протокол так, чтобы PUSH там не использовался практически никогда. Исходя из того, что каждый сайт хранит только те комментарии, которые считает нужным и собирает - когда считает нужным. Единственное исключение - когда кэширующий сайт, где разрешено комментирование, находится за файрволлом или прокси, т.е. иницировать соединение к нему внешний сайт не может. Но даже и в этой ситуации (хотя в спецификации протокола это не отражено) мне кажется разумным ограничить PUSH-взаимодействие неким smart-хостом в интернете, который если и не находится под тем же административным контролем, то имеет с владельцем сайта за файрволлом явным образом заключенное соглашение. А от кого попало push не принимается. Вот аналог SMTP-шного ETRN - пожалуйста.
(Reply) (Parent) (Thread)
[User Picture]From: nchaly
2008-04-05 04:35 pm (UTC)
1 - да, я об этом и говорю. добавить параметр "комменарии с такой-то даты".

2 - что не пушить все сайты сети, необходим какой-то вариант подписки, который не описать. Я правильно понимаю, что комментарии можно воодить только на нескольких серверах? В таком случае хосты-хранители копий сообщения должны а) подписаться на пуш, б) быть уведомлены, что с такого-то хоста могут поступать комментарии по данному сообщению.

А как насчет эстафетной передачи постов/комментариев?
(Reply) (Parent) (Thread)
[User Picture]From: nchaly
2008-04-05 04:37 pm (UTC)
"вариант подписки, который не описан"
(Reply) (Parent) (Thread)
[User Picture]From: vitus_wagner
2008-04-05 06:01 pm (UTC)
Никакого варианта подписки. У блога есть foaf. Сейчас в foaf описывается только список блогов, которые читает владелец данного блога, но этот foaf легко расширяем. Добавляем туда список friends-of, и таким образом имеем список всех сайтов, где хранится копия данного блога.

PUSH-а быть на мой взгляд, не должно. Единственное место где приемлем PUSH, это когда владелец сайта за файрволлом по предварительной договоренности с владельцем сайта в интернете оптравляет комментарии через него. В остальных случаях есть только нотификация "У меня, возможно, есть что-то вам интересное". Получив эту нотификацию, тот сайт имеет право сделать PULL (а имеет право не делать).
(Reply) (Parent) (Thread)