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

Sergey Dobrov binary at jrudevels.org
Thu Jun 2 11:03:25 UTC 2011


Suddenly, your mail client don't reply in the thread. :(

On 06/02/2011 05:55 AM, Valérian Saliou wrote:
> Hello,
> 
> I will try to reply to your answers/suggestions ;)
> 
> 1. In the microblogging XEP we wanted to define a simple way to share
> some files. But I never heard of the XEP-0135, will read it as soon as
> possible. Anyway, by looking at it quickly, it gives me some ideas about
> how we could manage photo albums/file albums to extend XMPP social
> features!
Sure, you should always do some research about underlying or just
already existing protocols before write anything.
But, again, this protocol doesn't clarify the way to upload files to the
filehosting service. I mean, that's ok to use SI protocol to do that but
how to specify a path to upload file to?

> 
> 2.1. It is actually clear: there is an example after this text.
It is but I don't agree that we should keep this as is. Because examples
is very large and for better understanding we have to clarify that. When
man is reading it should compare the text with the example to have
better understanding. In this case, obviously, that's impossible.

> 
> 2.2. Mhh, maybe I did not understand you when you suggested us this.
> Were you talking of the parent microblog item of a comment node, in case
> of re-using the comment node somewhere else? Or to identify the original
> comment node parent if the parent was repeated by some users in their
> own microblog?

I meant original post to which all the node related for. Simple usecase:
you receive an xmpp link which leads you to a particular comment in a
replies node. You can parse it and show to a user but how to show him
what post is this comment for? For that I decided to use rel="start"
link. I hope that it is clear enough.

> 
> 2.3. I don't really see where the security leak is. The microblog owner
> publishes an entry linking to a comment node, and the client retrieves
> it if there is a link to it. Or maybe you mean, avoid re-using a comment
> node URI in another microblog post by a nasty microblog item publisher?

Yes I mean that, for example, some spammer can post his nasty post with
rel="replies" that points to your comment. So user will be sure that it
replies for some AD post but you will receive this comments instead of
spammer. And all of your subscribers too. Of course, they could filter
it by <link rel="start"> but you will have many many junk in your node
anyway.

> 
> 3. I really think it makes things much simpler and clearer by separating
> the content itself from the informations, so that the owner can purge
> its microblog node without any meta-infos lost.

I have half of agreement here. :) You missed the point of metadata for
replies nodes. How to be with them? And the other point of this is
integrity. It's very hard to keep in consistency many nodes.

> 
> 4. The notifications, as defined in the XEP, can be sent to the node's
> owner (you can retrieve who the owner is with a pubsub query), and all
> the comment publishers. By the way, the parent microblog item publisher
> might be also notified.

Yep. So why we have to use "inbox" feature to notify users? I mean your
way (it is RECOMMENDED the user's client send a notification to the
people who commented on the comments node) is a very big overhead and if
we want to keep it in the document we should to give some
recommendations how client could do that. I have no idea, for example.

> 
> 5. I studied this case before. There is a solution with the <set
> xmlns='http://jabber.org/protocol/rsm'> element, to say the server "Hey,
> I just want the items published after the item with the ID=XX" (see the
> Pubsub XEP for that), but its usage is not clearly described and it is
> not implemented in XMPP servers like ejabberd.

I knew about RSM. But I forgot about <after> possibility. I'll try to
research about the possibility to add RSM support to ejabberd's
mod_pubsub but ejabberd have support of rsm in odbc version of pubsub.
But I don't like ejabberd's pubsub at all and want to try other
alternatives.

> 
> 6. Related to Pubsub XEP, I remember some mails were exchanged about
> this "Pubsub item count" during the last month, right?

Yep but I don't know about any accepted solution. In other hand we have
the problem with retracts notifications. I mean that it's impossible to
know when items was retracted while you was in offline.

I forgot to ask about node configuration. We talked about node
configuration options to recommend for blog node and for replies nodes
but I don't understand if you think that these suggestions was fine.

> 
> Best regards,
> 
> 
> Valérian Saliou,
> Jappix founder
> 
> ---------------------
> On 06/02/2011 12:36 AM, XMPP Extensions Editor wrote:
>> Version 0.4 of XEP-0277 (Microblogging over XMPP) has been released.
>>
>> Abstract: This specification defines a method for microblogging over
> XMPP.
>>
>> Changelog: Added microblog informations feature, ID innacurracy fixed,
> urn:xmpp:inbox support added, new commenting namespaces, first comment
> marker, security considerations added. (vs)
>>
>> Diff: http://xmpp.org/extensions/diff/api/xep/0277/diff/0.3/vs/0.4
>>
>> URL: http://xmpp.org/extensions/xep-0277.html
>>
>>
> 
> The revision of document has disappointed me...
> 
> 1. The "2.7 Attaching files to a post" point. I don't really understand
> how client should to serve the files. I think that we should to use
> XEP-135 to do that. I don't understand why to use rel="self" instead of
> rel="related" for a link to a file (rel="self" identifies a resource
> equivalent to the containing element which is obviously false. Please
> correct me if I wrong)
> 2. The "3. Comments" point.
> 2.1. "Romeo's client MIGHT add a element to the PubSub item." It's not
> clear what element might Romeo's client to add.
> 2.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 identify 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.
> 2.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.
> 3. 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? How to store metadata for replies
> nodes this way?
> 4. 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.
> 
> Some things that not related to new revision:
> 5. 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 think that we should add possibility to
> retrieve items from a node with timestamp or just a query that allow to
> check if there was items since the moment and how many.
> 6. 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)
> 


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




More information about the Standards mailing list