[Standards] Microblogging: XEP-0277 and beyond

Sergey Dobrov binary at jrudevels.org
Sat Sep 3 10:07:45 UTC 2011

On 09/03/2011 12:41 AM, Justin Karneges wrote:
> On Friday, September 02, 2011 04:29:25 AM Sergey Dobrov wrote:
>> On 09/02/2011 03:32 AM, Justin Karneges wrote:
>>> On Thursday, September 01, 2011 11:22:30 AM Sergey Dobrov wrote:
>>>> Then, my questions about XEP-303:
>>>> 1) Why to use three nodes? Info node can be replaced by some item with
>>>> some constant id. about necessity of activity node I don't understood at
>>>> all, why to have it?
>>> I didn't want to put the info item in with the comments since they are
>>> not really part of the same collection of data.  The gain with a
>>> separate node is that you could subscribe to just the 'info', and not
>>> the comments, if for some reason you wanted to do that.  Maybe that
>>> isn't very useful.
>> Exactly, maybe we should extend node metadata instead of that?
> 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.

> So I think the data belongs in a node.  Or, we could consider adding
> notification support for node metadata.
> 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?

>> Then, I don't understand how "likes" can work in such model, who will
>> count likes? I think that this feature should be implemented in
>> aggregators, some services which aggregates messages from one or more
>> servers and give services of statistics, search or something else.
> 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.

> I want to point out again how the activity node makes it far easier to figure
> out what has actually happened.  If you have a notification app that is
> tracking your comments, subscribing to the activity node and listening for
> "Justin likes comment X" is much more straightforward than subscribing to the
> comments node and making inferences.
>> About post deletion, why to have this notification? Is it not enough to
>> receive a regular retract event?
> Comments node could send a retract event.  But activity node is always
> appending, and would send some notification such as "User N deleted comment X".
> Justin

More information about the Standards mailing list