Re: [Standards] Microblogging: XEP-0277 and beyond
On 09/07/2011 07:40 AM, Justin Karneges wrote: 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. ok, maybe it can be useful but not a first-time needed feature. anyway, from my point of view it will be more useful to invent more flexible metadata protocol for nodes. (i mean, if node configuration changes may be delivered immediately as event, why metadata can't? but I really hate producing entities in a kind of nodes) 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. It is. But it's not flexible (for other protocols than XEP-303). Again, I think that it's completely unnecessary complication for servers (since server should support consistency of that nodes). Pubsub services are not too ideal without that complications. If we will produce more and more entities that can not be reused we will have the sad end. So I think that it will be better to invent FLEXIBLE journal than reinvent it in each applied protocol. 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. But it's already solved in the pubsub world: we have event delivering system. 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. Sure, the particular conversation will be kept in an one node and
Re: [Standards] Microblogging: XEP-0277 and beyond
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
Re: [Standards] Microblogging: XEP-0277 and beyond
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. 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 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. Justin -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Microblogging: XEP-0277 and beyond
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? 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. 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? Justin
Re: [Standards] Microblogging: XEP-0277 and beyond
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
Re: [Standards] Microblogging: XEP-0277 and beyond
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? 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 still don't understand. You trying to solve problems with extra entities when it should (in my opinion, of course) be solved by some generic pubsub extensions, for example, it could be really usable to store each item version, so you will be able to retrieve any edits of the comment too. But I still consider that activity node is unnecessary and comments node should be in a simple atom format. 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. About post deletion, why to have this notification? Is it not enough to receive a regular retract event? 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 representation. 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=-createdparent_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. It seems so. Justin -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Microblogging: XEP-0277 and beyond
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. So I think the data belongs in a node. Or, we could consider adding notification support for node metadata. 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 still don't understand. You trying to solve problems with extra entities when it should (in my opinion, of course) be solved by some generic pubsub extensions, for example, it could be really usable to store each item version, so you will be able to retrieve any edits of the comment too. But I still consider that activity node is unnecessary and comments node should be in a simple atom format. 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. 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 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
Re: [Standards] Microblogging: XEP-0277 and beyond
On 09/01/2011 03:21 AM, Justin Karneges wrote: On Wednesday, August 31, 2011 11:32:53 AM Sergey Dobrov wrote: IMO, the commenting approach described in XEP-277 is too simple and rather uninspired (full disclaimer: I work at a company whose sole product is commenting). Commenting is similar, but not identical to microblogging, and the two deserve separate specs. Probably the commenting section in XEP-277 should be exchanged with a pointer to XEP-303. I reviewed the XEP-303 and I'm sorry that I did not that before since it has some really significant notices, so I'll do some notes below and maybe you are right with a pointer to XEP-303. Anyway, are you saying that all of the functional requirements of XEP-303 could be extracted out into separate smaller reusable extensions that implementors of generic XEP-60 servers might embrace? Really ejabberd might add an extension that mirrors VCards content in Atom entries? I guess in theory that would be cool, but it seems a bit on the dreamy side. I meant that common cases should be in XEP-60 or some other XEPs that will describe some specific node behavior. For example, I don't sure that this is ok to include filters into the node name (why to url quote these?), but it can be useful to determine some queries protocol which can be inserted in the request of items, so we can use generic pubsub nodes without some functionality. 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? 2) Why to use Activity Streams here? I totally misunderstanding why to have such complication since commenting behavior totally get into simple Atom format. 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. 4) atom:id MUST be an URI. 5) Again, why to url encode a node name? (comments?order=-createdparent_ids=1%2C5a%2Co19g%2C)
Re: [Standards] Microblogging: XEP-0277 and beyond
On 09/02/2011 01:22 AM, Sergey Dobrov wrote: On 09/01/2011 03:21 AM, Justin Karneges wrote: On Wednesday, August 31, 2011 11:32:53 AM Sergey Dobrov wrote: IMO, the commenting approach described in XEP-277 is too simple and rather uninspired (full disclaimer: I work at a company whose sole product is commenting). Commenting is similar, but not identical to microblogging, and the two deserve separate specs. Probably the commenting section in XEP-277 should be exchanged with a pointer to XEP-303. I reviewed the XEP-303 and I'm sorry that I did not that before since it has some really significant notices, so I'll do some notes below and maybe you are right with a pointer to XEP-303. Anyway, are you saying that all of the functional requirements of XEP-303 could be extracted out into separate smaller reusable extensions that implementors of generic XEP-60 servers might embrace? Really ejabberd might add an extension that mirrors VCards content in Atom entries? I guess in theory that would be cool, but it seems a bit on the dreamy side. I meant that common cases should be in XEP-60 or some other XEPs that will describe some specific node behavior. For example, I don't sure that this is ok to include filters into the node name (why to url quote these?), but it can be useful to determine some queries protocol which can be inserted in the request of items, so we can use generic pubsub nodes without some functionality. 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? 2) Why to use Activity Streams here? I totally misunderstanding why to have such complication since commenting behavior totally get into simple Atom format. 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. 4) atom:id MUST be an URI. 5) Again, why to url encode a node name? (comments?order=-createdparent_ids=1%2C5a%2Co19g%2C) I forgot about one thing: I think that this is unnecessary to validate a sender on server side. That is why: I wrote a blog importer from the juick.com microblogging service to my implementation of the XEP-277 based service and when it imports comments it uses fake JIDs but the service sends publisher attribute so it can be validated who exactly sent a comment but it's also possible to make such imports or another pretty things. So I think that validation is unnecessary but publisher attribute usage must be clarified more strictly in the XEP-60.
Re: [Standards] Microblogging: XEP-0277 and beyond
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 representation. 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=-createdparent_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. Justin
Re: [Standards] Microblogging: XEP-0277 and beyond
On 08/31/2011 02:56 AM, Justin Karneges wrote: On Tuesday, August 30, 2011 04:16:29 AM Sergey Dobrov wrote: By dynamic node, I just mean the node can accept parameters when fulfilling requests. I guess you could write some reusable code that marshals the parameters (i.e. popping them off the end of a node name). But, which parameters are possible and how the parameters shall be honored is node-specific, so there's not really much more generic code you can write. Do you mean that pubsub service which serves commenting node should be not a generic pubsub service but some specific? Then, I don't really understand what is necessity of XEP-303 at all. In the XEP-277 is already defined a way how to comment on microblog posts, why not to use the same way, why is needed another entity? Then, some things in XEP-303 are just corrections for XEP-60 which will bring mess in standards and pubsub developers will not know where to find proper specification which will lead to incompatibilities in different pubsub implementation. About dynamic nodes, I think that it's completely unnecessary thing and it's enough to define the way to sort on created or modified time in the XEP-60 itself. But I really afraid about that inconsistency which may be invented with such XEPs as 303 (277 too, he-he). And, maybe it will be useful to make possible to make some hooks on item publishing to validate posted data but that's a subject for another thread. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Microblogging: XEP-0277 and beyond
On Wednesday, August 31, 2011 11:32:53 AM Sergey Dobrov wrote: On 08/31/2011 02:56 AM, Justin Karneges wrote: On Tuesday, August 30, 2011 04:16:29 AM Sergey Dobrov wrote: By dynamic node, I just mean the node can accept parameters when fulfilling requests. I guess you could write some reusable code that marshals the parameters (i.e. popping them off the end of a node name). But, which parameters are possible and how the parameters shall be honored is node-specific, so there's not really much more generic code you can write. Do you mean that pubsub service which serves commenting node should be not a generic pubsub service but some specific? Then, I don't really understand what is necessity of XEP-303 at all. In the XEP-277 is already defined a way how to comment on microblog posts, why not to use the same way, why is needed another entity? Then, some things in XEP-303 are just corrections for XEP-60 which will bring mess in standards and pubsub developers will not know where to find proper specification which will lead to incompatibilities in different pubsub implementation. About dynamic nodes, I think that it's completely unnecessary thing and it's enough to define the way to sort on created or modified time in the XEP-60 itself. But I really afraid about that inconsistency which may be invented with such XEPs as 303 (277 too, he-he). And, maybe it will be useful to make possible to make some hooks on item publishing to validate posted data but that's a subject for another thread. IMO, the commenting approach described in XEP-277 is too simple and rather uninspired (full disclaimer: I work at a company whose sole product is commenting). Commenting is similar, but not identical to microblogging, and the two deserve separate specs. Probably the commenting section in XEP-277 should be exchanged with a pointer to XEP-303. Anyway, are you saying that all of the functional requirements of XEP-303 could be extracted out into separate smaller reusable extensions that implementors of generic XEP-60 servers might embrace? Really ejabberd might add an extension that mirrors VCards content in Atom entries? I guess in theory that would be cool, but it seems a bit on the dreamy side. -Justin
Re: [Standards] Microblogging: XEP-0277 and beyond
On 08/26/2011 01:08 AM, Justin Karneges wrote: On Thursday, August 25, 2011 07:27:16 AM Sergey Dobrov wrote: On 08/25/2011 03:36 AM, Justin Karneges wrote: Yes, if tracking changes is needed then the node should have a way of offering items ordered by modified time. Being able to query for items using different kinds of orderings would be useful though, so I didn't want to stipulate that pubsub with RSM must always be ordered by modified time. Rather, each node would have some sort of natural ordering depending on intended purpose, and if we want the client to be able to select among multiple orderings offered by a node then that would be a separate extension or scheme. Yes, it's sounds ok but what with retracts again? At the moment, I feel this is best done by having a node-specific item format indicating deletion. For Atom-based pubsub nodes, this could be contentless entry. I don't sure that it's fine decision since blank entry is not equal to a retracted item. Anyway, it needs to be described in XEP-60. But I think it would also be good to see about getting retract into the spec for iq exchange. And how I can understand if I missed something and should to re-request items from node? Each pubsub message event should contain two RSM ids: the id of the item contained in the event as well as the id of the item that directly precedes it according to the item ordering. Whether by iq or message, the client would remember the last known RSM id. If a message event is received and the id of preceding item in that message does not match the last id known by the client, then the client can choose to catch up by using iq to fetch items since the last known id. We could use SHIM for this: headers xmlns=http://jabber.org/protocol/shim; header name=RsmId64fc10d2/header header name=PreviousRsmIdf4ac5920/header /headers That is seems to be ok. For example, my XEP-0303 proposes selecting ordering using special node name suffixing, such as ?order=-created to indicate created time descending order. But this is just one way to go about it. I don't have enough time to dive into XEP-303 enough but I don't think that this is a good idea to use dynamic pubsub nodes without separate XEP for it. Again, I don't think that different ordering is really need at this time. Maybe you don't need it, but I need it. :) The commenting protocol requires both created time ordering (for application display render) and modified time ordering (for tracking updates). But, I am open to discussing alternatives that don't involve dynamic node names. But where determined what is dynamic node? How servers can implement it without specification? Justin -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Microblogging: XEP-0277 and beyond
On Tuesday, August 30, 2011 04:16:29 AM Sergey Dobrov wrote: On 08/26/2011 01:08 AM, Justin Karneges wrote: On Thursday, August 25, 2011 07:27:16 AM Sergey Dobrov wrote: On 08/25/2011 03:36 AM, Justin Karneges wrote: For example, my XEP-0303 proposes selecting ordering using special node name suffixing, such as ?order=-created to indicate created time descending order. But this is just one way to go about it. I don't have enough time to dive into XEP-303 enough but I don't think that this is a good idea to use dynamic pubsub nodes without separate XEP for it. Again, I don't think that different ordering is really need at this time. Maybe you don't need it, but I need it. :) The commenting protocol requires both created time ordering (for application display render) and modified time ordering (for tracking updates). But, I am open to discussing alternatives that don't involve dynamic node names. But where determined what is dynamic node? How servers can implement it without specification? By dynamic node, I just mean the node can accept parameters when fulfilling requests. I guess you could write some reusable code that marshals the parameters (i.e. popping them off the end of a node name). But, which parameters are possible and how the parameters shall be honored is node-specific, so there's not really much more generic code you can write. Justin
Re: [Standards] Microblogging: XEP-0277 and beyond
On Wed, 2011-08-24 at 17:34 +0700, Sergey Dobrov wrote: On 08/24/2011 01:38 AM, Justin Karneges wrote: On Tuesday, August 23, 2011 04:34:12 AM Sergey Dobrov wrote: On 08/23/2011 09:14 AM, Justin Karneges wrote: The basic solve for item retraction is for the server to keep deletion markers around. For example the server could clear all content of an item and flag it as deleted, but keep it in the same position in the item list. This way retracted items can be reported in iq responses. That would not work because it is equal to the item update with the blank payload but how could you know that the item was updated? I'm still unsure what you're saying but I'll try to guess: do you mean to say that you cannot determine the difference between a publish vs update, unless you have a local copy of the item to compare with? If so, I have found that in many situations this does not actually matter. Can you share a use case? No, I tell you that even if I will be able to receive items according to the publish time then I can't find if some items was updated before that time. But if it's by modify time then yes, all seems to be ok except of retract. Are you saying here that you want intermediate changes for the same item (i.e. the same ItemID) that took place while the client was not online to receive the notifications? If so, the model in XEP-0060 is that each update to an item is a complete replacement for that item, so a service will not keep record of previous 'versions'. If you really want that you should probably use unique identifiers for each update. In the field of microblogging I don't see a particular use case for this. Microblog entries typically don't change once posted, and even if they would, an end-user would probably only be interested in the most recent version. For more expanded use cases in Federating Social Networks (beyond microblogs) that cover other social objects (regular blogs, stories, pictures, people's profiles) updates are more common. Let me expand on a real-world example. At Mediamatic we've built a network of sites that federate using (amongst others) XMPP PubSub. The sites are basically collections of Things that have relationships or Edges between them, with a particular predicate. Very semantic web, RDF-like. For exchanging Things, we make an Atom representation of the Thing with all of its 'outgoing' Edges, encoded as link/ elements. (Example: http://www.mediamatic.net/atom/24879). Each Thing has its own node (xmpp:pubsub.mediamatic.net?;node=id/24879). In this setting, for each update (changed title, new relationships) we just push the whole representation to the subscribing sites (ItemID 'current'). Upon reception, the local shadow representation is entirely replaced with the version just received. We did think about sending around delta's at some point, especially for edge updates, because the pings are really fat. Up till now, we haven't pursued this because it makes the operation more fragile. If you missed an update, you have to figure what you've missed, likely by replaying a journal. Alternatively, I could think of having a more explicit subscription, where you have the publishing service filter out certain bits (unwanted edges with particular predicates) in the Atom in the notification, and only send updates for 'fields' you are interested in. We also played with the thought of having separate items for derived (meta) data for each thing. These could hold information on the amount of comments, likes, visits and various 'ratings', that you might want to show on the federated sites. We haven't pursued this mostly because lack of time. I'm also not sure about how to encode this information, as items in a node typically have their payload in the same namespace. Encoding this meta data in Atom might be somewhat of an overkill. From my point of view, the best solution is node journal but I can't be sure since that idea was not discussed. True. I am trying to avoid this if possible. 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. I don't insist on journal, I just need a reliable way to retrieve node changes and I can't think up another way. In our case, we don't retract items, but do send node deletes (sometimes with a redirected to another Thing, when there was a move between sites or two things have been consolidated into one). I suppose that wouldn't work nicely in your setting, because all of our subscriptions are explicit. We do have something akin to collections or 'generic subscriptions', which act more like an Atom Feed. There we create or update items based on the atom:id inside the payloads, and don't actually look at the ItemID. Deletes are not published in this setting, but this could probably be done by doing an explicit
Re: [Standards] Microblogging: XEP-0277 and beyond
On 08/25/2011 03:36 AM, Justin Karneges wrote: On Wednesday, August 24, 2011 03:34:27 AM Sergey Dobrov wrote: On 08/24/2011 01:38 AM, Justin Karneges wrote: On Tuesday, August 23, 2011 04:34:12 AM Sergey Dobrov wrote: On 08/23/2011 09:14 AM, Justin Karneges wrote: The basic solve for item retraction is for the server to keep deletion markers around. For example the server could clear all content of an item and flag it as deleted, but keep it in the same position in the item list. This way retracted items can be reported in iq responses. That would not work because it is equal to the item update with the blank payload but how could you know that the item was updated? I'm still unsure what you're saying but I'll try to guess: do you mean to say that you cannot determine the difference between a publish vs update, unless you have a local copy of the item to compare with? If so, I have found that in many situations this does not actually matter. Can you share a use case? No, I tell you that even if I will be able to receive items according to the publish time then I can't find if some items was updated before that time. But if it's by modify time then yes, all seems to be ok except of retract. Yes, if tracking changes is needed then the node should have a way of offering items ordered by modified time. Being able to query for items using different kinds of orderings would be useful though, so I didn't want to stipulate that pubsub with RSM must always be ordered by modified time. Rather, each node would have some sort of natural ordering depending on intended purpose, and if we want the client to be able to select among multiple orderings offered by a node then that would be a separate extension or scheme. Yes, it's sounds ok but what with retracts again? And how I can understand if I missed something and should to re-request items from node? For example, my XEP-0303 proposes selecting ordering using special node name suffixing, such as ?order=-created to indicate created time descending order. But this is just one way to go about it. I don't have enough time to dive into XEP-303 enough but I don't think that this is a good idea to use dynamic pubsub nodes without separate XEP for it. Again, I don't think that different ordering is really need at this time. Justin -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Microblogging: XEP-0277 and beyond
On Thursday, August 25, 2011 07:27:16 AM Sergey Dobrov wrote: On 08/25/2011 03:36 AM, Justin Karneges wrote: Yes, if tracking changes is needed then the node should have a way of offering items ordered by modified time. Being able to query for items using different kinds of orderings would be useful though, so I didn't want to stipulate that pubsub with RSM must always be ordered by modified time. Rather, each node would have some sort of natural ordering depending on intended purpose, and if we want the client to be able to select among multiple orderings offered by a node then that would be a separate extension or scheme. Yes, it's sounds ok but what with retracts again? At the moment, I feel this is best done by having a node-specific item format indicating deletion. For Atom-based pubsub nodes, this could be contentless entry. But I think it would also be good to see about getting retract into the spec for iq exchange. And how I can understand if I missed something and should to re-request items from node? Each pubsub message event should contain two RSM ids: the id of the item contained in the event as well as the id of the item that directly precedes it according to the item ordering. Whether by iq or message, the client would remember the last known RSM id. If a message event is received and the id of preceding item in that message does not match the last id known by the client, then the client can choose to catch up by using iq to fetch items since the last known id. We could use SHIM for this: headers xmlns=http://jabber.org/protocol/shim; header name=RsmId64fc10d2/header header name=PreviousRsmIdf4ac5920/header /headers For example, my XEP-0303 proposes selecting ordering using special node name suffixing, such as ?order=-created to indicate created time descending order. But this is just one way to go about it. I don't have enough time to dive into XEP-303 enough but I don't think that this is a good idea to use dynamic pubsub nodes without separate XEP for it. Again, I don't think that different ordering is really need at this time. Maybe you don't need it, but I need it. :) The commenting protocol requires both created time ordering (for application display render) and modified time ordering (for tracking updates). But, I am open to discussing alternatives that don't involve dynamic node names. Justin
Re: [Standards] Microblogging: XEP-0277 and beyond
On 08/24/2011 01:38 AM, Justin Karneges wrote: On Tuesday, August 23, 2011 04:34:12 AM Sergey Dobrov wrote: On 08/23/2011 09:14 AM, Justin Karneges wrote: The basic solve for item retraction is for the server to keep deletion markers around. For example the server could clear all content of an item and flag it as deleted, but keep it in the same position in the item list. This way retracted items can be reported in iq responses. That would not work because it is equal to the item update with the blank payload but how could you know that the item was updated? I'm still unsure what you're saying but I'll try to guess: do you mean to say that you cannot determine the difference between a publish vs update, unless you have a local copy of the item to compare with? If so, I have found that in many situations this does not actually matter. Can you share a use case? No, I tell you that even if I will be able to receive items according to the publish time then I can't find if some items was updated before that time. But if it's by modify time then yes, all seems to be ok except of retract. From my point of view, the best solution is node journal but I can't be sure since that idea was not discussed. True. I am trying to avoid this if possible. 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. I don't insist on journal, I just need a reliable way to retrieve node changes and I can't think up another way. Justin -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Microblogging: XEP-0277 and beyond
On Wednesday, August 24, 2011 03:34:27 AM Sergey Dobrov wrote: On 08/24/2011 01:38 AM, Justin Karneges wrote: On Tuesday, August 23, 2011 04:34:12 AM Sergey Dobrov wrote: On 08/23/2011 09:14 AM, Justin Karneges wrote: The basic solve for item retraction is for the server to keep deletion markers around. For example the server could clear all content of an item and flag it as deleted, but keep it in the same position in the item list. This way retracted items can be reported in iq responses. That would not work because it is equal to the item update with the blank payload but how could you know that the item was updated? I'm still unsure what you're saying but I'll try to guess: do you mean to say that you cannot determine the difference between a publish vs update, unless you have a local copy of the item to compare with? If so, I have found that in many situations this does not actually matter. Can you share a use case? No, I tell you that even if I will be able to receive items according to the publish time then I can't find if some items was updated before that time. But if it's by modify time then yes, all seems to be ok except of retract. Yes, if tracking changes is needed then the node should have a way of offering items ordered by modified time. Being able to query for items using different kinds of orderings would be useful though, so I didn't want to stipulate that pubsub with RSM must always be ordered by modified time. Rather, each node would have some sort of natural ordering depending on intended purpose, and if we want the client to be able to select among multiple orderings offered by a node then that would be a separate extension or scheme. For example, my XEP-0303 proposes selecting ordering using special node name suffixing, such as ?order=-created to indicate created time descending order. But this is just one way to go about it. Justin
Re: [Standards] Microblogging: XEP-0277 and beyond
On 08/23/2011 09:14 AM, Justin Karneges wrote: On Monday, August 22, 2011 05:12:54 AM Sergey Dobrov wrote: On 08/19/2011 04:55 AM, Justin Karneges wrote: On Thursday, August 18, 2011 05:10:58 AM Goffi wrote: - the ability to get missed items between the last time a contact was disconnected and the time it reconnect I have a protocol flow for reliable pubsub that I've not yet publicized, but essentially the idea is to include Result Set Management (XEP-0059) UID values in pubsub event notifications. The client can then notice if it missed an item and use iq-get to catch up. Maybe this could go in some RSM with PubSub XEP that sorely needs to be written. Justin You forgot that we need to know about item retraction as well as about item publishing. The same thing about item update. The possibility to get items by date and time is good but it's not cover these problems and it's not necessary at this time from my point of view. The basic solve for item retraction is for the server to keep deletion markers around. For example the server could clear all content of an item and flag it as deleted, but keep it in the same position in the item list. This way retracted items can be reported in iq responses. That would not work because it is equal to the item update with the blank payload but how could you know that the item was updated? Unfortunately XEP-0060 never discusses sending retract in an iq response where item normally is, so I am not sure if this would be allowed today without a protocol update. Alternatively, retractions could be represented within the items themselves. For example if you were using Atom, an empty entry element may suffice to indicate deletion. Protocol needs many edits anyway. For example, it very useful to see a publisher of an item but XEP-60 doesn't give us good explanation how to determine if pubsub service can send such notifications. Item publish and update are fine though, right? Or what are you thinking about them? Publish is ok since we have RSM. Update has the same problem as retract. From my point of view, the best solution is node journal but I can't be sure since that idea was not discussed. Justin -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Microblogging: XEP-0277 and beyond
On 8/21/11 4:45 PM, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: Good catch, I didn't consider clock skew. I wonder if the client should just specify a timestamp 5-10m in the past instead of having magic at the node servers. Then accurate time queries (made relative to timestamps of other items provided by the server) stay optimized. Seems to me that client writers are more likely to incorrectly think the server clock is going to be right than the other way around, but I don't care where the skew is added as long as it's specified which side does it, so we don't double-skew. -- Joe Hildebrand
Re: [Standards] Microblogging: XEP-0277 and beyond
On 8/22/11 8:14 PM, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: The basic solve for item retraction is for the server to keep deletion markers around. For example the server could clear all content of an item and flag it as deleted, but keep it in the same position in the item list. This way retracted items can be reported in iq responses. Unfortunately XEP-0060 never discusses sending retract in an iq response where item normally is, so I am not sure if this would be allowed today without a protocol update. Alternatively, retractions could be represented within the items themselves. For example if you were using Atom, an empty entry element may suffice to indicate deletion. Item publish and update are fine though, right? Or what are you thinking about them? I was hoping for something more like atomic-subscribe-and-send-updates as a subscription option, so that the client's notification handling didn't have to change. The server could then just send normal retracts in that flow. If there was another subscription option that says it's ok to send me multiple notifications in the same message, the server could intelligently batch the notifications together for clients that have added the extra foreach loop. -- Joe Hildebrand
Re: [Standards] Microblogging: XEP-0277 and beyond
On Tuesday, August 23, 2011 04:34:12 AM Sergey Dobrov wrote: On 08/23/2011 09:14 AM, Justin Karneges wrote: The basic solve for item retraction is for the server to keep deletion markers around. For example the server could clear all content of an item and flag it as deleted, but keep it in the same position in the item list. This way retracted items can be reported in iq responses. That would not work because it is equal to the item update with the blank payload but how could you know that the item was updated? I'm still unsure what you're saying but I'll try to guess: do you mean to say that you cannot determine the difference between a publish vs update, unless you have a local copy of the item to compare with? If so, I have found that in many situations this does not actually matter. Can you share a use case? From my point of view, the best solution is node journal but I can't be sure since that idea was not discussed. True. I am trying to avoid this if possible. 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. Justin
Re: [Standards] Microblogging: XEP-0277 and beyond
On 08/19/2011 04:55 AM, Justin Karneges wrote: On Thursday, August 18, 2011 05:10:58 AM Goffi wrote: - the ability to get missed items between the last time a contact was disconnected and the time it reconnect I have a protocol flow for reliable pubsub that I've not yet publicized, but essentially the idea is to include Result Set Management (XEP-0059) UID values in pubsub event notifications. The client can then notice if it missed an item and use iq-get to catch up. Maybe this could go in some RSM with PubSub XEP that sorely needs to be written. Justin You forgot that we need to know about item retraction as well as about item publishing. The same thing about item update. The possibility to get items by date and time is good but it's not cover these problems and it's not necessary at this time from my point of view. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Microblogging: XEP-0277 and beyond
On 08/18/2011 09:47 PM, Goffi wrote: Le Jeudi 18 Août 2011 20:40:05, Sergey Dobrov a écrit : It's a bad idea to append the number to the namespace since it reserved for different revisions of XEP and not for your purpose. Again, I think that this should be solved by some privacy lists extension since your decision again restricted. As I said before, it just a QD hack for testing purpose, I know it's not a good solution. I would rather use privacy lists or whatever if we could have a per-item access management with it. But you should understand that this standard can be proposed only if the basic microblogging will work well. If I have to poll this by myself at client side, I'll have to send X IQ stanza for my X contacts, and flood the server. Client should cache data. You will flood anyway the only difference is who will flood: client or server. In all cases the client will need the data, and it's better to send one request to server, that X request for X contacts. Actually I think about something similar to Extended Stanza Adressing (http://xmpp.org/extensions/xep-0033.html), but to get several pubsub nodes at once. XEP-33 is good but it can't be used for iq stanzas... I ask last items presence to not have to poll individually all my contacts roster. On some blue centralised services, it's common to have 100+ contacts, should I poll all of them each time I log-in ? No, Pubsub node can send you an event when you came online with the serial for it's journal so you can decide to ask the node for new items. Oki, that looks like a nice solution, once again, waiting an answer from pubsub people. It seems that the only way is to design a prototype for the XEP and publish it... -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Microblogging: XEP-0277 and beyond
On Monday, August 22, 2011 05:12:54 AM Sergey Dobrov wrote: On 08/19/2011 04:55 AM, Justin Karneges wrote: On Thursday, August 18, 2011 05:10:58 AM Goffi wrote: - the ability to get missed items between the last time a contact was disconnected and the time it reconnect I have a protocol flow for reliable pubsub that I've not yet publicized, but essentially the idea is to include Result Set Management (XEP-0059) UID values in pubsub event notifications. The client can then notice if it missed an item and use iq-get to catch up. Maybe this could go in some RSM with PubSub XEP that sorely needs to be written. Justin You forgot that we need to know about item retraction as well as about item publishing. The same thing about item update. The possibility to get items by date and time is good but it's not cover these problems and it's not necessary at this time from my point of view. The basic solve for item retraction is for the server to keep deletion markers around. For example the server could clear all content of an item and flag it as deleted, but keep it in the same position in the item list. This way retracted items can be reported in iq responses. Unfortunately XEP-0060 never discusses sending retract in an iq response where item normally is, so I am not sure if this would be allowed today without a protocol update. Alternatively, retractions could be represented within the items themselves. For example if you were using Atom, an empty entry element may suffice to indicate deletion. Item publish and update are fine though, right? Or what are you thinking about them? Justin
Re: [Standards] Microblogging: XEP-0277 and beyond
On Saturday, August 20, 2011 12:11:05 AM Joe Hildebrand wrote: On 8/19/11 12:12 PM, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: Indeed. In my case I consider a time-based query to be inclusive, so as to not miss updates occuring within the same second. In the rare case you pick up the same item again, it's harmless. I'd go a little further, and suggest that the publishing server should back up enough time to account for clock skew, and republish everything from that earlier time. 5-10m should do it, as long as there aren't a lot of items. Good catch, I didn't consider clock skew. I wonder if the client should just specify a timestamp 5-10m in the past instead of having magic at the node servers. Then accurate time queries (made relative to timestamps of other items provided by the server) stay optimized. Justin
Re: [Standards] Microblogging: XEP-0277 and beyond
On 8/19/11 12:12 PM, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: In the context of PEP, it would just be a matter of putting this same type of position spec into the subscription request, and then each remote node would reply with all items since that time (or just the one item only if it has changed, I think PEP is always singleton?). There's no reason PEP is always a singleton. If the publisher wants singleton, she uses id='current'. Indeed. In my case I consider a time-based query to be inclusive, so as to not miss updates occuring within the same second. In the rare case you pick up the same item again, it's harmless. I'd go a little further, and suggest that the publishing server should back up enough time to account for clock skew, and republish everything from that earlier time. 5-10m should do it, as long as there aren't a lot of items. -- Joe Hildebrand
Re: [Standards] Microblogging: XEP-0277 and beyond
On 8/18/11 2:55 PM, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: I have a protocol flow for reliable pubsub that I've not yet publicized, but essentially the idea is to include Result Set Management (XEP-0059) UID values in pubsub event notifications. The client can then notice if it missed an item and use iq-get to catch up. Maybe this could go in some RSM with PubSub XEP that sorely needs to be written. I like the direction you're heading with this. While we're at it, we need something similar for PEP that uses date/timestamps on implicit subscribes, since one implicit subscription goes to multiple publishing nodes, each of which have different RSM ids. The hope is that you could cache between sessions, and only receive PEP updates for things that have changed. This would be a huge win for XEP-292 PEP-based vCard, particularly if avatars are included. One thing we have going for us is that a re-publish of an existing item (by id) replaces the previous version, so a little bit of overlap between sessions is ok If there's any way to incorporate that into your thinking so we end up with a consistent design, it would be cool. -- Joe Hildebrand
[Standards] Microblogging: XEP-0277 and beyond
G'day everybody, as it is my first post on @standard, I just quickly present myself: I'm the developper of Salut à Toi, a multi-frontend XMPP client (you can have a presentation here == http://www.goffi.org/post/2011/06/05/Salut-%C3%A0-Toi%3A- a-multi-frontends-XMPP-client ). My client use microblogging, and I have an implementation of XEP-0277 on it (with a dirty custom hack to have several roster-access nodes), which was made before the replies/comments update. first, here are my main needs for microblogging: - the possibility to have several nodes with different access models, and for a user to subscribe to them automatically - the possibility to pull all items of severals peoples (e.g. a roster group) at once - push notification when a contact is connected - the ability to get missed items between the last time a contact was disconnected and the time it reconnect The current XEP is based on PEP, and has IMHO many issues: - if you connect with +notify, you have all notifications from all you items, without the ability to filter (e.g. from only on group). - if somebody published an item 6 months ago, and nothing since, you'll still have it in your notifications. OK you can filter this at client side, but it would be nice to have a date-based filtering way. - maybe the most important: there is no way to know how many items you have missed neither to get them. Once again, a date-based retrieving way would be a nice addition - there is no way to retrieve the x last items for x contacts. I'd like to be able to ask to a server « all the post since 1 week from all my contacts in roster-group friends ». I have heard about the buddycloud draft on the subject: https://buddycloud.org/wiki/XMPP_XEP , and I think there are good ideas there, like using Message Archive Management ( http://doomsong.co.uk/extensions/render/message-archive-management.html ) for the date-based retrieving. Furthermore, there is this email from Sergey Dobrov that has not any answer: http://mail.jabber.org/pipermail/standards/2011-June/024618.html . It's a pity 'cause there are many interesting remarks in it. For example, I agree that adding tags would be nice, or the need to have a way to get items count. I think it's important to focus on microblogging, as it become more and more common these days. I also think that roster-access need special attention, specially in server side: it's important to have permission management easy for the end-user. Cheers Jérôme Poisson (aka Goffi) PS: I have also worked on features for my client that I'd like to standardize, like a generic card games management.
Re: [Standards] Microblogging: XEP-0277 and beyond
On 08/18/2011 07:10 PM, Goffi wrote: G'day everybody, as it is my first post on @standard, I just quickly present myself: I'm the developper of Salut à Toi, a multi-frontend XMPP client (you can have a presentation here == http://www.goffi.org/post/2011/06/05/Salut-%C3%A0-Toi%3A- a-multi-frontends-XMPP-client ). My client use microblogging, and I have an implementation of XEP-0277 on it (with a dirty custom hack to have several roster-access nodes), which was made before the replies/comments update. first, here are my main needs for microblogging: - the possibility to have several nodes with different access models, and for a user to subscribe to them automatically Could you give some example usecases for that? Since I don't really understand how you see it possible. - the possibility to pull all items of severals peoples (e.g. a roster group) at once That impossible since these users can be served on different hosts. So you should to ask users separately. I don't think that this is too ambiguous because it will be needed only once and then you will receive events immediately. - push notification when a contact is connected Presence?? :)) - the ability to get missed items between the last time a contact was disconnected and the time it reconnect I already proposed the solution for that but nobody reacted: http://mail.jabber.org/pipermail/standards/2011-June/024597.html The current XEP is based on PEP, and has IMHO many issues: - if you connect with +notify, you have all notifications from all you items, without the ability to filter (e.g. from only on group). I think that this issue can be solved with an extension for the privacy lists. - if somebody published an item 6 months ago, and nothing since, you'll still have it in your notifications. OK you can filter this at client side, but it would be nice to have a date-based filtering way. Why? I configure the node that it doesn't send last items when presence came and this is quite ok. - maybe the most important: there is no way to know how many items you have missed neither to get them. Once again, a date-based retrieving way would be a nice addition Once again: http://mail.jabber.org/pipermail/standards/2011-June/024597.html - there is no way to retrieve the x last items for x contacts. I'd like to be able to ask to a server « all the post since 1 week from all my contacts in roster-group friends ». You are forget about decentralization again. Again, why is this needed if you receive the events IMMEDIATELY? I have heard about the buddycloud draft on the subject: https://buddycloud.org/wiki/XMPP_XEP , and I think there are good ideas there, like using Message Archive Management ( http://doomsong.co.uk/extensions/render/message-archive-management.html ) for the date-based retrieving. I think that this feature can be omitted for the first time since it can be solved more easily. Furthermore, there is this email from Sergey Dobrov that has not any answer: http://mail.jabber.org/pipermail/standards/2011-June/024618.html . It's a pity 'cause there are many interesting remarks in it. For example, I agree that adding tags would be nice, or the need to have a way to get items count. I working to integrate these edits by myself and propose to accept the new version since it seems that nobody if not me. I think it's important to focus on microblogging, as it become more and more common these days. I also think that roster-access need special attention, specially in server side: it's important to have permission management easy for the end-user. That's ok but I think that we should work on independent solution that keeps in mind our own way (decentralized, flexibility, restrictions absence). Cheers Jérôme Poisson (aka Goffi) PS: I have also worked on features for my client that I'd like to standardize, like a generic card games management. Great thing! -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Microblogging: XEP-0277 and beyond
Le Jeudi 18 Août 2011 19:29:21, Sergey Dobrov a écrit : first, here are my main needs for microblogging: - the possibility to have several nodes with different access models, and for a user to subscribe to them automatically Could you give some example usecases for that? Since I don't really understand how you see it possible. Well, in my quick and dirty implementation (that I have made mainly to work on the frontend), I have several node: urn:xmpp:microblog:0 for the main microblog node, open access, that everybody can read, even people without XMPP account from the website. Then I have many other nodes: urn:xmpp:microblog:1, urn:xmpp:microblog:2, ... Each node has a different access (roster-access familly, roster-access friends), and I have an other private node (with a whitelist access for only the published) which keep a map between my roster-group and the node, so only the published know that urn:xmpp:microblog:1 is linked with familly roster group. Thanks to this map, I can publish to the good node when needed. My contacts have a notification because they have discovery feature for urn:xmpp:microblog:1+notify, urn:xmpp:microblog:2+notify, ..., urn:xmpp:microblog:big_enough_number+notify (BTW, it would be nice to have some wildcard charactere like urn:xmpp:microblog:*+notify), and thanks to access model, then just have notifications if they are in the good group. This implementation is a dirty hack, but it works at least for testing purpose. It would be actually not that bad if I could ask the server all the items (or the last x ones) that I could access from a given jid. You can try it at www.libervia.org (very old interface, a new one is on its way), but you'll have to create several accounts and play with roster to test it. - the possibility to pull all items of severals peoples (e.g. a roster group) at once That impossible since these users can be served on different hosts. So you should to ask users separately. I don't think that this is too ambiguous because it will be needed only once and then you will receive events immediately. I know that of course, but I think it's server job. A server can host many of my contacts nodes, so it can at least return the ones it is hosting, and then ask to other servers the informations it is lacking. At client side, that mean just on IQ get stanza, then having the result, which can be huge so maybe splitted in several stanza. If I have to poll this by myself at client side, I'll have to send X IQ stanza for my X contacts, and flood the server. - push notification when a contact is connected Presence?? :)) Yes this point is already managed in xep-0277, I just mentionned it cause it's a must-have. - the ability to get missed items between the last time a contact was disconnected and the time it reconnect I already proposed the solution for that but nobody reacted: http://mail.jabber.org/pipermail/standards/2011-June/024597.html Yes I know, so I hope this time there will be more feedback The current XEP is based on PEP, and has IMHO many issues: - if you connect with +notify, you have all notifications from all you items, without the ability to filter (e.g. from only on group). I think that this issue can be solved with an extension for the privacy lists. I agree - if somebody published an item 6 months ago, and nothing since, you'll still have it in your notifications. OK you can filter this at client side, but it would be nice to have a date-based filtering way. Why? I configure the node that it doesn't send last items when presence came and this is quite ok. I ask last items presence to not have to poll individually all my contacts roster. On some blue centralised services, it's common to have 100+ contacts, should I poll all of them each time I log-in ? - maybe the most important: there is no way to know how many items you have missed neither to get them. Once again, a date-based retrieving way would be a nice addition Once again: http://mail.jabber.org/pipermail/standards/2011-June/024597.html Hope to have feedback from pubsub specialists - there is no way to retrieve the x last items for x contacts. I'd like to be able to ask to a server « all the post since 1 week from all my contacts in roster-group friends ». You are forget about decentralization again. Again, why is this needed if you receive the events IMMEDIATELY? Because I'm not always online. For the decentralized issue, see my answer above. [SNIP] Furthermore, there is this email from Sergey Dobrov that has not any answer: http://mail.jabber.org/pipermail/standards/2011-June/024618.html . It's a pity 'cause there are many interesting remarks in it. For example, I agree that adding tags would be nice, or the need to have a way to get items count. I working to integrate these edits by myself and propose to accept the new version since it seems that
Re: [Standards] Microblogging: XEP-0277 and beyond
On 08/18/2011 08:09 PM, Goffi wrote: Le Jeudi 18 Août 2011 19:29:21, Sergey Dobrov a écrit : first, here are my main needs for microblogging: - the possibility to have several nodes with different access models, and for a user to subscribe to them automatically Could you give some example usecases for that? Since I don't really understand how you see it possible. Well, in my quick and dirty implementation (that I have made mainly to work on the frontend), I have several node: urn:xmpp:microblog:0 for the main microblog node, open access, that everybody can read, even people without XMPP account from the website. Then I have many other nodes: urn:xmpp:microblog:1, urn:xmpp:microblog:2, ... Each node has a different access (roster-access familly, roster-access friends), and I have an other private node (with a whitelist access for only the published) which keep a map between my roster-group and the node, so only the published know that urn:xmpp:microblog:1 is linked with familly roster group. Thanks to this map, I can publish to the good node when needed. My contacts have a notification because they have discovery feature for urn:xmpp:microblog:1+notify, urn:xmpp:microblog:2+notify, ..., urn:xmpp:microblog:big_enough_number+notify (BTW, it would be nice to have some wildcard charactere like urn:xmpp:microblog:*+notify), and thanks to access model, then just have notifications if they are in the good group. This implementation is a dirty hack, but it works at least for testing purpose. It would be actually not that bad if I could ask the server all the items (or the last x ones) that I could access from a given jid. You can try it at www.libervia.org (very old interface, a new one is on its way), but you'll have to create several accounts and play with roster to test it. It's a bad idea to append the number to the namespace since it reserved for different revisions of XEP and not for your purpose. Again, I think that this should be solved by some privacy lists extension since your decision again restricted. - the possibility to pull all items of severals peoples (e.g. a roster group) at once That impossible since these users can be served on different hosts. So you should to ask users separately. I don't think that this is too ambiguous because it will be needed only once and then you will receive events immediately. I know that of course, but I think it's server job. A server can host many of my contacts nodes, so it can at least return the ones it is hosting, and then ask to other servers the informations it is lacking. At client side, that mean just on IQ get stanza, then having the result, which can be huge so maybe splitted in several stanza. If I have to poll this by myself at client side, I'll have to send X IQ stanza for my X contacts, and flood the server. Client should cache data. You will flood anyway the only difference is who will flood: client or server. - push notification when a contact is connected Presence?? :)) Yes this point is already managed in xep-0277, I just mentionned it cause it's a must-have. - the ability to get missed items between the last time a contact was disconnected and the time it reconnect I already proposed the solution for that but nobody reacted: http://mail.jabber.org/pipermail/standards/2011-June/024597.html Yes I know, so I hope this time there will be more feedback The current XEP is based on PEP, and has IMHO many issues: - if you connect with +notify, you have all notifications from all you items, without the ability to filter (e.g. from only on group). I think that this issue can be solved with an extension for the privacy lists. I agree - if somebody published an item 6 months ago, and nothing since, you'll still have it in your notifications. OK you can filter this at client side, but it would be nice to have a date-based filtering way. Why? I configure the node that it doesn't send last items when presence came and this is quite ok. I ask last items presence to not have to poll individually all my contacts roster. On some blue centralised services, it's common to have 100+ contacts, should I poll all of them each time I log-in ? No, Pubsub node can send you an event when you came online with the serial for it's journal so you can decide to ask the node for new items. - maybe the most important: there is no way to know how many items you have missed neither to get them. Once again, a date-based retrieving way would be a nice addition Once again: http://mail.jabber.org/pipermail/standards/2011-June/024597.html Hope to have feedback from pubsub specialists Me too :) - there is no way to retrieve the x last items for x contacts. I'd like to be able to ask to a server « all the post since 1 week from all my contacts in roster-group friends ». You are forget about decentralization again.
Re: [Standards] Microblogging: XEP-0277 and beyond
Le Jeudi 18 Août 2011 20:40:05, Sergey Dobrov a écrit : It's a bad idea to append the number to the namespace since it reserved for different revisions of XEP and not for your purpose. Again, I think that this should be solved by some privacy lists extension since your decision again restricted. As I said before, it just a QD hack for testing purpose, I know it's not a good solution. I would rather use privacy lists or whatever if we could have a per-item access management with it. If I have to poll this by myself at client side, I'll have to send X IQ stanza for my X contacts, and flood the server. Client should cache data. You will flood anyway the only difference is who will flood: client or server. In all cases the client will need the data, and it's better to send one request to server, that X request for X contacts. Actually I think about something similar to Extended Stanza Adressing (http://xmpp.org/extensions/xep-0033.html), but to get several pubsub nodes at once. I ask last items presence to not have to poll individually all my contacts roster. On some blue centralised services, it's common to have 100+ contacts, should I poll all of them each time I log-in ? No, Pubsub node can send you an event when you came online with the serial for it's journal so you can decide to ask the node for new items. Oki, that looks like a nice solution, once again, waiting an answer from pubsub people.
Re: [Standards] Microblogging: XEP-0277 and beyond
It's my understanding of the XEP process that we standardise ways of doing something so that many clients and servers can interoperate. And for machine to machine services this is easy: machines do as we say and interoperate as we say. It's a predictable environment. Social is not easy and neither are user and groups of users predictable. Additionally, social services built on XMPP will have different business logic and be built into different applications in different ways. Getting this business-logic right will depend on the problem being solved. That's why I like XEP-0277; it says all one can really say about social (summary of XEP-0277: use atom for posts and post to a pub-sub like node). We all want interoperation between services. Social is different for different products: what works for one kind of use case will not work for someone else: some people think it should be roster based with groups like Google circles. Others want it decoupled from the roster. Some people want to add code to XMPP servers, others build pub-sub solutions. Some services have a single poster model, others are more like MUC with many posters. To help make this conversation go forward we need a solid description of what is being offered to the user. These are the questions we need to answer before we try to work out a spec(s): * the target user (hint: my parents won't be twiddling roster groups) * define the use case * how does it work? what happens when... (this is the social part) * clearly define the publishing and following models I am extremely doubtful that this process leads to a one-size-fits-all answer. And it would be a rather mediocre mishmash of kludges. I think a far more realistic result will be a couple of types of social services. Off the top of my head: * microblogging to pep nodes * twitter-like service * buddycloud-like service Each service (and hopefully spec) will relevant to a particular way of interacting and designed for a type of use case. It's really important that we avoid a rush to standardise that results in something mediocre and end up with the MySpace of the XMPP world: dropped after 2 years and filled with spam. XMPP gives us a huge advantage when building social services: its native federation and its built-in support for remote user-ids are awesome. Let's build awesome services for our users based off specs relevant for a particular use case. S. On 18/08/2011 16:47, Goffi wrote: Le Jeudi 18 Août 2011 20:40:05, Sergey Dobrov a écrit : It's a bad idea to append the number to the namespace since it reserved for different revisions of XEP and not for your purpose. Again, I think that this should be solved by some privacy lists extension since your decision again restricted. As I said before, it just a QD hack for testing purpose, I know it's not a good solution. I would rather use privacy lists or whatever if we could have a per-item access management with it. If I have to poll this by myself at client side, I'll have to send X IQ stanza for my X contacts, and flood the server. Client should cache data. You will flood anyway the only difference is who will flood: client or server. In all cases the client will need the data, and it's better to send one request to server, that X request for X contacts. Actually I think about something similar to Extended Stanza Adressing (http://xmpp.org/extensions/xep-0033.html), but to get several pubsub nodes at once. I ask last items presence to not have to poll individually all my contacts roster. On some blue centralised services, it's common to have 100+ contacts, should I poll all of them each time I log-in ? No, Pubsub node can send you an event when you came online with the serial for it's journal so you can decide to ask the node for new items. Oki, that looks like a nice solution, once again, waiting an answer from pubsub people. -- Simon Tennant mobile: +49 17 8545 0880 office: +49 89 4209 55854 office: +44 20 7043 6756 xmpp: si...@buddycloud.com build your own open and federated social network - http://open.buddycloud.com
Re: [Standards] Microblogging: XEP-0277 and beyond
On Thursday, August 18, 2011 05:10:58 AM Goffi wrote: - the ability to get missed items between the last time a contact was disconnected and the time it reconnect I have a protocol flow for reliable pubsub that I've not yet publicized, but essentially the idea is to include Result Set Management (XEP-0059) UID values in pubsub event notifications. The client can then notice if it missed an item and use iq-get to catch up. Maybe this could go in some RSM with PubSub XEP that sorely needs to be written. Justin
[Standards] Microblogging XEP new features
Hi, I am the Jappix project founder (https://www.jappix.com/ - https://project.jappix.com/ - https://mini.jappix.com), and we added full microblogging XEP (XEP-0277) support to our webclient (desktop edition). Here are some enhences of the XEP we did, which are working very fine! *1. File attachment* We had a strong need during its integration: the multiple/single file(s) attachment, like Identi.ca does in its protocol. We built a simple way (maybe not the best?!) to do this, with a file / element (can be multiple if more than one file per item). *2. Entry repeat* When someone repeat a friend's entry, we could specify it to the new posted item. We added a repeat / element to the source / one, with the jid attribute of the initial entry. *3. Comments* To allow users reacting to one's entry, we added a commenting feature. For that, we use a comments / element, wich specifies where is the comments node located (PubSub server/PEP + node name). Would it be possible to add this to the XEP draft, or to enhence this structure if bad? It looks like this: items node=urn:xmpp:microblog:0 item id=b7cfa299c9263eb218863362762c0e26 entry xmlns=http://www.w3.org/2005/Atom; source titleMicroblog (Vanaryon)/title updated2011-03-13T15:52:45Z/updated author nickVanaryon/nick /author *repeat jid=vanar...@jappix.com /* /source titleEspérons que le salon du jeu vidéo Breton sera meilleur l'année prochaine :(/title bodyEspérons que le salon du jeu vidéo Breton sera meilleur l'année prochaine :(/body published2011-03-13T15:52:45Z/published updated2011-03-13T15:52:45Z/updated link href= xmpp:vanar...@jappix.com?;node=urn%3Axmpp%3Amicroblog%3A0;item=b7cfa299c9263eb218863362762c0e26 rel=alternate * **file name=IMAG0090 url= https://www.jappix.com/store/share/vanar...@jappix.com/76cc121cab14443c1d6ffe046443dfd1d856940b.jpg; source=web ext=jpg type=image thumb= https://www.jappix.com/store/share/vanar...@jappix.com/76cc121cab14443c1d6ffe046443dfd1d856940b_thumb.jpg; / file name=IMAG0093 url= https://www.jappix.com/store/share/vanar...@jappix.com/bdc11f42e0c1d810b33733689f6cfd7a9197c9e0.jpg; source=web ext=jpg type=image thumb= https://www.jappix.com/store/share/vanar...@jappix.com/bdc11f42e0c1d810b33733689f6cfd7a9197c9e0_thumb.jpg; /* * * * **comments jid=jap...@jappix.com node=urn:xmpp:microblog:0:comments:80f4f021f57e3606e4b019c11dfd00de /* /entry /item /items *Here are the attributes in use for the file / element:* * *name*: the real file name * *url*: the file url (HTTP if source=web; ...) * *source*: the source of the file (web, ...) * *ext*: the file extension (I think it might be removed because of type attr) * *type*: the file type category (I think it might be changed to the MIME type to remove ext attr) * *thumb*: the link to a thumbnail of the image file, using the same MIME type as the big file (we may add video files thumbs support too, maybe using a thumb / sub-element with all the MIME type needed in a type attr) *For the repeat / element:* * *jid*: the JID of the initial author *For the comments / element:* * *jid*: the JID of the entity hosting the comments node * *node*: the node name hosting the comment items Publishing a single comment to a comments node looks like this: iq xmlns=jabber:client type=set to=jap...@jappix.com id=get_15-13 xml:lang=fr pubsub xmlns=http://jabber.org/protocol/pubsub; publish node=urn:xmpp:microblog:0:comments:f5168699fffb8915772a2603065cda05 item id=827f82c21dfa9f2436bb760f6b9be5d5 entry xmlns=http://www.w3.org/2005/Atom; *titlePublish a new comment!/title* published2011-03-26T11:00:51Z/published source author jidjap...@jappix.com/jid /author /source /entry /item /publish /pubsub /iq And, another question: why is the microblogging XEP now deferred? I really think there is some potential behind it, and defer it is not a solution: we can enhence it little by little and get what everyone wants. We managed to do something strong with it for Jappix, and we will soon add notifications features (we don't know how we will proceed now). I am waiting for your replies and thoughts about it. I am aware that my first integration of this new feature in Jappix is not really clean and might be enhenced. For any test of how we added
Re: [Standards] Microblogging XEP new features
Hello, Okay, I will try to make it more Atom-compliant. I had problems with my first mail (sent a week ago to the list), some people did not receive it (including me), and I considered it was lost. It seems not ;) For the entry repeat, yes, maybe adding a simple jid / element to the author / one is much better. The client will just have to compare the sender JID and this jid / text content to add a repeated icon (or something like this) to the notice. The in-reply-to/ specification is not really a commenting feature, it seems to be just a replying feature. What we did with our specification is that we allow users to comment on another PubSub node, created *only for the notice*, so that it is independent from the microblog notices themselves. Thanks for your reply, I will consider applying it to our specification, Valérian Saliou. 2011/3/26 Florian Zeitz florian.ze...@gmx.de Am 26.03.2011 12:05, schrieb Vanaryon: Hi, I am the Jappix project founder (https://www.jappix.com/ - https://project.jappix.com/ - https://mini.jappix.com), and we added full microblogging XEP (XEP-0277) support to our webclient (desktop edition). Here are some enhences of the XEP we did, which are working very fine! Hy, First as a general note: XEP 0277 uses the Atom Publishing format. It would therefore be better to reuse elements already defined by that format. Also any extensions you make have to be in a new namespace since the are not part of the atom. _*1. File attachment*_ We had a strong need during its integration: the multiple/single file(s) attachment, like Identi.ca does in its protocol. We built a simple way (maybe not the best?!) to do this, with a file / element (can be multiple if more than one file per item). This has been discussed on this list already (http://mail.jabber.org/pipermail/standards/2011-March/024277.html). In short: Use the link rel='enclosure / from Atom. _*2. Entry repeat*_ When someone repeat a friend's entry, we could specify it to the new posted item. We added a repeat / element to the source / one, with the jid attribute of the initial entry. I feel this should be part of the author/ element. There is already uri/, I think we could just put a xmpp uri there, couldn't we? _*3. Comments*_ To allow users reacting to one's entry, we added a commenting feature. For that, we use a comments / element, wich specifies where is the comments node located (PubSub server/PEP + node name). The current XEP-0277 also has a commenting feature which works by adding a in-reply-to/ element. That is however a quite different way to do comments and there should probably be some discussion on which way to do it. […] And, another question: why is the microblogging XEP now deferred? I really think there is some potential behind it, and defer it is not a solution: we can enhence it little by little and get what everyone wants. We managed to do something strong with it for Jappix, and we will soon add notifications features (we don't know how we will proceed now). It is deferred because such updating has not occured in a certain period of time. It will be un-deferred once any changes the to the XEP are made. AFAIK we are still looking for a new maintainer for that XEP. -- Florian Zeitz
Re: [Standards] Microblogging XEP new features
Hello (again), I changed things to make them Atom-compliant. Here is how I proceed now: *1. File attaching* Use this (per file): link rel=enclosure title=File name type=image/jpeg length=56131 href= https://www.jappix.com/store/share/jap...@jappix.com/bfeefd6318a433a571306f8b7df109b8044d6d273511.jpg *2. Repeat (original notice author)* Add a jid / element to the author / element. The client will compare the received stanza JID and this to know if this is a repeated notice. *3. Comments* Use this, with an XMPP URI: link rel=alternate href=xmpp:jappix% 40jappix.com?;node=urn%3Axmpp%3Amicroblog%3A0;item=3b782e7a5212a81f2578d935806baad5 How do you find this? Can we discuss about adding this to the XEP? (and okay for the deferred status, I was thinking that it had to be voted by the council to defer something, I did not know it was automated). Bye, Valérian Saliou. 2011/3/26 Vanaryon vanar...@gmail.com Hello, Okay, I will try to make it more Atom-compliant. I had problems with my first mail (sent a week ago to the list), some people did not receive it (including me), and I considered it was lost. It seems not ;) For the entry repeat, yes, maybe adding a simple jid / element to the author / one is much better. The client will just have to compare the sender JID and this jid / text content to add a repeated icon (or something like this) to the notice. The in-reply-to/ specification is not really a commenting feature, it seems to be just a replying feature. What we did with our specification is that we allow users to comment on another PubSub node, created *only for the notice*, so that it is independent from the microblog notices themselves. Thanks for your reply, I will consider applying it to our specification, Valérian Saliou. 2011/3/26 Florian Zeitz florian.ze...@gmx.de Am 26.03.2011 12:05, schrieb Vanaryon: Hi, I am the Jappix project founder (https://www.jappix.com/ - https://project.jappix.com/ - https://mini.jappix.com), and we added full microblogging XEP (XEP-0277) support to our webclient (desktop edition). Here are some enhences of the XEP we did, which are working very fine! Hy, First as a general note: XEP 0277 uses the Atom Publishing format. It would therefore be better to reuse elements already defined by that format. Also any extensions you make have to be in a new namespace since the are not part of the atom. _*1. File attachment*_ We had a strong need during its integration: the multiple/single file(s) attachment, like Identi.ca does in its protocol. We built a simple way (maybe not the best?!) to do this, with a file / element (can be multiple if more than one file per item). This has been discussed on this list already (http://mail.jabber.org/pipermail/standards/2011-March/024277.html). In short: Use the link rel='enclosure / from Atom. _*2. Entry repeat*_ When someone repeat a friend's entry, we could specify it to the new posted item. We added a repeat / element to the source / one, with the jid attribute of the initial entry. I feel this should be part of the author/ element. There is already uri/, I think we could just put a xmpp uri there, couldn't we? _*3. Comments*_ To allow users reacting to one's entry, we added a commenting feature. For that, we use a comments / element, wich specifies where is the comments node located (PubSub server/PEP + node name). The current XEP-0277 also has a commenting feature which works by adding a in-reply-to/ element. That is however a quite different way to do comments and there should probably be some discussion on which way to do it. […] And, another question: why is the microblogging XEP now deferred? I really think there is some potential behind it, and defer it is not a solution: we can enhence it little by little and get what everyone wants. We managed to do something strong with it for Jappix, and we will soon add notifications features (we don't know how we will proceed now). It is deferred because such updating has not occured in a certain period of time. It will be un-deferred once any changes the to the XEP are made. AFAIK we are still looking for a new maintainer for that XEP. -- Florian Zeitz
Re: [Standards] microblogging maintainer :)
On Mon Dec 20 13:10:19 2010, Thomas Baquet wrote: - As written in the draft, The client MAY add a “reply” attribute which gives the parent existing collection node. The default value of this attribute is the node where the item is published. - Actually I was a sick when i've written this draft (perhaps that's why I couldn't express me correctly --), but I would meant that by /default/ this is a child node of the node where the item is published. But, that can be a nice feature if the user is available to choose the node where the item will be published; The trouble with this model is that you're redefining how pubsub works quite radically. Nodes, currently can be one of two types: Collection Nodes, which contain other nodes (or, more strictly, pointers to other nodes). Leaf Nodes, which contain items. In both cases, they can contain as many things (nodes or items) as you like, although in PEP implementations this needs to be only one, and most (all?) current implementations restrict the number of items to a minimum. As such, I'd expect implementations of this to support many items per node, and full access model control to allow (or disallow) replies on the node as needs be. There's really no need to a protocol extension to pubsub to support this. In order to effectively unify the two models (ie, posting replies on your own node versus posting replies on the original poster's), I'd have thought you do this: 1) Replies are posted to the poster's µblog node. 2) The replier also posts a pointer (possibly duplicating the post) to a replies node on their own personal pubsub service. Then, the only risk is that a replier actually posts a top-level entry into someone else's µblog - in this case, though, it's pretty easy to spot and the node owner can remove it as well. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] microblogging maintainer :)
The trouble with this model is that you're redefining how pubsub works quite radically. Nodes, currently can be one of two types: I missed that... As such, I'd expect implementations of this to support many items per node, and full access model control to allow (or disallow) replies on the node as needs be. There's really no need to a protocol extension to pubsub to support this. Perhaps is this the simplest way - delegate the work to the client implementation: if the user has a write access on a node, the client has to propose to answer to the item. In this case, there is a leaf node for each published item. No need of XEP for this, as you told. - On this, Floriant was right. Then, the problem still the pointer - user can choose to post the reply on his own pubsub, in this case, he must send an pointer item on the original item's. So, how do we define the pointer? I began a little proposition about this (point 5 of the draft), but still incomplete - and, why not, add an attribute to define if is it a reply or a trackball (like in wordpress), a copy of the original etc. ? -- Thomas Baquet (aka Lord Blackfox) Jabber ID: ldblack...@papaya.im Website: http://www.lordblackfox.net/ Twitter: http://twitter.com/#!/LordBlackFox
Re: [Standards] microblogging maintainer :)
On Mon Dec 20 16:20:23 2010, Thomas Baquet wrote: The trouble with this model is that you're redefining how pubsub works quite radically. Nodes, currently can be one of two types: I missed that... As such, I'd expect implementations of this to support many items per node, and full access model control to allow (or disallow) replies on the node as needs be. There's really no need to a protocol extension to pubsub to support this. Perhaps is this the simplest way - delegate the work to the client implementation: if the user has a write access on a node, the client has to propose to answer to the item. In this case, there is a leaf node for each published item. No, there's a single leaf node for *all* the published items. And I'd argue that if you can't post to a node, then direct replies are not supported by that node. No need of XEP for this, as you told. - On this, Floriant was right. No, there's still a need to document how it should work, but there's no need to extend the protocol. Then, the problem still the pointer - user can choose to post the reply on his own pubsub, in this case, he must send an pointer item on the original item's. So, how do we define the pointer? I began a little proposition about this (point 5 of the draft), but still incomplete - and, why not, add an attribute to define if is it a reply or a trackball (like in wordpress), a copy of the original etc. ? You can place the pointer within the payload. I'd be quite surprised if there weren't one available already within Atom. There's certainly replies, etc, with the threading extension, I'd imagine there's a canonical URI some place there. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] microblogging maintainer :)
On 20/12/2010 14:45, Dave Cridland wrote: No, there's a single leaf node for *all* the published items. And I'd argue that if you can't post to a node, then direct replies are not supported by that node. What do u propose then to link the answer onto the base item? -- Thomas Baquet (aka Lord Blackfox) Jabber ID: ldblack...@papaya.im Website: http://www.lordblackfox.net/ Twitter: http://twitter.com/#!/LordBlackFox
Re: [Standards] microblogging maintainer :)
On Mon Dec 20 16:48:58 2010, Thomas Baquet wrote: On 20/12/2010 14:45, Dave Cridland wrote: No, there's a single leaf node for *all* the published items. And I'd argue that if you can't post to a node, then direct replies are not supported by that node. What do u propose then to link the answer onto the base item? WHat's needed beyond Atom threading in the payload? Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] microblogging maintainer :)
On 20/12/2010 14:58, Dave Cridland wrote: On Mon Dec 20 16:48:58 2010, Thomas Baquet wrote: On 20/12/2010 14:45, Dave Cridland wrote: No, there's a single leaf node for *all* the published items. And I'd argue that if you can't post to a node, then direct replies are not supported by that node. What do u propose then to link the answer onto the base item? WHat's needed beyond Atom threading in the payload? Dave. The problem is by using Atom that you'll limit reply node to Atom content then - otherwise, you'll lost the power of pubsub, even if Atom is extensible; a stupid example should be: if I want to answer with a mood, or a tune (even if it is basically expected for PEP, nothing should prevent me to post this) -- Thomas Baquet (aka Lord Blackfox) Jabber ID: ldblack...@papaya.im Website: http://www.lordblackfox.net/ Twitter: http://twitter.com/#!/LordBlackFox
Re: [Standards] microblogging maintainer :)
On Mon Dec 20 17:03:30 2010, Thomas Baquet wrote: On 20/12/2010 14:58, Dave Cridland wrote: On Mon Dec 20 16:48:58 2010, Thomas Baquet wrote: On 20/12/2010 14:45, Dave Cridland wrote: No, there's a single leaf node for *all* the published items. And I'd argue that if you can't post to a node, then direct replies are not supported by that node. What do u propose then to link the answer onto the base item? WHat's needed beyond Atom threading in the payload? Dave. The problem is by using Atom that you'll limit reply node to Atom content then - otherwise, you'll lost the power of pubsub, even if Atom is extensible; a stupid example should be: if I want to answer with a mood, or a tune (even if it is basically expected for PEP, nothing should prevent me to post this) Atom can be used to frame arbitrary content, as far as I'm aware. Absolutely nothing prevents you from replying with a mood element embedded in Atom. The Atom just buys us all the threadings and post mobility. If you look at Identi.ca, for instance, they throw a half-dozen representations of the post content, plus geolocation information, profile information of the poster, the instruction manual for the poster's fridge, and so on. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] microblogging maintainer :)
On 20/12/2010 15:16, Dave Cridland wrote: The problem is by using Atom that you'll limit reply node to Atom content then - otherwise, you'll lost the power of pubsub, even if Atom is extensible; a stupid example should be: if I want to answer with a mood, or a tune (even if it is basically expected for PEP, nothing should prevent me to post this) Atom can be used to frame arbitrary content, as far as I'm aware. Absolutely nothing prevents you from replying with a mood element embedded in Atom. The Atom just buys us all the threadings and post mobility. Isn't it blending pubsub with atom too much? I mean, atom is a kind of content like other which can be in a pubsub item. If we decide to use it as a container of (in the previous example) mood element (or any kind of content), why not directly replace item element with an atom entry (if it can embed the kind of sub-element we want)? -- Thomas Baquet (aka Lord Blackfox) Jabber ID: ldblack...@papaya.im Website: http://www.lordblackfox.net/ Twitter: http://twitter.com/#!/LordBlackFox
Re: [Standards] microblogging maintainer :)
On Mon Dec 20 17:23:49 2010, Thomas Baquet wrote: On 20/12/2010 15:16, Dave Cridland wrote: The problem is by using Atom that you'll limit reply node to Atom content then - otherwise, you'll lost the power of pubsub, even if Atom is extensible; a stupid example should be: if I want to answer with a mood, or a tune (even if it is basically expected for PEP, nothing should prevent me to post this) Atom can be used to frame arbitrary content, as far as I'm aware. Absolutely nothing prevents you from replying with a mood element embedded in Atom. The Atom just buys us all the threadings and post mobility. Isn't it blending pubsub with atom too much? I mean, atom is a kind of content like other which can be in a pubsub item. If we decide to use it as a container of (in the previous example) mood element (or any kind of content), why not directly replace item element with an atom entry (if it can embed the kind of sub-element we want)? Because PubSub nodes contain items - replacing the item element with an Atom element would mean breaking compatibility with PubSub. It doesn't seem useful to do that. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] microblogging maintainer :)
On 20/12/2010 15:38, Dave Cridland wrote: Because PubSub nodes contain items - replacing the item element with an Atom element would mean breaking compatibility with PubSub. It doesn't seem useful to do that. (Actually, I'd meant in a perspective of redefining pubsub, cause Atom is more flexible than the item element itself. Anyway...) Okay, so let's take the Atom way then: when a node allows a write access to user, it means he can post reply to items on it. But there stills a problem: imagine than - in a more general way - I post an blog article on my blog node; how will I manage wether people will effectively post a reply to this article or when they will post an article which is not a reply? For certain kind of content allowing people post in my node item which are not necesseraly item can be useful (like facebook wall), but others no. -- Thomas Baquet (aka Lord Blackfox) Jabber ID: ldblack...@papaya.im Website: http://www.lordblackfox.net/ Twitter: http://twitter.com/#!/LordBlackFox
Re: [Standards] microblogging maintainer :)
On 20/12/2010 19:01, Thomas Baquet wrote: Okay, so let's take the Atom way then: when a node allows a write access to user, it means he can post reply to items on it. But there stills a problem: imagine than - in a more general way - I post an blog article on my blog node; how will I manage wether people will effectively post a reply to this article or when they will post an article which is not a reply? For certain kind of content allowing people post in my node item which are not necesseraly item can be useful (like facebook wall), but others no. It would really help if we had some concrete examples of what features and use-cases this spec is trying to support? We all have different ideas of what micro-blogging means means and arbitrarily hammering out a spec without some predefined use cases and users stories is spec-masturbation: fun, but rather pointless. It may well be worth leaving this spec as nothing more than publish to a node (pep or pubsub) and use atom payloads. Trying to define anything more than that, like the business logic of who can reply to what is really the role of an implementer and depends on the type of community they are building their application for. If people want to define more then implement an application and see how users use it and adjust accordingly. I would really like this stuff all standardised based on how buddycloud users have used channels, but even then I think that going more detailed is really constraining (and with little benefit). S. -- Simon Tennant mobile: +49 17 8545 0880 office: +49 89 4209 55854 office: +44 20 7043 6756 xmpp: si...@buddycloud.com build your own open and federated social network - http://open.buddycloud.com
Re: [Standards] microblogging maintainer :)
On 12/04/2010 07:55 PM, Thomas Baquet wrote: I've written a first draft (full of awful errors, certainly); what do u think? Hello, Some comments on this draft (sorry if some of them are pointless. I'm still not an XMPP expert): - Do you think this should be part of the XEP-0277 or should this be a separate XEP? - I don’t understand why the publishing entity would decide to create the reply-node on an other node than where the item is being published. Wouldn't it be simpler to just create the reply-node as a child of the node where the item is published? This imply, for example, that the microblogging node (urn:xmpp:microblog:0) MUST be of type collection, if the service wants to permit replies to microblog-posts. Isn't it? - I think allow-reply and reply are a bit redundant. To allow users to reply to an item, the publishing entity MUST include a reply / element as a child of the item / element it wishes to publish. This reply / element MUST be empty and MAY contain a node attribute indicating the child node the server MUST create and where replies to this item SHOULD be published. If this element doesn’t contain any node attribute, this reply-node defaults to the item’s id. Example 1. User publish an item on a node iq type='set' from='ham...@denmark.lit/blogbot' to='pubsub.shakespeare.lit' id='publish1' pubsub xmlns='http://jabber.org/protocol/pubsub' publish node='princely_musings' item id='bnd81g37d61f49fgn581' entry xmlns='http://www.w3.org/2005/Atom' !-- SNIP -- /entry reply node=reply-bnd81g37d61f49fgn581 / /item /publish /pubsub /iq Example $$. Server will reply: iq type='result' from='pubsub.shakespeare.lit' to='franci...@denmark.lit/barracks' id='items1' pubsub xmlns='http://jabber.org/protocol/pubsub' items node='princely_musings' item id='bnd81g37d61f49fgn581' entry xmlns='http://www.w3.org/2005/Atom' !-- SNIP -- /entry reply node=princely_musings/reply-bnd81g37d61f49fgn581 / /item /items /pubsub /iq With the help of this XEP, we could have two microblogging models. - The twitter/identi.ca-like model: items are published with an Open access model, with no reply / element. User can still “respond” in their own microblog, as defined currently in 0277. - The Facebook/diaspora-like model: items are published with a Roster access model, with a reply / element as defined above. This second microblogging model could be defined in an additional XEP. (for a total of 3 XEPs : 0277, Reply On Pubsub, Microblog Second Model) -- Florent Le Coz
Re: [Standards] microblogging maintainer :)
On 01/12/2010 17:03, Dave Cridland wrote: On Wed Dec 1 16:40:34 2010, Peter Saint-Andre wrote: On 12/1/10 9:39 AM, Dave Cridland wrote: On Wed Dec 1 16:33:30 2010, Peter Saint-Andre wrote: Will someone volunteer to take over maintainership of XEP-0270? I simply don't have the cycles to do it justice. XEP-0270 is compliance suites - don't we want to shelve that one and make a 2011 one? (Something I'd be fine with handling the XEP side of, but couldn't hope to pretend to be impartial about). Sorry, I meant the microblogging spec: http://xmpp.org/extensions/xep-0277.html I'm entirely happy with maintaining this, as long as there is sufficient interest in the community to provide things to put *in* it. ie, I'll cheerfully act as editor, and document consensus, but not author. Dave. Okay, I've been thinking a while theses last days about this, read again this thread: http://mail.jabber.org/pipermail/standards/2010-September/023817.html , and then would share some ideas: - every pubsub node can have an answer node, given in an @related attribute (or else), which is a collection node, and on which users will post answers; - for each item in the node, there is a subnode created on the answer collection node using the id of the concerned item. The server will create it only when an user will publish an element on the subnode. - each item in the answer node can have an @related attribute, which is the id of an another item published in the same answer node; Basically, I tough about thread attribute, but this is limited at one sub-level of answer. - user can post a reference element on the answer node in state of publish element directly on the answer node. In this case, use atom? This system can be used for microblogging, blogging, forum, and so... Example for microblogging: C: iq type=get to=ro...@shakespeare.it query xmlns=http://jabber.org/protocol/disco#items; /iq S: iq type=result to=jul...@shakespeare.it queryxmlns=http://jabber.org/protocol/disco#items; item node=urn:xmpp:microblog related=urn:xmpp:microblog:comments / item node=urn:xmpp:activityStreamrelated=urn:xmpp:activityStream:comments / item node=mylifeisbeautifulrelated=comments/mylifeisbeautiful / item node=ilovejulietsomuchrelated=comments/ilovejulietsomuch / /query /iq C: iq type=get to=ro...@shakespeare.it pubsubxmlns='http://jabber.org/protocol/pubsub' itemsnode=urn:xmpp:microblog:0/ /pubsub /iq S: iq type=result to=jul...@shakespeare.it pubsubxmlns='http://jabber.org/protocol/pubsub' items node=urn:xmpp:microblog:0 related=urn:xmpp:microblog:comments item id=item000 !-- DATA -- /item item id=item001 !-- DATA -- /item item id=item002 !-- DATA -- /item /items /pubsub /iq C: iq type=get to=ro...@shakespeare.it query xmlns=http://jabber.org/protocol/disco#items; node=urn:xmpp:microblog:comments /iq S: iq type=result to=jul...@shakespeare.it queryxmlns=http://jabber.org/protocol/disco#items; node=urn:xmpp:microblog:comments item node=item000/ item node=item001/ item node=item002/ /query /iq -- Thomas Baquet (aka Lord Blackfox) Jabber ID: ldblack...@papaya.im Website: http://www.lordblackfox.net/ Twitter: http://twitter.com/#!/LordBlackFox
Re: [Standards] microblogging maintainer :)
On 01/12/2010 16:43, Peter Saint-Andre wrote: On 12/1/10 11:30 AM, Thomas Baquet wrote: On 01/12/2010 16:40, Peter Saint-Andre wrote: On 12/1/10 9:39 AM, Dave Cridland wrote: On Wed Dec 1 16:33:30 2010, Peter Saint-Andre wrote: Will someone volunteer to take over maintainership of XEP-0270? I simply don't have the cycles to do it justice. XEP-0270 is compliance suites - don't we want to shelve that one and make a 2011 one? (Something I'd be fine with handling the XEP side of, but couldn't hope to pretend to be impartial about). Sorry, I meant the microblogging spec: http://xmpp.org/extensions/xep-0277.html Oops... Peter Perhaps enlarge this extensions to all forms of Pubsub content implying answering, forwarding, etc., no? Are you volunteering? ;-) I've written a first draft (full of awful errors, certainly); what do u think? -- Thomas Baquet (aka Lord Blackfox) Jabber ID: ldblack...@papaya.im Website: http://www.lordblackfox.net/ Twitter: http://twitter.com/#!/LordBlackFox xep - reply on pubsub.odt Description: application/vnd.oasis.opendocument.text
Re: [Standards] microblogging maintainer :)
On 01/12/2010 16:40, Peter Saint-Andre wrote: On 12/1/10 9:39 AM, Dave Cridland wrote: On Wed Dec 1 16:33:30 2010, Peter Saint-Andre wrote: Will someone volunteer to take over maintainership of XEP-0270? I simply don't have the cycles to do it justice. XEP-0270 is compliance suites - don't we want to shelve that one and make a 2011 one? (Something I'd be fine with handling the XEP side of, but couldn't hope to pretend to be impartial about). Sorry, I meant the microblogging spec: http://xmpp.org/extensions/xep-0277.html Oops... Peter Perhaps enlarge this extensions to all forms of Pubsub content implying answering, forwarding, etc., no? -- Thomas Baquet (aka Lord Blackfox) Jabber ID: ldblack...@papaya.im Website: http://www.lordblackfox.net/ Twitter: http://twitter.com/#!/LordBlackFox
Re: [Standards] microblogging maintainer :)
On 12/1/10 11:30 AM, Thomas Baquet wrote: On 01/12/2010 16:40, Peter Saint-Andre wrote: On 12/1/10 9:39 AM, Dave Cridland wrote: On Wed Dec 1 16:33:30 2010, Peter Saint-Andre wrote: Will someone volunteer to take over maintainership of XEP-0270? I simply don't have the cycles to do it justice. XEP-0270 is compliance suites - don't we want to shelve that one and make a 2011 one? (Something I'd be fine with handling the XEP side of, but couldn't hope to pretend to be impartial about). Sorry, I meant the microblogging spec: http://xmpp.org/extensions/xep-0277.html Oops... Peter Perhaps enlarge this extensions to all forms of Pubsub content implying answering, forwarding, etc., no? Are you volunteering? ;-) smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] microblogging maintainer :)
On 01/12/2010 16:43, Peter Saint-Andre wrote: On 12/1/10 11:30 AM, Thomas Baquet wrote: On 01/12/2010 16:40, Peter Saint-Andre wrote: On 12/1/10 9:39 AM, Dave Cridland wrote: On Wed Dec 1 16:33:30 2010, Peter Saint-Andre wrote: Will someone volunteer to take over maintainership of XEP-0270? I simply don't have the cycles to do it justice. XEP-0270 is compliance suites - don't we want to shelve that one and make a 2011 one? (Something I'd be fine with handling the XEP side of, but couldn't hope to pretend to be impartial about). Sorry, I meant the microblogging spec: http://xmpp.org/extensions/xep-0277.html Oops... Peter Perhaps enlarge this extensions to all forms of Pubsub content implying answering, forwarding, etc., no? Are you volunteering? ;-) To help, why not; the problem still that my English is a bit ugly and that I miss a lot of time... But that can be interesting to make a PiratePad ( http://piratepad.net ) where people can work on this and push ideas, no? -- Thomas Baquet (aka Lord Blackfox) Jabber ID: ldblack...@papaya.im Website: http://www.lordblackfox.net/ Twitter: http://twitter.com/#!/LordBlackFox
Re: [Standards] microblogging maintainer :)
Hi Peter, I might be interested since I'm partially involved in the OneSocialWeb project, but to be honest I have no experience with XEP-maintainership (time/effort required, skills and so on...) Sorry for the newbie question, but can you provide me some details about that? Thanks a lo luca 2010/12/1 Thomas Baquet ld.black...@gmail.com On 01/12/2010 16:43, Peter Saint-Andre wrote: On 12/1/10 11:30 AM, Thomas Baquet wrote: On 01/12/2010 16:40, Peter Saint-Andre wrote: On 12/1/10 9:39 AM, Dave Cridland wrote: On Wed Dec 1 16:33:30 2010, Peter Saint-Andre wrote: Will someone volunteer to take over maintainership of XEP-0270? I simply don't have the cycles to do it justice. XEP-0270 is compliance suites - don't we want to shelve that one and make a 2011 one? (Something I'd be fine with handling the XEP side of, but couldn't hope to pretend to be impartial about). Sorry, I meant the microblogging spec: http://xmpp.org/extensions/xep-0277.html Oops... Peter Perhaps enlarge this extensions to all forms of Pubsub content implying answering, forwarding, etc., no? Are you volunteering? ;-) To help, why not; the problem still that my English is a bit ugly and that I miss a lot of time... But that can be interesting to make a PiratePad ( http://piratepad.net ) where people can work on this and push ideas, no? -- Thomas Baquet (aka Lord Blackfox) Jabber ID: ldblack...@papaya.im Website: http://www.lordblackfox.net/ Twitter: http://twitter.com/#!/LordBlackFoxhttp://twitter.com/#%21/LordBlackFox -- Luca Faggioli OneSocialWeb JID: l...@social.openliven.com
Re: [Standards] microblogging maintainer :)
On Wed Dec 1 16:40:34 2010, Peter Saint-Andre wrote: On 12/1/10 9:39 AM, Dave Cridland wrote: On Wed Dec 1 16:33:30 2010, Peter Saint-Andre wrote: Will someone volunteer to take over maintainership of XEP-0270? I simply don't have the cycles to do it justice. XEP-0270 is compliance suites - don't we want to shelve that one and make a 2011 one? (Something I'd be fine with handling the XEP side of, but couldn't hope to pretend to be impartial about). Sorry, I meant the microblogging spec: http://xmpp.org/extensions/xep-0277.html I'm entirely happy with maintaining this, as long as there is sufficient interest in the community to provide things to put *in* it. ie, I'll cheerfully act as editor, and document consensus, but not author. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Microblogging structure
On 11/27/2010 02:23 PM, Thomas Baquet wrote: Hi, I was reading the xep-0277 (Microblogging over XMPP), when I was asking myself if the structure used for reply is really interesting: if Mr. A has subscribed to my µblog node but not the Mr. B's one, and if Mr. B answered to me, it can be interesting for Mr. A to access to Mr. B's answer. In this case, the system used by the xep is not efficient: the reply notification will only be sent to me, not to Mr. A. Then, why not making something like a notify-node where a new entry is added when Mr. B post is own answer on his node. The entry added to my node will just be a reference to Mr B's answer. Like this, he keeps control of his published data, but everybody will be notified by this. This system should be generalized for other kind of publications, like blog articles, forums, etc. Hi, The problem you're pointing here is very similar to what I noted earlier, see this previous thread: http://mail.jabber.org/pipermail/standards/2010-September/023817.html See also the next posts, with responses to this problem. By the way, Dave, did you come up with a solution? Would it help you if I (and others) wrote a modified version of 0277. Because things didn't move for a while, and I would appreciate that they did. -- Florent
[Standards] Microblogging structure
Hi, I was reading the xep-0277 (Microblogging over XMPP), when I was asking myself if the structure used for reply is really interesting: if Mr. A has subscribed to my µblog node but not the Mr. B's one, and if Mr. B answered to me, it can be interesting for Mr. A to access to Mr. B's answer. In this case, the system used by the xep is not efficient: the reply notification will only be sent to me, not to Mr. A. Then, why not making something like a notify-node where a new entry is added when Mr. B post is own answer on his node. The entry added to my node will just be a reference to Mr B's answer. Like this, he keeps control of his published data, but everybody will be notified by this. This system should be generalized for other kind of publications, like blog articles, forums, etc. -- Thomas Baquet (aka Lord Blackfox) Jabber ID: ldblack...@papaya.im Website: http://www.lordblackfox.net/
Re: [Standards] microblogging
Good Sunday Sirs, 2010/1/22 Peter Saint-Andre stpe...@stpeter.im: About 18 months ago we had a flurry of discussion about microblogging over XMPP but that conversation fizzled out. In the last few days, we've had some renewed interest in the old microblogging proposal over on the WS-XMPP list: http://mail.jabber.org/pipermail/ws-xmpp/2010-January/000206.html I'd like to bring this topic back in front of the Council and try to get the original proposal published as a XEP so we can foster more discussion: http://xmpp.org/extensions/inbox/microblogging.html If anyone has input here, please do weigh in. In the Buddycloud project we are doing things very close to this. The next version we are releasing in near future will be fully PubSub based. The biggest difference we have is that the microblogging is not on PEP nodes, but on normal nodes on specific component based on XEP-0060. This is done so that any JID can be used (@gtalk.com, @jabber.org, etc) to use the service. It would be my pleasure to explain more what we have done. It has been my plan to write a longer mail about the system as soon as the system is out. I'll be also at FOSDEM and participating the XMPP Summit 8 to spread information what we have found and learned. PubSub Rocks! Br, -- Tuomas xmpp:tuo...@xmpp.lobstermonster.org
Re: [Standards] microblogging
On 1/24/10 9:52 AM, Tuomas Koski wrote: Good Sunday Sirs, 2010/1/22 Peter Saint-Andre stpe...@stpeter.im: About 18 months ago we had a flurry of discussion about microblogging over XMPP but that conversation fizzled out. In the last few days, we've had some renewed interest in the old microblogging proposal over on the WS-XMPP list: http://mail.jabber.org/pipermail/ws-xmpp/2010-January/000206.html I'd like to bring this topic back in front of the Council and try to get the original proposal published as a XEP so we can foster more discussion: http://xmpp.org/extensions/inbox/microblogging.html If anyone has input here, please do weigh in. In the Buddycloud project we are doing things very close to this. The next version we are releasing in near future will be fully PubSub based. The biggest difference we have is that the microblogging is not on PEP nodes, but on normal nodes on specific component based on XEP-0060. This is done so that any JID can be used (@gtalk.com, @jabber.org, etc) to use the service. Sure. It's not necessarily tied to PEP, only to PubSub. We'll fix the proposal to make that clear. It would be my pleasure to explain more what we have done. It has been my plan to write a longer mail about the system as soon as the system is out. I'll be also at FOSDEM and participating the XMPP Summit 8 to spread information what we have found and learned. Looking forward to your talk! Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] microblogging
About 18 months ago we had a flurry of discussion about microblogging over XMPP but that conversation fizzled out. In the last few days, we've had some renewed interest in the old microblogging proposal over on the WS-XMPP list: http://mail.jabber.org/pipermail/ws-xmpp/2010-January/000206.html I'd like to bring this topic back in front of the Council and try to get the original proposal published as a XEP so we can foster more discussion: http://xmpp.org/extensions/inbox/microblogging.html If anyone has input here, please do weigh in. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
