So far, I haven't done a whole lot of specifying on the XMPP side - it would be great if you had some opinions! The biggest thing I think we need to solve for the XMPP mechanisms is working out how to authorise subscriptions. The pubsub XMPP extension works pretty well in terms of defining the mechanisms for distributing the data, however, its white-list mechanism is a bit underspecified to use without additional work. I, personally, see GetPingd as predominantly a discovery mechanism for techniques that are already in use, so an important part of making XMPP work would be making this kind of mechanism discoverable.
Welcome to the group.
Paul.
On Wed, May 7, 2008 at 7:48 PM, Peter Saint-Andre <stpe...@stpeter.im> wrote:
Some microblogging platforms allow commenting on other people's microblog posts (like jaiku and friendfeed) - do you think itd be possible to have that functionality in the XEP? Seems like it could potentially be a bit restrictive. Of course comments could just be a different view on replies, but it's still not quite the same.
On Thu, May 8, 2008 at 6:02 AM, Paul Jones <pauljone...@gmail.com> wrote: > Hi Peter,
> Thanks for joining us.
> So far, I haven't done a whole lot of specifying on the XMPP side - it > would be great if you had some opinions! The biggest thing I think we need > to solve for the XMPP mechanisms is working out how to authorise > subscriptions. The pubsub XMPP extension works pretty well in terms of > defining the mechanisms for distributing the data, however, its white-list > mechanism is a bit underspecified to use without additional work. I, > personally, see GetPingd as predominantly a discovery mechanism for > techniques that are already in use, so an important part of making XMPP work > would be making this kind of mechanism discoverable.
> Welcome to the group.
> Paul.
> On Wed, May 7, 2008 at 7:48 PM, Peter Saint-Andre <stpe...@stpeter.im> > wrote:
> > I just joined the list so I figured I'd say hi. Let me know if I can > > help out with the XMPP end of things. :)
> Some microblogging platforms allow commenting on other people's > microblog posts (like jaiku and friendfeed) - do you think itd be > possible to have that functionality in the XEP? Seems like it could > potentially be a bit restrictive. Of course comments could just be > a different view on replies, but it's still not quite the same.
Doesn't the <in-reply-to /> element in the current version of the XEP (see example 3 of the spec, please note that the XML is a bit wonky on that part, peter will fix it when he wakes up :) ) does what you need?
I would post to my microblog with a in-reply-to element pointing to your item.
oh, and introducing myself: Pedro Melo, XMPP geek.
>> Some microblogging platforms allow commenting on other people's >> microblog posts (like jaiku and friendfeed) - do you think itd be >> possible to have that functionality in the XEP? Seems like it could >> potentially be a bit restrictive. Of course comments could just be >> a different view on replies, but it's still not quite the same.
> Doesn't the <in-reply-to /> element in the current version of the XEP > (see example 3 of the spec, please note that the XML is a bit wonky > on that part, peter will fix it when he wakes up :) ) does what you > need?
That XML comes straight from RFC 4685. What aspect of the XML is wonky? Do you not like the namespace prefixes?
> I would post to my microblog with a in-reply-to element pointing to > your item.
Yes, that's the idea.
Naturally, you could also reply directly to the author (not post to your microblogging node). But I'll add an example of that to the next version.
> oh, and introducing myself: Pedro Melo, XMPP geek.
> Some microblogging platforms allow commenting on other people's microblog > posts (like jaiku and friendfeed) - do you think itd be possible to have > that functionality in the XEP? Seems like it could potentially be a bit > restrictive. Of course comments could just be a different view on replies, > but it's still not quite the same.
The distinction between comments and replies it not clear to me. Is that an interface issue? Or is there a difference between me commenting on what you've posted (in the same thread) vs. me posting starting a new thread that is triggered by something you've posted?
> Thanks for joining the group!
I'm on just about every other list that exists, why not this one? ;-)
> So far, I haven't done a whole lot of specifying on the XMPP side - it would > be great if you had some opinions! The biggest thing I think we need to > solve for the XMPP mechanisms is working out how to authorise subscriptions. > The pubsub XMPP extension works pretty well in terms of defining the > mechanisms for distributing the data, however, its white-list mechanism is a > bit underspecified to use without additional work. I, personally, see > GetPingd as predominantly a discovery mechanism for techniques that are > already in use, so an important part of making XMPP work would be making > this kind of mechanism discoverable.
It's not clear to me what you mean by subscription authorization and whitelists in the context of XMPP pubsub. We do have the ability to authorize subscriptions. See for instance:
>>> Some microblogging platforms allow commenting on other people's >>> microblog posts (like jaiku and friendfeed) - do you think itd be >>> possible to have that functionality in the XEP? Seems like it could >>> potentially be a bit restrictive. Of course comments could just be >>> a different view on replies, but it's still not quite the same.
>> Doesn't the <in-reply-to /> element in the current version of the XEP >> (see example 3 of the spec, please note that the XML is a bit wonky >> on that part, peter will fix it when he wakes up :) ) does what you >> need?
> That XML comes straight from RFC 4685. What aspect of the XML is > wonky? > Do you not like the namespace prefixes?
When I read the XEP, the ref attribute ended not with a ' but with a </id>.
I copy/pasted the example 3 in a XML validator and it failed at that point.
Fixed now, thanks Peter.
>> I would post to my microblog with a in-reply-to element pointing to >> your item.
> Yes, that's the idea.
> Naturally, you could also reply directly to the author (not post to > your > microblogging node). But I'll add an example of that to the next > version.
A comment node on the author pubsub tree?
>> oh, and introducing myself: Pedro Melo, XMPP geek.
On Fri, May 9, 2008 at 5:15 AM, Peter Saint-Andre <stpe...@stpeter.im> wrote:
> The distinction between comments and replies it not clear to me. Is that > an interface issue? Or is there a difference between me commenting on > what you've posted (in the same thread) vs. me posting starting a new > thread that is triggered by something you've posted?
This is purely my understanding based on using a few of these different services, I expect to be corrected by someone if I'm wrong.
A reply in twitter is an "@someone how are you" which may not actually be a reply at all. If this isnt in response to a particular message it should be the root node in a new thread and should live on my own timeline. I've seen some twitter services that try and make threaded conversations out of @ replies, it didn't work as great as it could simple because of this problem of @replies not being an actual reply to something.
Whereas if someone says "gee I'm feeling sick today" and I post a comment to that particular item saying "now you should get some sleep" (may or may not have @someone) that is a comment relating to a specific thread and thus could possibly not even live on my own timeline. it would be a comment on that person's timeline (that i argue they should have moderation control over, though i'm sure some will disagree)
@ twitters aren't always replies. They may be the opening to a new
conversation. It's just addressed to a certain person, like an email.
And yes, as you point out, not all replies have @ leading them, and
they don't necessarily have the ID of the @'ed person spelled
correctly. :)
Twitter is notoriously non-deterministic in this regard. A new
distributed microblogging platform should probably attempt to cure
some of these ills by making conversation threading explicit (like
this mail group) with "reply" and "new post" buttons.
Twitter definitely needs help with conversation threading and
reconstruction. Lots of room for innovation here.
JoeC
On May 10, 1:59 am, "David P. Novakovic" <d...@dpn.name> wrote:
> On Fri, May 9, 2008 at 5:15 AM, Peter Saint-Andre <stpe...@stpeter.im>
> wrote:
> > The distinction between comments and replies it not clear to me. Is that
> > an interface issue? Or is there a difference between me commenting on
> > what you've posted (in the same thread) vs. me posting starting a new
> > thread that is triggered by something you've posted?
> This is purely my understanding based on using a few of these different
> services, I expect to be corrected by someone if I'm wrong.
> A reply in twitter is an "@someone how are you" which may not actually be a
> reply at all. If this isnt in response to a particular message it should be
> the root node in a new thread and should live on my own timeline. I've seen
> some twitter services that try and make threaded conversations out of @
> replies, it didn't work as great as it could simple because of this problem
> of @replies not being an actual reply to something.
> Whereas if someone says "gee I'm feeling sick today" and I post a comment to
> that particular item saying "now you should get some sleep" (may or may not
> have @someone) that is a comment relating to a specific thread and thus
> could possibly not even live on my own timeline. it would be a comment on
> that person's timeline (that i argue they should have moderation control
> over, though i'm sure some will disagree)
> @ twitters aren't always replies. They may be the opening to a new > conversation. It's just addressed to a certain person, like an email. > And yes, as you point out, not all replies have @ leading them, and > they don't necessarily have the ID of the @'ed person spelled > correctly. :)
> Twitter is notoriously non-deterministic in this regard. A new > distributed microblogging platform should probably attempt to cure > some of these ills by making conversation threading explicit (like > this mail group) with "reply" and "new post" buttons.
> Twitter definitely needs help with conversation threading and > reconstruction. Lots of room for innovation here.
> On May 10, 1:59 am, "David P. Novakovic" <d...@dpn.name> wrote: >> On Fri, May 9, 2008 at 5:15 AM, Peter Saint-Andre >> <stpe...@stpeter.im> >> wrote:
>>> The distinction between comments and replies it not clear to me. >>> Is that >>> an interface issue? Or is there a difference between me >>> commenting on >>> what you've posted (in the same thread) vs. me posting starting a >>> new >>> thread that is triggered by something you've posted?
>> This is purely my understanding based on using a few of these >> different >> services, I expect to be corrected by someone if I'm wrong.
>> A reply in twitter is an "@someone how are you" which may not >> actually be a >> reply at all. If this isnt in response to a particular message it >> should be >> the root node in a new thread and should live on my own timeline. >> I've seen >> some twitter services that try and make threaded conversations out >> of @ >> replies, it didn't work as great as it could simple because of >> this problem >> of @replies not being an actual reply to something.
>> Whereas if someone says "gee I'm feeling sick today" and I post a >> comment to >> that particular item saying "now you should get some sleep" (may >> or may not >> have @someone) that is a comment relating to a specific thread and >> thus >> could possibly not even live on my own timeline. it would be a >> comment on >> that person's timeline (that i argue they should have moderation >> control >> over, though i'm sure some will disagree)
> So far, I haven't done a whole lot of specifying on the XMPP side - it > would > > be great if you had some opinions! The biggest thing I think we need to > > solve for the XMPP mechanisms is working out how to authorise > subscriptions. > > The pubsub XMPP extension works pretty well in terms of defining the > > mechanisms for distributing the data, however, its white-list mechanism > is a > > bit underspecified to use without additional work. I, personally, see > > GetPingd as predominantly a discovery mechanism for techniques that are > > already in use, so an important part of making XMPP work would be making > > this kind of mechanism discoverable.
> It's not clear to me what you mean by subscription authorization and > whitelists in the context of XMPP pubsub. We do have the ability to > authorize subscriptions. See for instance:
> By whitelisting, do you mean (for example) the ability say that any > subscription from a particular domain is acceptable?
So I'm thinking about it in the context of this scenario:
A resource supports some kind of authorization mechanism to view it (OAuth perhaps), as it is not normally visible to anonymous clients. We want to allow subscribers on the resource, but obviously, just allowing pubsub subscriptions would completely circumvent the web-based security if they didn't require authorization. This scenario obviously isn't about manual whitelisting, but instead about token-based authorization, which doesn't seem to be covered.
One possibility I've considered is the requirement to pre-subscribe via web-mechanisms (ie, provide your JID to a protected web-resource perhaps), but this has the disadvantage of not being pure XMPP. I was wondering if there were any ideas floating around about pure-XMPP authorisation mechanisms?
The same kind of thing has been in the back of my mind as I consider how to implement a distributed Twitter. It doesn't seem correct or necessary to have to implement everything in XMPP, or more to the point re-implement well-known mechanisms. The primary use of XMPP in a distributed microblogging system is to notify subscribers.
On Mon, May 12, 2008 at 3:46 AM, Paul Jones <pauljone...@gmail.com> wrote: > Hi Peter,
> > > So far, I haven't done a whole lot of specifying on the XMPP side - it > would > > > be great if you had some opinions! The biggest thing I think we need to > > > solve for the XMPP mechanisms is working out how to authorise > subscriptions. > > > The pubsub XMPP extension works pretty well in terms of defining the > > > mechanisms for distributing the data, however, its white-list mechanism > is a > > > bit underspecified to use without additional work. I, personally, see > > > GetPingd as predominantly a discovery mechanism for techniques that are > > > already in use, so an important part of making XMPP work would be making > > > this kind of mechanism discoverable.
> > It's not clear to me what you mean by subscription authorization and > > whitelists in the context of XMPP pubsub. We do have the ability to > > authorize subscriptions. See for instance:
> > By whitelisting, do you mean (for example) the ability say that any > > subscription from a particular domain is acceptable?
> So I'm thinking about it in the context of this scenario:
> A resource supports some kind of authorization mechanism to view it (OAuth > perhaps), as it is not normally visible to anonymous clients. We want to > allow subscribers on the resource, but obviously, just allowing pubsub > subscriptions would completely circumvent the web-based security if they > didn't require authorization. This scenario obviously isn't about manual > whitelisting, but instead about token-based authorization, which doesn't > seem to be covered.
> One possibility I've considered is the requirement to pre-subscribe via > web-mechanisms (ie, provide your JID to a protected web-resource perhaps), > but this has the disadvantage of not being pure XMPP. I was wondering if > there were any ideas floating around about pure-XMPP authorisation > mechanisms?
> The same kind of thing has been in the back of my mind as I consider > how to implement a distributed Twitter. It doesn't seem correct or > necessary to have to implement everything in XMPP, or more to the > point re-implement well-known mechanisms. > The primary use of XMPP in a distributed microblogging system is to > notify subscribers.
So your opinion is that a hybrid approach is the right one? Where perhaps you pre-authorize via a web mechanism authorised with standard mechanics (OAuth, Basic, ...), and then perform a pubsub join?
On Mon, May 12, 2008 at 6:12 AM, Paul Jones <pauljone...@gmail.com> wrote:
> > The same kind of thing has been in the back of my mind as I consider > > how to implement a distributed Twitter. It doesn't seem correct or > > necessary to have to implement everything in XMPP, or more to the > > point re-implement well-known mechanisms. > > The primary use of XMPP in a distributed microblogging system is to > > notify subscribers.
> So your opinion is that a hybrid approach is the right one? Where perhaps > you pre-authorize via a web mechanism authorised with standard mechanics > (OAuth, Basic, ...), and then perform a pubsub join?
>> So far, I haven't done a whole lot of specifying on the XMPP side - it >> would >>> be great if you had some opinions! The biggest thing I think we need to >>> solve for the XMPP mechanisms is working out how to authorise >> subscriptions. >>> The pubsub XMPP extension works pretty well in terms of defining the >>> mechanisms for distributing the data, however, its white-list mechanism >> is a >>> bit underspecified to use without additional work. I, personally, see >>> GetPingd as predominantly a discovery mechanism for techniques that are >>> already in use, so an important part of making XMPP work would be making >>> this kind of mechanism discoverable. >> It's not clear to me what you mean by subscription authorization and >> whitelists in the context of XMPP pubsub. We do have the ability to >> authorize subscriptions. See for instance:
>> By whitelisting, do you mean (for example) the ability say that any >> subscription from a particular domain is acceptable?
> So I'm thinking about it in the context of this scenario:
> A resource supports some kind of authorization mechanism to view it (OAuth > perhaps), as it is not normally visible to anonymous clients. We want to > allow subscribers on the resource, but obviously, just allowing pubsub > subscriptions would completely circumvent the web-based security if they > didn't require authorization. This scenario obviously isn't about manual > whitelisting, but instead about token-based authorization, which doesn't > seem to be covered.
> One possibility I've considered is the requirement to pre-subscribe via > web-mechanisms (ie, provide your JID to a protected web-resource perhaps), > but this has the disadvantage of not being pure XMPP. I was wondering if > there were any ideas floating around about pure-XMPP authorisation > mechanisms?
