[Standards] Microblogging: XEP-0277 and beyond

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Wed Sep 7 00:40:12 UTC 2011


On Sunday, September 04, 2011 11:47:55 PM Sergey Dobrov wrote:
> On 09/05/2011 12:17 PM, Justin Karneges wrote:
> > On Saturday, September 03, 2011 03:07:45 AM Sergey Dobrov wrote:
> >> On 09/03/2011 12:41 AM, Justin Karneges wrote:
> >>> The drawback to node metadata is it does not support update
> >>> notifications.  I have the need to track this data, particularly the
> >>> conversation title.
> >> 
> >> Don't understand why to change that.
> > 
> > Don't understand why the title of a conversation might change?
> 
> Yup.

In my experience a title change for a commenting area is usually only done to 
correct a typo.  Still, applications that cache titles (think long running 
apps like web sites) should have a way to keep them up to date.

> >>> Activity makes it much easier to determine what has happened to an
> >>> item. For example, if a moderator edits a comment, this is easily
> >>> described in activity terms.  Simply doing complete replacement of
> >>> comment items is not terrible but it makes it harder for listeners to
> >>> figure out what is going on.
> >>> 
> >>> The main point is the activity node is an append-only changelog, and
> >>> the comments node is an up-to-date compilation of that log.
> >> 
> >> That's funny: some earlier you said: "My stance is there is nothing
> >> wrong with using a journal to implement pubsub, but ideally pubsub-using
> >> protocols should not be so complex that they require a journal-based
> >> implementation to participate." And now you talking about inventing the
> >> same journal but in specific (non-universal) way and in much more
> >> complex manner. Why?
> > 
> > It's simple: the activity node has optional persistence, hence the
> > journal is optional.
> 
> Journal is optional feature anyway. So it's more usable to make it
> universal and not force it to depend on an applied protocol, isn't it?

The activity node is actually the most normal.  It doesn't even define any 
parameters.  It's the raw stream of what's happening.

The comments node is the weird one.  It's a view/compilation of the activity.

> >>> The plan for likes is you'd publish to the activity node ("Justin likes
> >>> comment X"), but on the comment node this would be reflected as a
> >>> property of an existing comment rather than a new item.  Comment items
> >>> could have "like" data stored within them, such as a count and maybe a
> >>> list of the last five people to like the comment.
> >> 
> >> I think that all these actions should not be copied from centralized
> >> services since that services have more possibilities to control them. I
> >> mean, it will be very hard to check if likes are winded by some bad
> >> mans. Also it will be hard to represent some statistics of most liked
> >> items. So I think that these things should be solved in that manner how
> >> google ranking web pages: aggregators will rank items by repost counts
> >> or something. And, yes, for user like button should be replaced by
> >> "repost" or "repost with comment", I have such functionality in my
> >> microblogging service and I want to add it into the XEP-277.
> > 
> > What do you mean by centralized?  That the conversation is the authority
> > on all of its replies and likes?
> 
> Yes, I don't understand what is the reason to have likes in such system
> if we can't count them globally and give stats.

The problem with distributing a single conversation across servers is then you 
need a way of aggregating even in the common case.  Simply viewing the 
conversation properly with nested threads and like points requires an 
aggregator.  This is what Salmon is for in the HTTP world: telling upstream 
you've made a reply/like/etc.  My humble opinion is that this approach does 
have some cool-factor but it is also a giant pain in the ass in terms of 
practicality.

I think that if we ever did support distributed conversations then you'd still 
want the main conversation node (root node) to be able to hold copies of all 
the content (e.g. use a salmon-like process so that the root node remains in-
the-know and is able to serve the full dataset to clients).  Assuming this is 
acceptable, then we can always add distribution in the future.

Justin



More information about the Standards mailing list