Re: [Standards] Proposed XMPP Extension: Commenting
On Wednesday, July 13, 2011 08:40:06 AM Stephan Maka wrote: > 1) The specification imposes a naming scheme on Publish-Subscribe nodes. > Until now, XEP-0060 users could have assumed them to be rather > free-form. The proposed spec uses special naming for two reasons: 1) To make it easy to locate the set of nodes associated with the same conversation. To work around this we could say that a conversation must specify not simply a node prefix, but must specify the full name of all three nodes. 2) Parameters are passed by suffixing them to the node name. To work around this we could pass them in some separate section possibly. Given that we already precedent for fixed nodes names in PEP, I figured the node naming rules weren't anything to be terribly concerned with. > There is a general question on how a particlar content model is > designed. First, there is the "Twitter" model: posts are aggregated in > per-user nodes and reference posts in other nodes. > > On the other hand, services such as Facebook, Google+ and buddycloud > aggregate comments in the same context of the referred post. That could > mean, the whole conversation goes into a single Publish-Subscribe node. > This is what we at buddycloud do. A separate node for comments is > specified by the new Commenting XEP. I don't quite follow this. By "same context" do you mean to put comment items into the same node as a status messaging being replied to? > 2) Discussion flow modelling has been approached by The Open Web[tm] as > well: ATOM Threading Extensions[1] and the Salmon protocol[2]. > > ATOM Threading Extensions indicate what parent item a comment is > referring to. They can be applied to Publish-Subscribe content nicely, > if we had a URI scheme for referencing individual items, such as: > >xmlns:thr="http://purl.org/syndication/thread/1.0"; > ref="0f72afbe-a9d4-11e0-b0bc-0024bed71c0a" > type="application/atom+xml" > > href="xmpp:comments.example.com?pubsub;node=coffeetalk/comments;item=0f72a > fbe-a9d4-11e0-b0bc-0024bed71c0a" /> > > Such referencing is entirely missing from the proposed specification. Ah indeed, forgot this. Replies would work exactly this way. > The Salmon protocol, proposed by Google and used in OStatus, allows any > resource to receive comments by indicating an endpoint URL without > mandatory naming schemes. For ATOM content, this is as simple as > . Again, the spec does not force where the conversation must be. Just like how Atom can refer to a salmon URI, it could just as well refer to a JID+node_prefix. > They do not call it only "comments" because, what can be seen from the > variety of ActivityStreams verbs, there are more than just comments on > social networking services: likes, reposts, rsvps, follows, invites, > tags et cetera. This is just nomenclature; /commenting/ names the > category well enough. Indeed. Justin
Re: [Standards] Proposed XMPP Extension: Commenting
On Wednesday, July 13, 2011 08:51:24 AM Kevin Smith wrote: > On Tue, Jul 12, 2011 at 2:15 AM, XMPP Extensions Editor wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > I also asked Simon Tennant to comment, who remarked (reproduced with > permission): > > "I had a look through the commenting spec. There's a whole lot of > business logic in there that will really depend on the application. > They like infinite threads/bc likes one-level-deep... IMHO all we need > to do is specify: "use Atom". Well actually we don't. Everyone already > uses Atom. Sorry - I'd love to support things but this is just a > spec-fest and I don't see it adding much to XMPP." The commenting proposal addresses the following so-far unaddressed problems: 1) We need an efficient means of displaying existing comments without having to fetch all the comments in a conversation. Livefyre conversations get into the hundreds of comments, and sometimes exceed a thousand. That's not even including "like" activity. Also, RSM by date is not enough if you expect to support nesting. 2) When several users are publishing to the same node, and asserting their own author information to be contained within an Atom payload, we have a spoofing concern. The PubSub node needs to be "smart" then, to be able to natively understand the Atom format and sanitize submissions. 3) Related to 2) and 1), we need a way of caching author information beyond merely the author JID, otherwise the viewing client has to resolve this information. 4) Handling of unsolicited event notifications. This is primarily a solution for mentions. However, it also solves the "atomic post to remote conversation and local user activity" problem. You want to comment somewhere but also have that comment show up on some user profile page of yourself. Do you submit the comment to your profile service, and that service posts it to the conversation? Or, do you submit to the conversation and that service posts it to your profile service? Or, do you submit to both individually? The proposed XEP suggests the second case. This design is based on real-world experience building a federated commenting system. Yes, it is a lot of business rules. If you're hosting comments then you follow these rules. :) Justin
Re: [Standards] Proposed XMPP Extension: Commenting
Stephan Maka wrote: > [...] if we had a URI scheme for referencing individual items [...] > > xmpp:comments.example.com?pubsub;node=coffeetalk/comments;item=0f72afbe-a9d4-11e0-b0bc-0024bed71c0a Actually, it is specified like that by XEP-0060[1,2] but was just missing in the Querytype registry[3]. Mail to regist...@xmpp.org sent. Stephan [1] http://xmpp.org/extensions/xep-0060.html#impl-uri [2] http://xmpp.org/extensions/xep-0060.html#registrar-querytypes [3] http://xmpp.org/registrar/querytypes.xml
Re: [Standards] Proposed XMPP Extension: Commenting
On Tue, Jul 12, 2011 at 2:15 AM, XMPP Extensions Editor wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. I also asked Simon Tennant to comment, who remarked (reproduced with permission): "I had a look through the commenting spec. There's a whole lot of business logic in there that will really depend on the application. They like infinite threads/bc likes one-level-deep... IMHO all we need to do is specify: "use Atom". Well actually we don't. Everyone already uses Atom. Sorry - I'd love to support things but this is just a spec-fest and I don't see it adding much to XMPP." My (back to Kev's voice) knowledge of Atom and related japery is very weak, so I can't make an informed remark about this. /K
Re: [Standards] Proposed XMPP Extension: Commenting
XMPP Extensions Editor wrote: > Title: Commenting > Abstract: This specification defines a method for commenting. > URL: http://www.xmpp.org/extensions/inbox/commenting.html Hi It's nice that more people think about this aspect. I have two objections with the proposed mechanism: 1) The specification imposes a naming scheme on Publish-Subscribe nodes. Until now, XEP-0060 users could have assumed them to be rather free-form. There is a general question on how a particlar content model is designed. First, there is the "Twitter" model: posts are aggregated in per-user nodes and reference posts in other nodes. On the other hand, services such as Facebook, Google+ and buddycloud aggregate comments in the same context of the referred post. That could mean, the whole conversation goes into a single Publish-Subscribe node. This is what we at buddycloud do. A separate node for comments is specified by the new Commenting XEP. Because XEP-0060's access and publish models are flexible to allow that, and XMPP traffic always identifies the origin of a request, the second model can be used as well. It might be required that a post of a non-publisher can only be a comment to an item that actually exists. This rule must then be enforced by the Publish-Subscribe service. 2) Discussion flow modelling has been approached by The Open Web[tm] as well: ATOM Threading Extensions[1] and the Salmon protocol[2]. ATOM Threading Extensions indicate what parent item a comment is referring to. They can be applied to Publish-Subscribe content nicely, if we had a URI scheme for referencing individual items, such as: http://purl.org/syndication/thread/1.0"; ref="0f72afbe-a9d4-11e0-b0bc-0024bed71c0a" type="application/atom+xml" href="xmpp:comments.example.com?pubsub;node=coffeetalk/comments;item=0f72afbe-a9d4-11e0-b0bc-0024bed71c0a" /> Such referencing is entirely missing from the proposed specification. The Salmon protocol, proposed by Google and used in OStatus, allows any resource to receive comments by indicating an endpoint URL without mandatory naming schemes. For ATOM content, this is as simple as . They do not call it only "comments" because, what can be seen from the variety of ActivityStreams verbs, there are more than just comments on social networking services: likes, reposts, rsvps, follows, invites, tags et cetera. This is just nomenclature; /commenting/ names the category well enough. Stephan Maka [1] http://tools.ietf.org/html/rfc4685 [2] http://www.salmon-protocol.org/
[Standards] Proposed XMPP Extension: Commenting
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Commenting Abstract: This specification defines a method for commenting. URL: http://www.xmpp.org/extensions/inbox/commenting.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
