[Standards] Microblogging: XEP-0277 and beyond

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Thu Sep 1 20:32:40 UTC 2011

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.

I do believe there is a need to have separate comments and activity nodes 
though, and possibly even more in the future (I want to have an "occupants" 
node containing a userlist of people with temporary subscriptions -- think MUC 
over pubsub).  So, I have already resigned to needing multiple nodes, and when 
it came time to need 'info', I decided a singleton made logical sense.

The activity node is actually the core node of the system.  Flowing through it 
would be the stream of activity occuring in the conversation.  If you want to 
post a comment, like a comment, delete a comment, etc, it makes sense to 
publish them as "activity".  If you want to receive events for these kinds of 
activities (e.g. to track the conversation while you are away, and power 
something like Facebook Notifications), then again you want to be subscribed to 
items of "activity".  This is distinct from the comments node, which only 
holds the comments in their current state.  For example, if a comment is 
posted and edited three times after that, this would be represented as four 
items in the activity node but still only one item (updated three times) in 
the comments node.  The comments node is needed to drive application displays.  
So this is why I believe both nodes are needed.

I don't want servers to have to maintain an activity log to be compliant 
though, which is why item persistence on the activity node is optional.  A 
simple server can receive a published activity item, relay it to subscribers, 
apply it to the comments node state, and then throw it away.

> 2) Why to use Activity Streams here? I totally misunderstanding why to
> have such complication since commenting behavior totally get into simple
> Atom format.

AS make the most sense for the activity node.  It makes less sense for the 
comments node though.  Perhaps the comments node could be an Atom-only 

> 3) You have filter parameter by parent id but have no any mechanism to
> represent such relations. But this mechanism is already defined in XEP-277.

Hmm, yes.  Agree it should be thr:in-reply-to.

> 4) atom:id MUST be an URI.

Oops, you're right.

> 5) Again, why to url encode a node name?
> ("comments?order=-created&parent_ids=1%2C5a%2Co19g%2C")

It was just an easy approach that would work with existing pubsub client 
libraries.  Perhaps a better idea would be to allow <options> in pubsub iq 
requests, then we can have an x:data form for the extra parameters.


More information about the Standards mailing list