[Standards] Microblogging: XEP-0277 and beyond
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".
More information about the Standards