[Standards] UPDATED: XEP-0277 (Microblogging over XMPP)

Sergey Dobrov binary at jrudevels.org
Wed Jun 15 19:44:47 UTC 2011

Generalize my suggestions for XEP-0277 as was asked by Neustradamus.

1. I agreed with Arc Riley that XEP-0277 should not contain "2.7.
Attaching files to a post" as overhead and the reason which is slowing
down acceptance of the standard.
1.1 If attachments will be kept in the XEP it needs to rel="self" in
link to a file to be changed to rel="related" because self means the
entry itself contained in other URI.

2. I don't agree that we should use standard node configuration for
microblogs nodes. That's my suggestions:
2.1. For microblog node itself:
2.1.1. We should change "pubsub#notify_retract" to true to track removed
items to remove them from UI.
2.1.2. Change "pubsub#max_items" to some reasonable value (for example,
ejabberd's default configuration defaults it to 10 which is too small
for persistent blog storage)
2.1.3. "pubsub#send_last_published_item" for PEP defaults to
"on_sub_and_presence" which is bad for microblog node because we don't
need to receive last item on each login bacause of the nature of a blog.
So I suggest to change it to "never".
2.2. For replies node:
2.2.1. We should change "pubsub#notify_retract" to true to track removed
items to remove them from UI.
2.2.2. Change "pubsub#max_items" to some reasonable value (for example,
ejabberd's default configuration defaults it to 10 which is too small
for persistent blog storage)
2.2.3. Change "pubsub#access_model" to "open" to allow any user to comment
to a post. (Or restrict this property in accordance to user's settings)

3. The "3. Comments" point.
3.1. "Romeo's client MIGHT add a element to the PubSub item." It's not
clear what element might Romeo's client to add. I know that there
example in document but I think that document should be as clear as
3.2. "If the comment to publish is the first item of the node, the
client MAY add a "link" element, with the "rel=start" attribute." Why
only for first? How to determine if it first? What if the comment will
be retracted? The spec doesn't clarify what href should be added with
the link. I use rel="start" as identifier of the post to what whole
replies node is related. I mean to the post which have <link
rel="replies"> to this pubsub node with comments. In this way client can
always determine a thread to what comment is related even if it receive
an xmpp-link to some comment and not for an original post.
3.3. There are one possible attack to a comments node. If some entity
will publish post with link rel="replies" to a comments node for another
post then users can be confused with actual content of the post to which
they replying. I assume to add cross references links to both post and
replies node metadata and oblige client to check if links correspond to
one another.

4. The "5. Microblog informations" point. Why to make more and more new
entities? I mean why we need the new node
"urn:xmpp:microblog:0:informations"? Why can't we use the
"urn:xmpp:microblog:0" node itself?
4.1. How to store metadata for replies nodes this way?

5. The "6. Notifications" point is the most strange for me. Why to send
notification when commenting on node? I mean we already have replies
node to which anyone can subscribe and receive usual notifications. I
understand that it's impossible to do that when replies node is not
used. But how can I determine to which users I should send my
notifications? If I constantly attached to the network I can see all
thread and all comments but if I use different resources and often
switch between them then all this schema will fail. But I think it can
be useful for some other kinds of events.
5.1. I can suggest my way to solve the problem. In my implementation of
prototype of microblogging service based on pubsub I have one more
entity which called "Aggregator". It simply subscribes to all users and
any comments node and consumes all events saving it in it's database.
Then it can represent it on web (http://b.habahaba.im/ does so), give
full text search based on Ad-Hoc or web, give many extra services which
you can find on regular services. My Aggregator is attached to the xmpp
host and consumes only events for this host and represents web service
for mine microblogging service. But it's possible to build global
aggregator service which will consume any events in global network and
can be the same as google now for WWW.
6. I think that we should add an ability to add categories (e.g. tags) to
the posts (and/or comments). That is easy using entry:category Atom element:

<category term="xmpp"/>

7. Moving a text of post to a <content> item is fine but Atom's entry
MUST contain at least one <title> element. I suggest to put to the
<title> element plain text version of content truncated to 140 chars. (I
already have it in my implementation)
8. Why to use <source> element in posts where it contains only <author>
element? I think that it would be better to move it in examples directly
to an entry element:
<entry xmlns="http://www.w3.org/2005/Atom">
    <name>Sergey Dobrov</name>
    <uri>xmpp:binary at jrudevels.org</uri>
  <title>My post</title>
  <content type="text">My post</content>

Obviously, implementations should parse both variants of placement of
atom:author but I think that we should suggest the simplest variant in
our examples.

Some things that not related to new revision:
1. Retrieve offline items. I don't know how it possible to retrieve
items that was sent while my client was in offline or the priority of my
client was not highest. I already suggested to allow pubsub nodes to
have it's own journal to track any events in a node.
2. We have no possibility to retrieve count of items in a node easily. I
know about metadata for a node but I don't think that this is really
easy way to retrieve such a basic information. (I don't know how it will
be efficient for server side). Partially the problem can be solved with
RSM but it's impossible to know count of items without node retrieving.
I already heard here the suggestion to include this value in each pubsub

With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.

More information about the Standards mailing list