Re: [Social] [diso-project] Re: OpenMicroBlogging

[Chris Messina]

Let me frame the challenge/opportunity this way:
Presume that I have a URL of my own, given a recipient URL, I want to be
able to send a message "at it" and have it be received on the other end, and
be routed properly, based on the recipient's rules. As the sender, I just
want to be able to send a message and know that the recipient should receive
it.

This parallels having a "from" email address and sending it "to" a recipient
email address. But in this case we're replacing email as the identifier with
a URL.

So if I self-identify as http://twitter.com/factoryjoe and I want to send a
message to http://twitter.com/redmonk, if on that endpoint is a discovery
document that suggests where to send messages and how to sign them so that
the messages will be received and not rejected outright, I think we're
getting somewhere.

I see no reason not to use ATOM or XMPP for this, except that XMPP doesn't
work well with today's shared hosting environments. Perhaps we use XRDS
discovery to point to an XMPP endpoint and then offer a fallback ATOM
endpoint in the case that XMPP would fail?

You know that I'm against inventing unnecessarily -- which is why I pointed
out this microblogging effort. It might not be the way to do it, but it
gives us an example of someone's thinking that's actually been implemented
and gives us something to build against.

Chris


On Wed, Jun 18, 2008 at 11:33 AM, Eran Hammer-Lahav <eran (AT) hueniverse (DOT) com>
wrote:

> My question is given the simplicity of microblogging, assuming we get an
> activity stream spec/solution figured out, wouldn't it implicitly solve the
> "open" microblogging need? Given that a microblogging "action" is the same
> as its "notification", it looks to me to be a specialized subset of activity
> streams.
>
> EHL
>
>
>
> On 6/18/08 11:22 AM, "Stephen Paul Weber" <singpolyma (AT) gmail (DOT) com> wrote:
>
>
>
> > Is this something we could/should implement? How could we make it more
> > "DiSo" friendly? (Sorry I need to read it over but haven't had a chance
> > yet).
>
> I have said this to Steve privately, and I will now say it publicly:
> reinventing messaging protocols over HTTP is a *bad* idea. We have
> protocols (more than one, two very popular ones), *open* *standard*
> protocols (yes, I'm looking square at SMTP and XMPP - as well as NNTP,
> which is less applicable) that do messaging *well* *really well* they
> were, well, *built for it*. They have faced the problems and improved
> to solve them. They stand the test of time, *do* the job, and are
> *widely* implemented. Unless there is a use case that one of the
> existing standards cannot meet (which I doubt more each time I
> consider this), I see no reason to invent anything, only to build
> tools to use what we have.
>
> Furthermore, reinventing content pushing over HTTP is a *bad* idea.
> There are several *open* and *implemented* (although less widely than
> messaging protocols) standards for pushing content *even specifically
> post or blog-type content* over HTTP. XML-RPC and AtomPub, to name
> two.
>
> (Yes, this is a variation on my "please don't invent anything" rant.)
>
> --
> - Stephen Paul Weber (Singpolyma)
>
> Web: http://singpolyma.net/
> Twitter: http://twitter.com/singpolyma
> IM: singpolyma (AT) gmail (DOT) com
>
>
>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "DiSo Project" group.
> To post to this group, send email to diso-project (AT) googlegroups (DOT) com
> To unsubscribe from this group, send email to
> diso-project-unsubscribe (AT) googlegroups (DOT) com
> For more options, visit this group at
> http://groups.google.com/group/diso-project?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>


--
Chris Messina
Citizen-Participant &
Open Source Advocate-at-Large
factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is: [ ] bloggable [X] ask first [ ] private

[Bob Wyman]

Chris,
I can't see any reason why an XRDS file with a link to the appropriate JID
would NOT be the correct way to implement this. Is there something I'm
missing?

bob wyman

On Wed, Jun 18, 2008 at 2:58 PM, Chris Messina <chris.messina (AT) gmail (DOT) com>
wrote:

> Let me frame the challenge/opportunity this way:
> Presume that I have a URL of my own, given a recipient URL, I want to be
> able to send a message "at it" and have it be received on the other end, and
> be routed properly, based on the recipient's rules. As the sender, I just
> want to be able to send a message and know that the recipient should receive
> it.
>
> This parallels having a "from" email address and sending it "to" a
> recipient email address. But in this case we're replacing email as the
> identifier with a URL.
>
> So if I self-identify as http://twitter.com/factoryjoe and I want to send
> a message to http://twitter.com/redmonk, if on that endpoint is a
> discovery document that suggests where to send messages and how to sign them
> so that the messages will be received and not rejected outright, I think
> we're getting somewhere.
>
> I see no reason not to use ATOM or XMPP for this, except that XMPP doesn't
> work well with today's shared hosting environments. Perhaps we use XRDS
> discovery to point to an XMPP endpoint and then offer a fallback ATOM
> endpoint in the case that XMPP would fail?
>
> You know that I'm against inventing unnecessarily -- which is why I pointed
> out this microblogging effort. It might not be the way to do it, but it
> gives us an example of someone's thinking that's actually been implemented
> and gives us something to build against.
>
> Chris
>
>
>

[Blaine Cook]

On Wed, Jun 18, 2008 at 11:58 AM, Chris Messina <chris.messina (AT) gmail (DOT) com>
wrote:

> Presume that I have a URL of my own, given a recipient URL, I want to be
> able to send a message "at it" and have it be received on the other end, and
> be routed properly, based on the recipient's rules. As the sender, I just
> want to be able to send a message and know that the recipient should receive
> it.
>
> This parallels having a "from" email address and sending it "to" a
> recipient email address. But in this case we're replacing email as the
> identifier with a URL.
>

Steve Ivy and I kicked around some ideas last week. They're recorded on the
DiSo project blog here: http://diso-project.org/wiki/messaging-brainstorming


> So if I self-identify as http://twitter.com/factoryjoe and I want to send
> a message to http://twitter.com/redmonk, if on that endpoint is a
> discovery document that suggests where to send messages and how to sign them
> so that the messages will be received and not rejected outright, I think
> we're getting somewhere.
>

Also, people don't self-identify as URLs. The OpenID experiment seems to
have proven this, as the consensus seems to be around using email addresses
(or email address-like identifiers) as OpenID identifiers.


> I see no reason not to use ATOM or XMPP for this, except that XMPP doesn't
> work well with today's shared hosting environments. Perhaps we use XRDS
> discovery to point to an XMPP endpoint and then offer a fallback ATOM
> endpoint in the case that XMPP would fail?
>

I still question the requirement that this stuff run in a dreamhost-like
environment, where you don't have access to run daemons, and to that end can
only offer that the HTTP form of messaging should be a degraded form of
XMPP, not the primary mechanism.

XRDS for this seems like massive overkill. Whatever happened to good 'ol
<link rel>? It works fantastically for RSS feeds, which are alternate
representations of presented data, just like messaging endpoints.


> You know that I'm against inventing unnecessarily -- which is why I pointed
> out this microblogging effort. It might not be the way to do it, but it
> gives us an example of someone's thinking that's actually been implemented
> and gives us something to build against.
>

I appreciate the effort, but frankly, Twitter exports all the microblogging
information using a combination of already-available standards; Atom (maybe
hAtom?), hCard, etc. Why on earth would we seek to re-implement Atom when a
simpler approach satisfies the needs?


>
> Chris
>
>
> On Wed, Jun 18, 2008 at 11:33 AM, Eran Hammer-Lahav <eran (AT) hueniverse (DOT) com>
> wrote:
>
>> My question is given the simplicity of microblogging, assuming we get an
>> activity stream spec/solution figured out, wouldn't it implicitly solve the
>> "open" microblogging need? Given that a microblogging "action" is the same
>> as its "notification", it looks to me to be a specialized subset of activity
>> streams.
>>
>> EHL
>>
>>
>>
>> On 6/18/08 11:22 AM, "Stephen Paul Weber" <singpolyma (AT) gmail (DOT) com> wrote:
>>
>>
>>
>> > Is this something we could/should implement? How could we make it more
>> > "DiSo" friendly? (Sorry I need to read it over but haven't had a chance
>> > yet).
>>
>> I have said this to Steve privately, and I will now say it publicly:
>> reinventing messaging protocols over HTTP is a *bad* idea. We have
>> protocols (more than one, two very popular ones), *open* *standard*
>> protocols (yes, I'm looking square at SMTP and XMPP - as well as NNTP,
>> which is less applicable) that do messaging *well* *really well* they
>> were, well, *built for it*. They have faced the problems and improved
>> to solve them. They stand the test of time, *do* the job, and are
>> *widely* implemented. Unless there is a use case that one of the
>> existing standards cannot meet (which I doubt more each time I
>> consider this), I see no reason to invent anything, only to build
>> tools to use what we have.
>>
>> Furthermore, reinventing content pushing over HTTP is a *bad* idea.
>> There are several *open* and *implemented* (although less widely than
>> messaging protocols) standards for pushing content *even specifically
>> post or blog-type content* over HTTP. XML-RPC and AtomPub, to name
>> two.
>>
>> (Yes, this is a variation on my "please don't invent anything" rant.)
>>
>> --
>> - Stephen Paul Weber (Singpolyma)
>>
>> Web: http://singpolyma.net/
>> Twitter: http://twitter.com/singpolyma
>> IM: singpolyma (AT) gmail (DOT) com
>>
>>
>>
>>
>> --~--~---------~--~----~------------~-------~--~----~
>> You received this message because you are subscribed to the Google Groups
>> "DiSo Project" group.
>> To post to this group, send email to diso-project (AT) googlegroups (DOT) com
>> To unsubscribe from this group, send email to
>> diso-project-unsubscribe (AT) googlegroups (DOT) com
>> For more options, visit this group at
>> http://groups.google.com/group/diso-project?hl=en
>> -~----------~----~----~----~------~----~------~--~---
>>
>>
>
>
> --
> Chris Messina
> Citizen-Participant &
> Open Source Advocate-at-Large
> factoryjoe.com # diso-project.org
> citizenagency.com # vidoop.com
> This email is: [ ] bloggable [X] ask first [ ] private
>

[Bob Wyman]

On Wed, Jun 18, 2008 at 4:52 PM, Blaine Cook <romeda (AT) gmail (DOT) com> wrote:
> XRDS for this seems like massive overkill.
> Whatever happened to good 'ol <link rel>?
> It works fantastically for RSS feeds, which are
> alternate representations of presented data,
> just like messaging endpoints.

I think we may risk over using "good 'ol <link rel>". There is an issue here
of "separation of concerns" or proper modularization. While <link rel> might
"work", it does not seem right to rely on this mechanism for all links to
all resources -- no matter how indirectly they may be related to the page in
which they are found. I suggest that <link rel> should really only be used
to link to resources that have a particular direct relationship to the HTML
page in which the links are found. Links to Atom or RSS syndication files
are typically links to alternative representations of the HTML files in
which they are found and thus would fit the rule that I suggest.

The JID that should be used in sending a message to the "owner" of a page is
only indirectly related to an HTML page itself. Thus, it seems reasonable to
use a mechanism which is explicitly intended to store links to persons or
things with identity -- i.e. the XRDS file.

Today, there aren't many things that get put in XRDS files. The result is
that XRDS files often seem over designed for the limited purpose of
providing links to OpenID services, etc. However, I think we'll find in the
future that users will have a need to associate a broad set of linked
resources to their identities. As this set of commonly linked resources
grows, it will become less and less reasonable to stuff them all into HTML
embedded <link rel>s. It should also be noted that it is quite likely that
in many applications, XRDS files won't actually be maintained as static
files on disk. They will, in fact, be generated on-demand and as a result
will be able to accommodate potentially changing data. (my XRDS file might
contain a link to the resource that describes my current location...)
Forcing links to be stored in HTML would have the effect of discouraging the
use of dynamic sets of links and, even if implemented via various templating
systems, the use of dynamically changing links in HTML files would tend to
make a mess of caching schemes -- even though the changes are not related to
the HTML content itself.

Use <link rel> for what it was intended to be used: Links to resources which
are related to the containing HTML page. Use XRDS files for links that
relate to things which have identity.

bob wyman



> On Wed, Jun 18, 2008 at 11:58 AM, Chris Messina <chris.messina (AT) gmail (DOT) com>
> wrote:
>
>> Presume that I have a URL of my own, given a recipient URL, I want to be
>> able to send a message "at it" and have it be received on the other end, and
>> be routed properly, based on the recipient's rules. As the sender, I just
>> want to be able to send a message and know that the recipient should receive
>> it.
>>
>> This parallels having a "from" email address and sending it "to" a
>> recipient email address. But in this case we're replacing email as the
>> identifier with a URL.
>>
>
> Steve Ivy and I kicked around some ideas last week. They're recorded on the
> DiSo project blog here:
> http://diso-project.org/wiki/messaging-brainstorming
>
>
>> So if I self-identify as http://twitter.com/factoryjoe and I want to send
>> a message to http://twitter.com/redmonk, if on that endpoint is a
>> discovery document that suggests where to send messages and how to sign them
>> so that the messages will be received and not rejected outright, I think
>> we're getting somewhere.
>>
>
> Also, people don't self-identify as URLs. The OpenID experiment seems to
> have proven this, as the consensus seems to be around using email addresses
> (or email address-like identifiers) as OpenID identifiers.
>
>
>> I see no reason not to use ATOM or XMPP for this, except that XMPP doesn't
>> work well with today's shared hosting environments. Perhaps we use XRDS
>> discovery to point to an XMPP endpoint and then offer a fallback ATOM
>> endpoint in the case that XMPP would fail?
>>
>
> I still question the requirement that this stuff run in a dreamhost-like
> environment, where you don't have access to run daemons, and to that end can
> only offer that the HTTP form of messaging should be a degraded form of
> XMPP, not the primary mechanism.
>
> XRDS for this seems like massive overkill. Whatever happened to good 'ol
> <link rel>? It works fantastically for RSS feeds, which are alternate
> representations of presented data, just like messaging endpoints.
>
>
>> You know that I'm against inventing unnecessarily -- which is why I
>> pointed out this microblogging effort. It might not be the way to do it, but
>> it gives us an example of someone's thinking that's actually been
>> implemented and gives us something to build against.
>>
>
> I appreciate the effort, but frankly, Twitter exports all the microblogging
> information using a combination of already-available standards; Atom (maybe
> hAtom?), hCard, etc. Why on earth would we seek to re-implement Atom when a
> simpler approach satisfies the needs?
>
>
>>
>> Chris
>>
>>
>> On Wed, Jun 18, 2008 at 11:33 AM, Eran Hammer-Lahav <eran (AT) hueniverse (DOT) com>
>> wrote:
>>
>>> My question is given the simplicity of microblogging, assuming we get
>>> an activity stream spec/solution figured out, wouldn't it implicitly solve
>>> the "open" microblogging need? Given that a microblogging "action" is the
>>> same as its "notification", it looks to me to be a specialized subset of
>>> activity streams.
>>>
>>> EHL
>>>
>>>
>>>
>>> On 6/18/08 11:22 AM, "Stephen Paul Weber" <singpolyma (AT) gmail (DOT) com> wrote:
>>>
>>>
>>>
>>> > Is this something we could/should implement? How could we make it more
>>> > "DiSo" friendly? (Sorry I need to read it over but haven't had a chance
>>> > yet).
>>>
>>> I have said this to Steve privately, and I will now say it publicly:
>>> reinventing messaging protocols over HTTP is a *bad* idea. We have
>>> protocols (more than one, two very popular ones), *open* *standard*
>>> protocols (yes, I'm looking square at SMTP and XMPP - as well as NNTP,
>>> which is less applicable) that do messaging *well* *really well* they
>>> were, well, *built for it*. They have faced the problems and improved
>>> to solve them. They stand the test of time, *do* the job, and are
>>> *widely* implemented. Unless there is a use case that one of the
>>> existing standards cannot meet (which I doubt more each time I
>>> consider this), I see no reason to invent anything, only to build
>>> tools to use what we have.
>>>
>>> Furthermore, reinventing content pushing over HTTP is a *bad* idea.
>>> There are several *open* and *implemented* (although less widely than
>>> messaging protocols) standards for pushing content *even specifically
>>> post or blog-type content* over HTTP. XML-RPC and AtomPub, to name
>>> two.
>>>
>>> (Yes, this is a variation on my "please don't invent anything" rant.)
>>>
>>> --
>>> - Stephen Paul Weber (Singpolyma)
>>>
>>> Web: http://singpolyma.net/
>>> Twitter: http://twitter.com/singpolyma
>>> IM: singpolyma (AT) gmail (DOT) com
>>>
>>>
>>>
>>>
>>> --~--~---------~--~----~------------~-------~--~----~
>>> You received this message because you are subscribed to the Google Groups
>>> "DiSo Project" group.
>>> To post to this group, send email to diso-project (AT) googlegroups (DOT) com
>>> To unsubscribe from this group, send email to
>>> diso-project-unsubscribe (AT) googlegroups (DOT) com
>>> For more options, visit this group at
>>> http://groups.google.com/group/diso-project?hl=en
>>> -~----------~----~----~----~------~----~------~--~---
>>>
>>>
>>
>>
>> --
>> Chris Messina
>> Citizen-Participant &
>> Open Source Advocate-at-Large
>> factoryjoe.com # diso-project.org
>> citizenagency.com # vidoop.com
>> This email is: [ ] bloggable [X] ask first [ ] private
>>
>
>

[Henry H]

Why the concern for shared hosting? I recently switched to Slicehost (a VPS
provider) and it's about 1000x better than my previous shared hosting
experience. There are no issues with running daemons on VPS. I honestly
believe the hosting market will head this way with everything being hosted
on separate virtual private servers. Prices will come down although paying
$20/month for a 256M / 10GB HD / 100GB bandwidth where you have full admin
rights is not a bad deal.

On Wed, Jun 18, 2008 at 7:25 PM, Bob Wyman <bob (AT) wyman (DOT) us> wrote:

> On Wed, Jun 18, 2008 at 4:52 PM, Blaine Cook <romeda (AT) gmail (DOT) com> wrote:
> > XRDS for this seems like massive overkill.
> > Whatever happened to good 'ol <link rel>?
> > It works fantastically for RSS feeds, which are
> > alternate representations of presented data,
> > just like messaging endpoints.
>
> I think we may risk over using "good 'ol <link rel>". There is an issue
> here of "separation of concerns" or proper modularization. While <link rel>
> might "work", it does not seem right to rely on this mechanism for all links
> to all resources -- no matter how indirectly they may be related to the page
> in which they are found. I suggest that <link rel> should really only be
> used to link to resources that have a particular direct relationship to the
> HTML page in which the links are found. Links to Atom or RSS syndication
> files are typically links to alternative representations of the HTML files
> in which they are found and thus would fit the rule that I suggest.
>
> The JID that should be used in sending a message to the "owner" of a page
> is only indirectly related to an HTML page itself. Thus, it seems reasonable
> to use a mechanism which is explicitly intended to store links to persons or
> things with identity -- i.e. the XRDS file.
>
> Today, there aren't many things that get put in XRDS files. The result is
> that XRDS files often seem over designed for the limited purpose of
> providing links to OpenID services, etc. However, I think we'll find in the
> future that users will have a need to associate a broad set of linked
> resources to their identities. As this set of commonly linked resources
> grows, it will become less and less reasonable to stuff them all into HTML
> embedded <link rel>s. It should also be noted that it is quite likely that
> in many applications, XRDS files won't actually be maintained as static
> files on disk. They will, in fact, be generated on-demand and as a result
> will be able to accommodate potentially changing data. (my XRDS file might
> contain a link to the resource that describes my current location...)
> Forcing links to be stored in HTML would have the effect of discouraging the
> use of dynamic sets of links and, even if implemented via various templating
> systems, the use of dynamically changing links in HTML files would tend to
> make a mess of caching schemes -- even though the changes are not related to
> the HTML content itself.
>
> Use <link rel> for what it was intended to be used: Links to resources
> which are related to the containing HTML page. Use XRDS files for links that
> relate to things which have identity.
>
> bob wyman
>
>
>
>> On Wed, Jun 18, 2008 at 11:58 AM, Chris Messina <chris.messina (AT) gmail (DOT) com>
>> wrote:
>>
>>> Presume that I have a URL of my own, given a recipient URL, I want to be
>>> able to send a message "at it" and have it be received on the other end, and
>>> be routed properly, based on the recipient's rules. As the sender, I just
>>> want to be able to send a message and know that the recipient should receive
>>> it.
>>>
>>> This parallels having a "from" email address and sending it "to" a
>>> recipient email address. But in this case we're replacing email as the
>>> identifier with a URL.
>>>
>>
>> Steve Ivy and I kicked around some ideas last week. They're recorded on
>> the DiSo project blog here:
>> http://diso-project.org/wiki/messaging-brainstorming
>>
>>
>>> So if I self-identify as http://twitter.com/factoryjoe and I want to
>>> send a message to http://twitter.com/redmonk, if on that endpoint is a
>>> discovery document that suggests where to send messages and how to sign them
>>> so that the messages will be received and not rejected outright, I think
>>> we're getting somewhere.
>>>
>>
>> Also, people don't self-identify as URLs. The OpenID experiment seems to
>> have proven this, as the consensus seems to be around using email addresses
>> (or email address-like identifiers) as OpenID identifiers.
>>
>>
>>> I see no reason not to use ATOM or XMPP for this, except that XMPP
>>> doesn't work well with today's shared hosting environments. Perhaps we use
>>> XRDS discovery to point to an XMPP endpoint and then offer a fallback ATOM
>>> endpoint in the case that XMPP would fail?
>>>
>>
>> I still question the requirement that this stuff run in a dreamhost-like
>> environment, where you don't have access to run daemons, and to that end can
>> only offer that the HTTP form of messaging should be a degraded form of
>> XMPP, not the primary mechanism.
>>
>> XRDS for this seems like massive overkill. Whatever happened to good 'ol
>> <link rel>? It works fantastically for RSS feeds, which are alternate
>> representations of presented data, just like messaging endpoints.
>>
>>
>>> You know that I'm against inventing unnecessarily -- which is why I
>>> pointed out this microblogging effort. It might not be the way to do it, but
>>> it gives us an example of someone's thinking that's actually been
>>> implemented and gives us something to build against.
>>>
>>
>> I appreciate the effort, but frankly, Twitter exports all the
>> microblogging information using a combination of already-available
>> standards; Atom (maybe hAtom?), hCard, etc. Why on earth would we seek to
>> re-implement Atom when a simpler approach satisfies the needs?
>>
>>
>>>
>>> Chris
>>>
>>>
>>> On Wed, Jun 18, 2008 at 11:33 AM, Eran Hammer-Lahav <eran (AT) hueniverse (DOT) com>
>>> wrote:
>>>
>>>> My question is given the simplicity of microblogging, assuming we get
>>>> an activity stream spec/solution figured out, wouldn't it implicitly solve
>>>> the "open" microblogging need? Given that a microblogging "action" is the
>>>> same as its "notification", it looks to me to be a specialized subset of
>>>> activity streams.
>>>>
>>>> EHL
>>>>
>>>>
>>>>
>>>> On 6/18/08 11:22 AM, "Stephen Paul Weber" <singpolyma (AT) gmail (DOT) com> wrote:
>>>>
>>>>
>>>>
>>>> > Is this something we could/should implement? How could we make it more
>>>> > "DiSo" friendly? (Sorry I need to read it over but haven't had a
>>>> chance
>>>> > yet).
>>>>
>>>> I have said this to Steve privately, and I will now say it publicly:
>>>> reinventing messaging protocols over HTTP is a *bad* idea. We have
>>>> protocols (more than one, two very popular ones), *open* *standard*
>>>> protocols (yes, I'm looking square at SMTP and XMPP - as well as NNTP,
>>>> which is less applicable) that do messaging *well* *really well* they
>>>> were, well, *built for it*. They have faced the problems and improved
>>>> to solve them. They stand the test of time, *do* the job, and are
>>>> *widely* implemented. Unless there is a use case that one of the
>>>> existing standards cannot meet (which I doubt more each time I
>>>> consider this), I see no reason to invent anything, only to build
>>>> tools to use what we have.
>>>>
>>>> Furthermore, reinventing content pushing over HTTP is a *bad* idea.
>>>> There are several *open* and *implemented* (although less widely than
>>>> messaging protocols) standards for pushing content *even specifically
>>>> post or blog-type content* over HTTP. XML-RPC and AtomPub, to name
>>>> two.
>>>>
>>>> (Yes, this is a variation on my "please don't invent anything" rant.)
>>>>
>>>> --
>>>> - Stephen Paul Weber (Singpolyma)
>>>>
>>>> Web: http://singpolyma.net/
>>>> Twitter: http://twitter.com/singpolyma
>>>> IM: singpolyma (AT) gmail (DOT) com
>>>>
>>>>
>>>>
>>>>
>>>> --~--~---------~--~----~------------~-------~--~----~
>>>> You received this message because you are subscribed to the Google
>>>> Groups "DiSo Project" group.
>>>> To post to this group, send email to diso-project (AT) googlegroups (DOT) com
>>>> To unsubscribe from this group, send email to
>>>> diso-project-unsubscribe (AT) googlegroups (DOT) com
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/diso-project?hl=en
>>>> -~----------~----~----~----~------~----~------~--~---
>>>>
>>>>
>>>
>>>
>>> --
>>> Chris Messina
>>> Citizen-Participant &
>>> Open Source Advocate-at-Large
>>> factoryjoe.com # diso-project.org
>>> citizenagency.com # vidoop.com
>>> This email is: [ ] bloggable [X] ask first [ ] private
>>>
>>
>>
>

[Chris Messina]

Perhaps we just need to code up a demo using this approach and probe
the challenge moot: I'd be thrilled if the building blocks we already
have solve this problem and be put in place immediately!

Chris

Sent by 1G iPhone.

On Jun 18, 2008, at 15:29, "Bob Wyman" <bob (AT) wyman (DOT) us> wrote:

> Chris,
> I can't see any reason why an XRDS file with a link to the
> appropriate JID would NOT be the correct way to implement this. Is
> there something I'm missing?
>
> bob wyman
>
> On Wed, Jun 18, 2008 at 2:58 PM, Chris Messina <chris.messina (AT) gmail (DOT) com
> > wrote:
> Let me frame the challenge/opportunity this way:
>
> Presume that I have a URL of my own, given a recipient URL, I want
> to be able to send a message "at it" and have it be received on the
> other end, and be routed properly, based on the recipient's rules.
> As the sender, I just want to be able to send a message and know
> that the recipient should receive it.
>
> This parallels having a "from" email address and sending it "to" a
> recipient email address. But in this case we're replacing email as
> the identifier with a URL.
>
> So if I self-identify as http://twitter.com/factoryjoe and I want to
> send a message to http://twitter.com/redmonk, if on that endpoint is
> a discovery document that suggests where to send messages and how to
> sign them so that the messages will be received and not rejected
> outright, I think we're getting somewhere.
>
> I see no reason not to use ATOM or XMPP for this, except that XMPP
> doesn't work well with today's shared hosting environments. Perhaps
> we use XRDS discovery to point to an XMPP endpoint and then offer a
> fallback ATOM endpoint in the case that XMPP would fail?
>
> You know that I'm against inventing unnecessarily -- which is why I
> pointed out this microblogging effort. It might not be the way to do
> it, but it gives us an example of someone's thinking that's actually
> been implemented and gives us something to build against.
>
> Chris
>
>
>

[Nick Vidal]

On Wed, Jun 18, 2008 at 9:25 PM, Bob Wyman <bob (AT) wyman (DOT) us> wrote:
> I think we may risk over using "good 'ol <link rel>". There is an issue here
> of "separation of concerns" or proper modularization. While <link rel> might
> "work", it does not seem right to rely on this mechanism for all links to
> all resources -- no matter how indirectly they may be related to the page in
> which they are found. I suggest that <link rel> should really only be used
> to link to resources that have a particular direct relationship to the HTML
> page in which the links are found. Links to Atom or RSS syndication files
> are typically links to alternative representations of the HTML files in
> which they are found and thus would fit the rule that I suggest.

I agree with Bob here. I would like to, in this opportunity, ask some
feedback about the taglink element, a proposal to create semantic
links among Atom streams. This is the conceptual diagram:

incoming stream => base stream => outgoing stream

The base stream is one of my channel. For example: Nick's "XMPP"
channel. Let us suppose Bob has a "PubSub" channel. I'm subscribed to
it. And let us suppose Peter is subscribed to my "XMPP" channel.
Everything Bob publishes on the "PubSub" channel goes to my "XMPP"
channel for approval. And everything I publish on the "XMPP" channel
goes to Peter's "Jabber" channel for approval. So we have:

Bob's "PubSub" => Nick's "XMPP" => Peter's "Jabber"

Each person has an "ISS" channel, where these taglink metadata get's
published. So Nick's "ISS" channel would be:

<iss version="1.0$B!m(B>
$B!D(B
<tag name="XMPP">
<tagcloud type="entries" year="2006|2007|2008$B!m(B
data="0,0,0,0,0,0,4,23,45,32,34,31|
32,44,53,23,43,32,34,64,34,21,35,23|
43,23,34$B!m(B/>
<taglink type="base"
push="xmpp:nick (AT) iss (DOT) im?;node=xmpp"
pull='http://nick.iss.im/category/xmpp'/>
<taglink type="incoming"
push="xmpp:bob (AT) wyman (DOT) us?;node=pubsub"
pull='http://bob.wyman.us/category/pubsub'/>
$B!D(B
<taglink type="outgoing"
push="xmpp:peter (AT) jabber (DOT) org?;node=jabber"
pull='http://peter.jabber.org/category/jabber'/>
$B!D(B
</tag>
$B!D(B
</iss>

This is the most recent format we have. We just merged the old
tagcloud and taglink formats into one. Any feedback is welcome!
Thanks!

Best regards,
Nick

[Nick Vidal]

Notice that the taglink provides both push and pull links. All
channels, including the "ISS" channel, could be published both in XMPP
pubsub nodes, or just a basic blogging software running in a common
web server.

2008/6/19 Nick Vidal <nick (AT) iss (DOT) im>:
> On Wed, Jun 18, 2008 at 9:25 PM, Bob Wyman <bob (AT) wyman (DOT) us> wrote:
>> I think we may risk over using "good 'ol <link rel>". There is an issue here
>> of "separation of concerns" or proper modularization. While <link rel> might
>> "work", it does not seem right to rely on this mechanism for all links to
>> all resources -- no matter how indirectly they may be related to the page in
>> which they are found. I suggest that <link rel> should really only be used
>> to link to resources that have a particular direct relationship to the HTML
>> page in which the links are found. Links to Atom or RSS syndication files
>> are typically links to alternative representations of the HTML files in
>> which they are found and thus would fit the rule that I suggest.
>
> I agree with Bob here. I would like to, in this opportunity, ask some
> feedback about the taglink element, a proposal to create semantic
> links among Atom streams. This is the conceptual diagram:
>
> incoming stream => base stream => outgoing stream
>
> The base stream is one of my channel. For example: Nick's "XMPP"
> channel. Let us suppose Bob has a "PubSub" channel. I'm subscribed to
> it. And let us suppose Peter is subscribed to my "XMPP" channel.
> Everything Bob publishes on the "PubSub" channel goes to my "XMPP"
> channel for approval. And everything I publish on the "XMPP" channel
> goes to Peter's "Jabber" channel for approval. So we have:
>
> Bob's "PubSub" => Nick's "XMPP" => Peter's "Jabber"
>
> Each person has an "ISS" channel, where these taglink metadata get's
> published. So Nick's "ISS" channel would be:
>
> <iss version="1.0$B!m(B>
> $B!D(B
> <tag name="XMPP">
> <tagcloud type="entries" year="2006|2007|2008$B!m(B
> data="0,0,0,0,0,0,4,23,45,32,34,31|
> 32,44,53,23,43,32,34,64,34,21,35,23|
> 43,23,34$B!m(B/>
> <taglink type="base"
> push="xmpp:nick (AT) iss (DOT) im?;node=xmpp"
> pull='http://nick.iss.im/category/xmpp'/>
> <taglink type="incoming"
> push="xmpp:bob (AT) wyman (DOT) us?;node=pubsub"
> pull='http://bob.wyman.us/category/pubsub'/>
> $B!D(B
> <taglink type="outgoing"
> push="xmpp:peter (AT) jabber (DOT) org?;node=jabber"
> pull='http://peter.jabber.org/category/jabber'/>
> $B!D(B
> </tag>
> $B!D(B
> </iss>
>
> This is the most recent format we have. We just merged the old
> tagcloud and taglink formats into one. Any feedback is welcome!
> Thanks!
>
> Best regards,
> Nick
>

[Steven Livingstone-Perez]

For what it’s worth – if you wish to hack a demo I have set up an XMPP Openfire server. It was really to investigate where things are since my last look. To develop a server – or even a client - there is still a lot of work in XMPP (open source *servers other than Openfire were hard to find) which is my only worry.



However, as a packaged solution it was pretty easy. My ISP doesn’t support the default port so I had to use an alternative but managed to connect via Exodus ok and send some messages. I found you can create a new user directly through most clients which is neat.



1. Just enter your desired jabber id in the format username (AT) openid (DOT) org … I am weblivz (AT) openid (DOT) org

2. Choose a password

3. In the connection, enter the host as “openid.org”

4. Change the default port to 5901

5. That’s it.



In view of how easy this was and the number of open source clients available, I can only imagine that this kinds of infrastructure to be a great building block.



My *only* concern is that if you want to run your own server there are a lot of commercial clauses I saw and writing your own is certainly not trivial (unlike writing some simple sender/listener as defined in the openmicroblogging.org contract).



If someone wishes to use this to hack some xrds and do some testing I’d be glad to help out (other than tomorrow morn when I am at a funeral).



Regards,

Steven

http://livz.org



From: diso-project (AT) googlegroups (DOT) com [mailto:diso-project (AT) googlegroups (DOT) com] On Behalf Of Chris Messina
Sent: 19 June 2008 14:21
To: XMPP and Social Networking, Two Great Tastes That Taste Great Together!; diso-project (AT) googlegroups (DOT) com
Subject: [diso-project] Re: [Social] [diso-project] Re: OpenMicroBlogging



Perhaps we just need to code up a demo using this approach and probe the challenge moot: I'd be thrilled if the building blocks we already have solve this problem and be put in place immediately!



Chris

Sent by 1G iPhone.


On Jun 18, 2008, at 15:29, "Bob Wyman" <bob (AT) wyman (DOT) us> wrote:

Chris,
I can't see any reason why an XRDS file with a link to the appropriate JID would NOT be the correct way to implement this. Is there something I'm missing?

bob wyman

On Wed, Jun 18, 2008 at 2:58 PM, Chris Messina <chris.messina (AT) gmail (DOT) com> wrote:

Let me frame the challenge/opportunity this way:



Presume that I have a URL of my own, given a recipient URL, I want to be able to send a message "at it" and have it be received on the other end, and be routed properly, based on the recipient's rules. As the sender, I just want to be able to send a message and know that the recipient should receive it.



This parallels having a "from" email address and sending it "to" a recipient email address. But in this case we're replacing email as the identifier with a URL.



So if I self-identify as http://twitter.com/factoryjoe and I want to send a message to http://twitter.com/redmonk, if on that endpoint is a discovery document that suggests where to send messages and how to sign them so that the messages will be received and not rejected outright, I think we're getting somewhere.



I see no reason not to use ATOM or XMPP for this, except that XMPP doesn't work well with today's shared hosting environments. Perhaps we use XRDS discovery to point to an XMPP endpoint and then offer a fallback ATOM endpoint in the case that XMPP would fail?



You know that I'm against inventing unnecessarily -- which is why I pointed out this microblogging effort. It might not be the way to do it, but it gives us an example of someone's thinking that's actually been implemented and gives us something to build against.



Chris






--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "DiSo Project" group.
To post to this group, send email to diso-project (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to diso-project-unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/diso-project?hl=en
-~----------~----~----~----~------~----~------~--~---

[Steven Livingstone-Perez]

Apologies to those that mailed me – I logged off the remote server and it seemed to close down the service. Ok now.



Thinking about it, I like the idea of an xrds giving you a pointer to the “IM” user service, just not convinced (in simpler cases such as openmicroblogging) it should always be a jabber id.



steven

http://livz.org





From: Steven Livingstone-Perez [mailto:weblivz (AT) hotmail (DOT) com]
Sent: 19 June 2008 17:25
To: 'diso-project (AT) googlegroups (DOT) com'; 'XMPP and Social Networking, Two Great Tastes That Taste Great Together!'
Subject: RE: [diso-project] Re: [Social] [diso-project] Re: OpenMicroBlogging



For what it’s worth – if you wish to hack a demo I have set up an XMPP Openfire server. It was really to investigate where things are since my last look. To develop a server – or even a client - there is still a lot of work in XMPP (open source *servers other than Openfire were hard to find) which is my only worry.



However, as a packaged solution it was pretty easy. My ISP doesn’t support the default port so I had to use an alternative but managed to connect via Exodus ok and send some messages. I found you can create a new user directly through most clients which is neat.



1. Just enter your desired jabber id in the format username (AT) openid (DOT) org … I am weblivz (AT) openid (DOT) org

2. Choose a password

3. In the connection, enter the host as “openid.org”

4. Change the default port to 5901

5. That’s it.



In view of how easy this was and the number of open source clients available, I can only imagine that this kinds of infrastructure to be a great building block.



My *only* concern is that if you want to run your own server there are a lot of commercial clauses I saw and writing your own is certainly not trivial (unlike writing some simple sender/listener as defined in the openmicroblogging.org contract).



If someone wishes to use this to hack some xrds and do some testing I’d be glad to help out (other than tomorrow morn when I am at a funeral).



Regards,

Steven

http://livz.org



From: diso-project (AT) googlegroups (DOT) com [mailto:diso-project (AT) googlegroups (DOT) com] On Behalf Of Chris Messina
Sent: 19 June 2008 14:21
To: XMPP and Social Networking, Two Great Tastes That Taste Great Together!; diso-project (AT) googlegroups (DOT) com
Subject: [diso-project] Re: [Social] [diso-project] Re: OpenMicroBlogging



Perhaps we just need to code up a demo using this approach and probe the challenge moot: I'd be thrilled if the building blocks we already have solve this problem and be put in place immediately!



Chris

Sent by 1G iPhone.


On Jun 18, 2008, at 15:29, "Bob Wyman" <bob (AT) wyman (DOT) us> wrote:

Chris,
I can't see any reason why an XRDS file with a link to the appropriate JID would NOT be the correct way to implement this. Is there something I'm missing?

bob wyman

On Wed, Jun 18, 2008 at 2:58 PM, Chris Messina <chris.messina (AT) gmail (DOT) com> wrote:

Let me frame the challenge/opportunity this way:



Presume that I have a URL of my own, given a recipient URL, I want to be able to send a message "at it" and have it be received on the other end, and be routed properly, based on the recipient's rules. As the sender, I just want to be able to send a message and know that the recipient should receive it.



This parallels having a "from" email address and sending it "to" a recipient email address. But in this case we're replacing email as the identifier with a URL.



So if I self-identify as http://twitter.com/factoryjoe and I want to send a message to http://twitter.com/redmonk, if on that endpoint is a discovery document that suggests where to send messages and how to sign them so that the messages will be received and not rejected outright, I think we're getting somewhere.



I see no reason not to use ATOM or XMPP for this, except that XMPP doesn't work well with today's shared hosting environments. Perhaps we use XRDS discovery to point to an XMPP endpoint and then offer a fallback ATOM endpoint in the case that XMPP would fail?



You know that I'm against inventing unnecessarily -- which is why I pointed out this microblogging effort. It might not be the way to do it, but it gives us an example of someone's thinking that's actually been implemented and gives us something to build against.



Chris






--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "DiSo Project" group.
To post to this group, send email to diso-project (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to diso-project-unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/diso-project?hl=en
-~----------~----~----~----~------~----~------~--~---

[Peter Saint-Andre]

On 06/18/2008 12:58 PM, Chris Messina wrote:

> I see no reason not to use ATOM or XMPP for this, except that XMPP doesn't
> work well with today's shared hosting environments.

Says who? DreamHost, GMX, and other shared hosting companies offer XMPP
support. I don't see the problem.

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Peter Saint-Andre]

On 06/18/2008 5:52 PM, Blaine Cook wrote:

> I appreciate the effort, but frankly, Twitter exports all the microblogging
> information using a combination of already-available standards; Atom (maybe
> hAtom?), hCard, etc. Why on earth would we seek to re-implement Atom when a
> simpler approach satisfies the needs?

Agreed -- let's see how far we can get with widely-deployed technologies
and only then try to fill any remaining gaps.

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Steve Ivy]

Hi Peter - welcome to the conversation!

From my POV, the main goal of building on XMPP is to provide as
near-realtime notifications of social events in this nascient social
framework. And XMPP (and it's various and numerous extensions ;-) )
provides 90% of those needs. The "last mile" however, is the web view
of that data stream - or, of course, a snapshot of it as it existed
when the request was made. That last mile has been the thorn in the
side of the shared-hosting user.

I initially started building a wordpress XMPP plugin [1]. It would log
into an XMPP server for a short time, receive events, then pass those
events through a series of callbacks to let other plugins do stuff
with the messages. It's still a model I like, except for the "php page
logging into xmpp server" bit. two problems with that model:

* It requires the user to setup cron or similar to trigger the code
that periodically connects to the server, and
* It requires the server to be configured to queue messages for the
user if they're not logged in.

Both of these need to be solved in order for the shared-hosting user
to participate in this real-time network.

Chris pointed earlier to someone who's created a prototype
xmpp->atompub bridge. That approach sounds to me like a GREAT way to
have new notifications selectively published into a stateless (which
is really the limitation for a shared-hosting user) environment.
WordPress and MovableType (and quite a few others) support AtomPub so
it makes a lot of sense to me.

At the beginning, I took the position that any DiSo code should run
under that stateless, shared-hosting limitation. As I look at it now,
though, I think that having DiSo plugins for stateful systems like
jabber servers makes all the sense in the world. If that wordpress
user wants access to these features, they just need to have access to
a provider that offers (in this case) a compatible xmpp service.

Ok, that was a bit long-winded, but if we can harness the power of a
real-time system like XMPP without losing the participation of the
small/self-hosted users, then things reach a new level of WIN.

--Steve

[1] http://code.google.com/p/diso/source/browse/wordpress/wp-xmpp/trunk/xmpp-client.php

On Thu, Jun 19, 2008 at 11:47 AM, Peter Saint-Andre <stpeter (AT) stpeter (DOT) im> wrote:
> On 06/18/2008 12:58 PM, Chris Messina wrote:
>
>> I see no reason not to use ATOM or XMPP for this, except that XMPP doesn't
>> work well with today's shared hosting environments.
>
> Says who? DreamHost, GMX, and other shared hosting companies offer XMPP
> support. I don't see the problem.
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>



--
Steve Ivy
http://redmonk.net // http://diso-project.org
This email is: [ ] bloggable [x] ask first [ ] private

[Steve Ivy]

Another aspect of using XMPP for social networking notifications which
confuses me is this:

At which JID should I receive these notifications? I don't really want
"so and so would like to friend you" and "your friend is now a zombie
and ate your brain" messages coming to my iChat, adium, or gaim
window. And yet, I don't really want to maintain any more JIDs than I
need to.

In addition, there's the issue of message capture by different
clients. If I *am* logged in via a chat client to the same JID that my
DiSo-enabled site is using, will I lose messages if the real-time
client is available to receive it but my "social inbox" client has not
connected recently?

Can using different resources (my-jid (AT) server (DOT) org/ichat,
my-jid (AT) server (DOT) org/website) help solve this? How widely are resources
supported?

I hope that some of you in the XMPP world can set me straight...

--Steve

On Thu, Jun 19, 2008 at 12:05 PM, Steve Ivy <steveivy (AT) gmail (DOT) com> wrote:
> Hi Peter - welcome to the conversation!
>
> From my POV, the main goal of building on XMPP is to provide as
> near-realtime notifications of social events in this nascient social
> framework. And XMPP (and it's various and numerous extensions ;-) )
> provides 90% of those needs. The "last mile" however, is the web view
> of that data stream - or, of course, a snapshot of it as it existed
> when the request was made. That last mile has been the thorn in the
> side of the shared-hosting user.
>
> I initially started building a wordpress XMPP plugin [1]. It would log
> into an XMPP server for a short time, receive events, then pass those
> events through a series of callbacks to let other plugins do stuff
> with the messages. It's still a model I like, except for the "php page
> logging into xmpp server" bit. two problems with that model:
>
> * It requires the user to setup cron or similar to trigger the code
> that periodically connects to the server, and
> * It requires the server to be configured to queue messages for the
> user if they're not logged in.
>
> Both of these need to be solved in order for the shared-hosting user
> to participate in this real-time network.
>
> Chris pointed earlier to someone who's created a prototype
> xmpp->atompub bridge. That approach sounds to me like a GREAT way to
> have new notifications selectively published into a stateless (which
> is really the limitation for a shared-hosting user) environment.
> WordPress and MovableType (and quite a few others) support AtomPub so
> it makes a lot of sense to me.
>
> At the beginning, I took the position that any DiSo code should run
> under that stateless, shared-hosting limitation. As I look at it now,
> though, I think that having DiSo plugins for stateful systems like
> jabber servers makes all the sense in the world. If that wordpress
> user wants access to these features, they just need to have access to
> a provider that offers (in this case) a compatible xmpp service.
>
> Ok, that was a bit long-winded, but if we can harness the power of a
> real-time system like XMPP without losing the participation of the
> small/self-hosted users, then things reach a new level of WIN.
>
> --Steve
>
> [1] http://code.google.com/p/diso/source/browse/wordpress/wp-xmpp/trunk/xmpp-client.php
>
> On Thu, Jun 19, 2008 at 11:47 AM, Peter Saint-Andre <stpeter (AT) stpeter (DOT) im> wrote:
>> On 06/18/2008 12:58 PM, Chris Messina wrote:
>>
>>> I see no reason not to use ATOM or XMPP for this, except that XMPP doesn't
>>> work well with today's shared hosting environments.
>>
>> Says who? DreamHost, GMX, and other shared hosting companies offer XMPP
>> support. I don't see the problem.
>>
>> Peter
>>
>> --
>> Peter Saint-Andre
>> https://stpeter.im/
>>
>>
>
>
>
> --
> Steve Ivy
> http://redmonk.net // http://diso-project.org
> This email is: [ ] bloggable [x] ask first [ ] private
>



--
Steve Ivy
http://redmonk.net // http://diso-project.org
This email is: [ ] bloggable [x] ask first [ ] private

[Peter Saint-Andre]

On 06/18/2008 6:25 PM, Bob Wyman wrote:
> On Wed, Jun 18, 2008 at 4:52 PM, Blaine Cook <romeda (AT) gmail (DOT) com> wrote:
>> XRDS for this seems like massive overkill.
>> Whatever happened to good 'ol <link rel>?
>> It works fantastically for RSS feeds, which are
>> alternate representations of presented data,
>> just like messaging endpoints.
>
> I think we may risk over using "good 'ol <link rel>". There is an issue here
> of "separation of concerns" or proper modularization. While <link rel> might
> "work", it does not seem right to rely on this mechanism for all links to
> all resources -- no matter how indirectly they may be related to the page in
> which they are found. I suggest that <link rel> should really only be used
> to link to resources that have a particular direct relationship to the HTML
> page in which the links are found. Links to Atom or RSS syndication files
> are typically links to alternative representations of the HTML files in
> which they are found and thus would fit the rule that I suggest.
>
> The JID that should be used in sending a message to the "owner" of a page is
> only indirectly related to an HTML page itself.

How is contacting the page owner / creator less "direct" than finding an
alternative representation of the content? If the web is to be truly
social then ISTM that it's completely appropriate to provide links to
content creators, discussion forums, microblogging feeds, and anything
else of interest.

> Thus, it seems reasonable to
> use a mechanism which is explicitly intended to store links to persons or
> things with identity -- i.e. the XRDS file.
>
> Today, there aren't many things that get put in XRDS files. The result is
> that XRDS files often seem over designed for the limited purpose of
> providing links to OpenID services, etc. However, I think we'll find in the
> future that users will have a need to associate a broad set of linked
> resources to their identities. As this set of commonly linked resources
> grows, it will become less and less reasonable to stuff them all into HTML
> embedded <link rel>s. It should also be noted that it is quite likely that
> in many applications, XRDS files won't actually be maintained as static
> files on disk. They will, in fact, be generated on-demand and as a result
> will be able to accommodate potentially changing data. (my XRDS file might
> contain a link to the resource that describes my current location...)
> Forcing links to be stored in HTML would have the effect of discouraging the
> use of dynamic sets of links and, even if implemented via various templating
> systems, the use of dynamically changing links in HTML files would tend to
> make a mess of caching schemes -- even though the changes are not related to
> the HTML content itself.
>
> Use <link rel> for what it was intended to be used: Links to resources which
> are related to the containing HTML page. Use XRDS files for links that
> relate to things which have identity.

Says who? Can't a link point to any URI, not just a web page? I don't
see any such restriction in the HTML 4.0 spec.

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Steven Livingstone-Perez]

> If I *am* logged in via a chat client to the same JID that my
DiSo-enabled site is using, will I lose messages if the real-time
client is available to receive it but my "social inbox" client has not
connected recently?

This is *exactly* what I found in my prototype. If you have your test client and Google Talk logged into the same account you get a message to them both. If you are offline and then you online, you get the message to the one you log with first.

I had considered whether you need separate id's - weblivz (AT) gmail (DOT) com versus weblivz (AT) social (DOT) gmail.com but that's a pain.

As an extension to this idea, say you are in a "room" as per FriendFeed (or Twitter hastags) and you want to receive the generic messages but not have to be a friend of everyone (you are a friend of the room) - how best to support this? (a brief look seems to indicate that it *can* be done as part of the infrastructure, I'm just now sure). Maybe this is what you are saying in your first point.

steven
http://livz.org

-----Original Message-----
From: diso-project (AT) googlegroups (DOT) com [mailto:diso-project (AT) googlegroups (DOT) com] On Behalf Of Steve Ivy
Sent: 19 June 2008 20:20
To: diso-project (AT) googlegroups (DOT) com; social (AT) xmpp (DOT) org
Subject: [diso-project] Re: [Social] [diso-project] Re: OpenMicroBlogging


Another aspect of using XMPP for social networking notifications which
confuses me is this:

At which JID should I receive these notifications? I don't really want
"so and so would like to friend you" and "your friend is now a zombie
and ate your brain" messages coming to my iChat, adium, or gaim
window. And yet, I don't really want to maintain any more JIDs than I
need to.

In addition, there's the issue of message capture by different
clients. If I *am* logged in via a chat client to the same JID that my
DiSo-enabled site is using, will I lose messages if the real-time
client is available to receive it but my "social inbox" client has not
connected recently?

Can using different resources (my-jid (AT) server (DOT) org/ichat,
my-jid (AT) server (DOT) org/website) help solve this? How widely are resources
supported?

I hope that some of you in the XMPP world can set me straight...

--Steve

On Thu, Jun 19, 2008 at 12:05 PM, Steve Ivy <steveivy (AT) gmail (DOT) com> wrote:
> Hi Peter - welcome to the conversation!
>
> From my POV, the main goal of building on XMPP is to provide as
> near-realtime notifications of social events in this nascient social
> framework. And XMPP (and it's various and numerous extensions ;-) )
> provides 90% of those needs. The "last mile" however, is the web view
> of that data stream - or, of course, a snapshot of it as it existed
> when the request was made. That last mile has been the thorn in the
> side of the shared-hosting user.
>
> I initially started building a wordpress XMPP plugin [1]. It would log
> into an XMPP server for a short time, receive events, then pass those
> events through a series of callbacks to let other plugins do stuff
> with the messages. It's still a model I like, except for the "php page
> logging into xmpp server" bit. two problems with that model:
>
> * It requires the user to setup cron or similar to trigger the code
> that periodically connects to the server, and
> * It requires the server to be configured to queue messages for the
> user if they're not logged in.
>
> Both of these need to be solved in order for the shared-hosting user
> to participate in this real-time network.
>
> Chris pointed earlier to someone who's created a prototype
> xmpp->atompub bridge. That approach sounds to me like a GREAT way to
> have new notifications selectively published into a stateless (which
> is really the limitation for a shared-hosting user) environment.
> WordPress and MovableType (and quite a few others) support AtomPub so
> it makes a lot of sense to me.
>
> At the beginning, I took the position that any DiSo code should run
> under that stateless, shared-hosting limitation. As I look at it now,
> though, I think that having DiSo plugins for stateful systems like
> jabber servers makes all the sense in the world. If that wordpress
> user wants access to these features, they just need to have access to
> a provider that offers (in this case) a compatible xmpp service.
>
> Ok, that was a bit long-winded, but if we can harness the power of a
> real-time system like XMPP without losing the participation of the
> small/self-hosted users, then things reach a new level of WIN.
>
> --Steve
>
> [1] http://code.google.com/p/diso/source/browse/wordpress/wp-xmpp/trunk/xmpp-client.php
>
> On Thu, Jun 19, 2008 at 11:47 AM, Peter Saint-Andre <stpeter (AT) stpeter (DOT) im> wrote:
>> On 06/18/2008 12:58 PM, Chris Messina wrote:
>>
>>> I see no reason not to use ATOM or XMPP for this, except that XMPP doesn't
>>> work well with today's shared hosting environments.
>>
>> Says who? DreamHost, GMX, and other shared hosting companies offer XMPP
>> support. I don't see the problem.
>>
>> Peter
>>
>> --
>> Peter Saint-Andre
>> https://stpeter.im/
>>
>>
>
>
>
> --
> Steve Ivy
> http://redmonk.net // http://diso-project.org
> This email is: [ ] bloggable [x] ask first [ ] private
>



--
Steve Ivy
http://redmonk.net // http://diso-project.org
This email is: [ ] bloggable [x] ask first [ ] private

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "DiSo Project" group.
To post to this group, send email to diso-project (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to diso-project-unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/diso-project?hl=en
-~----------~----~----~----~------~----~------~--~---

[John Breslin]

Hiya -

In case you might be interested, we have recently described and shown
how an open and decentralised microblogging system can work. In a paper
that we (Alexandre Passant, Tuukka Hastrup, Uldis Bojars and I) have
written for SFSW 2008, a prototype called SMOB for distributed /
decentralised microblogging is described: "Microblogging: A Semantic Web
and Distributed Approach" -
http://www.semanticscripting.org/SFSW2008/papers/11.pdf

Check out the SMOB page at http://smob.sioc-project.org for server and
client code downloads. Screenshots at http://url.ie/djz

The prototype uses FOAF and SIOC to model microbloggers, their
properties, account and service information, and the microblog updates
that users create. A multitude of publishing services can ping one or a
set of aggregating servers as selected by each user, and it is important
to note that users retain control of their own data through self hosting.

The aggregate view of microblogs use ARC2 for storage / querying and
Exhibit (from SIMILE MIT) for the user interface. Security and privacy
are open issues, but can be addressed in some part by requiring OpenID
authentication.

For those who want to try out this distributed microblogging client, you
can install it by doing a: # svn co
http://smob.googlecode.com/svn/trunk/client/

(Needs a site with PHP4 or greater.) Then making changes according to
the README file (e.g. tell it which servers to ping).

You can also try the anonymous client at:
http://smob.sioc-project.org/client

Then, the server view is available at:
http://smob.sioc-project.org/server (you can also get the code at
http://smob.googlecode.com/svn/trunk/server/)

If you install your own client, you can configure it to post to your
Twitter account simultaneously.

BTW, this is my first post to the list; I meant to post earlier about
possible XMPP / SIOC crossovers but will do another day...

Thanks,

John.
--

[Bob Wyman]

On Thu, Jun 19, 2008 at 12:26 PM, Peter Saint-Andre <stpeter (AT) stpeter (DOT) im>
wrote:
> How is contacting the page owner / creator less "direct"
> than finding an alternative representation of the content?
> If the web is to be truly social then ISTM that it's
> completely appropriate to provide links to content
> creators, discussion forums, microblogging feeds,
> and anything else of interest.

Clearly, the owner or a creator of a page is not an alternative
representation of the page... In any case, the long term issue here will be:
"How many and which <link rel>'s are appropriate content for a web page and
if there are any links which are not appropriate, where should they be
placed?" I hope that people can look ahead to the future and realize that
there are potentially many links that we would want to make from some
"identity root" for an individual to services and resources that are
associated with the identified individual. Today, when there are few such
links, it "works" to have them all embedded in a "home HTML" page. But,
we'll eventually get to the point when overloading <link rel=> that starts
to feel very cumbersome. At that point, we're likely to look to some
mechanism like XRDS files and we'll undoubtedly regret the number of
historical "standards" that establish the expectation that some links are in
HTML pages and other are not.

I argue that we as we move forward, we have an obligation to try to
anticipate where we're going. Let's avoid building up practices today that
are fairly certain to be considered unfortunate in the future. This is why I
argue that we should limit embedded <link rel> use to links that are
directly related to the content in which they are found. In my reading of
the situation, I would consider a link to an XRDS file which describes that
page owner/creator as something which is "related to the page." That linked
XRDS file is, however, where you should look to find attributes of the
page's owner (such as JID, email address, address, social network
membership, current location, etc.).

bob wyman

[Jean-Marc Liotier]

Also sprach Steve Ivy [Thu, Jun 19, 2008 at 12:20:23PM -0700] :
>
> At which JID should I receive these notifications? I don't really want
> "so and so would like to friend you" and "your friend is now a zombie
> and ate your brain" messages coming to my iChat, adium, or gaim
> window. And yet, I don't really want to maintain any more JIDs than I
> need to.

That is what publish-subscribe is about : you only susbscribe to the
streams that you want to receive notification from.

And then not all messages need to be rendered as chat on the client
side. For now most XMPP clients are in fact chat clients - and the
current user experience of notifications through XMPP is therefore the
reception of a message from a "contact". But those notifications could
also be rendered as a news stream the way we render Atom or RSS, or it
could be a ticker tape, or a tray notification popup or whatever you
want to develop your client as...

> In addition, there's the issue of message capture by different
> clients. If I *am* logged in via a chat client to the same JID that my
> DiSo-enabled site is using, will I lose messages if the real-time
> client is available to receive it but my "social inbox" client has not
> connected recently?

When server side history becomes widespread (probably through
implementations of XEP-0136) this problem will cease to exist just as
all my mail clients see the same messages on my IMAP server.

[Steve Ivy]

Yes, PubSub is definitely full of win. Interestingly, the XMPP/AtomPub
bridge is built on PubSub, so all the pieces are *almost* there:

> http://www.cestari.info/2008/6/19/atom-pubsub-module-for-ejabberd

Re-iterating my previous statement, perhaps we should approach the
author about filling out the functionality some and supporting it in
some way?

--Steve

On Thu, Jun 19, 2008 at 2:27 PM, Jean-Marc Liotier <jm (AT) liotier (DOT) org> wrote:
> Also sprach Steve Ivy [Thu, Jun 19, 2008 at 12:20:23PM -0700] :
>>
>> At which JID should I receive these notifications? I don't really want
>> "so and so would like to friend you" and "your friend is now a zombie
>> and ate your brain" messages coming to my iChat, adium, or gaim
>> window. And yet, I don't really want to maintain any more JIDs than I
>> need to.
>
> That is what publish-subscribe is about : you only susbscribe to the
> streams that you want to receive notification from.
>
> And then not all messages need to be rendered as chat on the client
> side. For now most XMPP clients are in fact chat clients - and the
> current user experience of notifications through XMPP is therefore the
> reception of a message from a "contact". But those notifications could
> also be rendered as a news stream the way we render Atom or RSS, or it
> could be a ticker tape, or a tray notification popup or whatever you
> want to develop your client as...
>
>> In addition, there's the issue of message capture by different
>> clients. If I *am* logged in via a chat client to the same JID that my
>> DiSo-enabled site is using, will I lose messages if the real-time
>> client is available to receive it but my "social inbox" client has not
>> connected recently?
>
> When server side history becomes widespread (probably through
> implementations of XEP-0136) this problem will cease to exist just as
> all my mail clients see the same messages on my IMAP server.
>
>



--
Steve Ivy
http://redmonk.net // http://diso-project.org
This email is: [ ] bloggable [x] ask first [ ] private

[Steve Ivy]

Bringing this into this thread...

Sylvain, this is great work, and exactly what we've been discussing
the last day or so - how to get XMPP and web services playing
together. It looks like you've got XMPP packets being pushed *out* to
an AtomPub API, which is a big deal!

Ok, discuss!

--Steve

> All,

> I had started coding around that topic a few weeks ago but got slowed
> down more than I expected. Anywy a first few gradual steps for those
> interested.

> http://www.defuze.org/archives/20-Microblogging-with-XMPP-and-AtomPub.-Dumping-code..html

> - Sylvain

> PS: Sorry for cross posting.

On Thu, Jun 19, 2008 at 4:33 PM, Josh Patterson <jpatterson (AT) floe (DOT) tv> wrote:
>
> If you are looking for example implementations and ideas to draw from,
> id suggest "smob":
>
> http://smob.sioc-project.org/
>
> with code at
>
> http://code.google.com/p/smob/
>
> It's described as "A distributed / decentralised microblogging system,
> built on Semantic Web technologies, mainly SIOC and FOAF."
>
> Josh
>
>
>
>
> On Jun 19, 9:20 am, Chris Messina <chris.mess... (AT) gmail (DOT) com> wrote:
>> Perhaps we just need to code up a demo using this approach and probe
>> the challenge moot: I'd be thrilled if the building blocks we already
>> have solve this problem and be put in place immediately!
>>
>> Chris
>>
>> Sent by 1G iPhone.
>>
>> On Jun 18, 2008, at 15:29, "Bob Wyman" <b... (AT) wyman (DOT) us> wrote:
>>
>> > Chris,
>> > I can't see any reason why an XRDS file with a link to the
>> > appropriate JID would NOT be the correct way to implement this. Is
>> > there something I'm missing?
>>
>> > bob wyman
>>
>> > On Wed, Jun 18, 2008 at 2:58 PM, Chris Messina <chris.mess... (AT) gmail (DOT) com
>> > > wrote:
>> > Let me frame the challenge/opportunity this way:
>>
>> > Presume that I have a URL of my own, given a recipient URL, I want
>> > to be able to send a message "at it" and have it be received on the
>> > other end, and be routed properly, based on the recipient's rules.
>> > As the sender, I just want to be able to send a message and know
>> > that the recipient should receive it.
>>
>> > This parallels having a "from" email address and sending it "to" a
>> > recipient email address. But in this case we're replacing email as
>> > the identifier with a URL.
>>
>> > So if I self-identify ashttp://twitter.com/factoryjoeand I want to
>> > send a message tohttp://twitter.com/redmonk, if on that endpoint is
>> > a discovery document that suggests where to send messages and how to
>> > sign them so that the messages will be received and not rejected
>> > outright, I think we're getting somewhere.
>>
>> > I see no reason not to use ATOM or XMPP for this, except that XMPP
>> > doesn't work well with today's shared hosting environments. Perhaps
>> > we use XRDS discovery to point to an XMPP endpoint and then offer a
>> > fallback ATOM endpoint in the case that XMPP would fail?
>>
>> > You know that I'm against inventing unnecessarily -- which is why I
>> > pointed out this microblogging effort. It might not be the way to do
>> > it, but it gives us an example of someone's thinking that's actually
>> > been implemented and gives us something to build against.
>>
>> > Chris
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "DiSo Project" group.
> To post to this group, send email to diso-project (AT) googlegroups (DOT) com
> To unsubscribe from this group, send email to diso-project-unsubscribe (AT) googlegroups (DOT) com
> For more options, visit this group at http://groups.google.com/group/diso-project?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>



--
Steve Ivy
http://redmonk.net // http://diso-project.org
This email is: [ ] bloggable [x] ask first [ ] private

[Steven Livingstone-Perez]

> But those notifications could also be rendered as a news stream the way we
render Atom or >RSS, or it could be a ticker tape, or a tray notification

Jean-Mark -
Excellent! This scenario is in fact what pushed me to look at XMPP in the
first place (I had been writing my own pubsub system at first due to
confusing commercial clauses in many of the XMPP servers I first looked at).

Do you (or anyone else out there) have pointers to applications that do this
kind of thing with XMPP?

Regards,
Steven
http://livz.org

-----Original Message-----
From: social-bounces (AT) xmpp (DOT) org [mailto:social-bounces (AT) xmpp (DOT) org] On Behalf Of
Jean-Marc Liotier
Sent: 19 June 2008 22:27
To: XMPP and Social Networking, Two Great Tastes That Taste Great Together!
Cc: diso-project (AT) googlegroups (DOT) com
Subject: Re: [Social] [diso-project] Re: [diso-project] Re:
OpenMicroBlogging

Also sprach Steve Ivy [Thu, Jun 19, 2008 at 12:20:23PM -0700] :
>
> At which JID should I receive these notifications? I don't really want
> "so and so would like to friend you" and "your friend is now a zombie
> and ate your brain" messages coming to my iChat, adium, or gaim
> window. And yet, I don't really want to maintain any more JIDs than I
> need to.

That is what publish-subscribe is about : you only susbscribe to the
streams that you want to receive notification from.

And then not all messages need to be rendered as chat on the client
side. For now most XMPP clients are in fact chat clients - and the
current user experience of notifications through XMPP is therefore the
reception of a message from a "contact". But those notifications could
also be rendered as a news stream the way we render Atom or RSS, or it
could be a ticker tape, or a tray notification popup or whatever you
want to develop your client as...

> In addition, there's the issue of message capture by different
> clients. If I *am* logged in via a chat client to the same JID that my
> DiSo-enabled site is using, will I lose messages if the real-time
> client is available to receive it but my "social inbox" client has not
> connected recently?

When server side history becomes widespread (probably through
implementations of XEP-0136) this problem will cease to exist just as
all my mail clients see the same messages on my IMAP server.

[Simon Wistow]

On Wed, Jun 18, 2008 at 04:52:19PM -0700, Blaine Cook said:
> Steve Ivy and I kicked around some ideas last week. They're recorded on the
> DiSo project blog here: http://diso-project.org/wiki/messaging-brainstorming

I've only skimmed through the brainstorming doc and apologies if this
has already been discussed before and I've not found the prior
discussions but ...

We already have a discovery mechanism in place for web and (especially)
mail endpoints - it's DNS and it's well understood and battle proven to
work.

It's extensible too - see SPF and also RFCs 1712 and 1876 which describe
how to provide location information in your zone file.

So instead of

<!-- Messaging 1.0 Endpoint Definition -->
<Service priority="10">
<Type>http://xrdstype.net/messaging/1.0/server</Type>
<URI simple:httpMethod="GET">http://endpoint.mysocialinbox.com</URI>
<LocalID>http://myopenid.example.com</LocalID>
</Service>

why not something like (completely off the top of my head and stolen
liberally from SPF)

example.org. IN TXT "v=messaging1.0 \
server=http://endpoint.mysocialinbox.com \
local-id=http://myopenid.example.com"

or

example.org. MSG endpoint.mysocialinbox.com \
local-id=http://myopenid.example.com


Or, to put it another way, why reinvent everything again over HTTP. Why
have your messaging endpoint rely on your web server (unless of course
the goal is to reinvent messaging over HTTP which is a whole other
argument)?

Again - sorry if I've missed this discussion already.

Simon

[Pedro Melo]

Hi,

On Jun 19, 2008, at 9:58 PM, Simon Wistow wrote:

> On Wed, Jun 18, 2008 at 04:52:19PM -0700, Blaine Cook said:
>> Steve Ivy and I kicked around some ideas last week. They're
>> recorded on the
>> DiSo project blog here: http://diso-project.org/wiki/messaging-
>> brainstorming
>
> I've only skimmed through the brainstorming doc and apologies if this
> has already been discussed before and I've not found the prior
> discussions but ...
>
> We already have a discovery mechanism in place for web and
> (especially)
> mail endpoints - it's DNS and it's well understood and battle
> proven to
> work.
>
> It's extensible too - see SPF and also RFCs 1712 and 1876 which
> describe
> how to provide location information in your zone file.
>
> So instead of
>
> <!-- Messaging 1.0 Endpoint Definition -->
> <Service priority="10">
> <Type>http://xrdstype.net/messaging/1.0/server</Type>
> <URI simple:httpMethod="GET">http://
> endpoint.mysocialinbox.com</URI>
> <LocalID>http://myopenid.example.com</LocalID>
> </Service>
>
> why not something like (completely off the top of my head and stolen
> liberally from SPF)
>
> example.org. IN TXT "v=messaging1.0 \
> server=http://endpoint.mysocialinbox.com \
> local-id=http://myopenid.example.com"
>
> or
>
> example.org. MSG endpoint.mysocialinbox.com \
> local-id=http://myopenid.example.com
>
>
> Or, to put it another way, why reinvent everything again over HTTP.
> Why
> have your messaging endpoint rely on your web server (unless of course
> the goal is to reinvent messaging over HTTP which is a whole other
> argument)?

First let me tell you that I personally agree with you.

The argument against DNS, as I've seen it in the past, is that it
raises the barrier to entry.

Today, publishing files via HTTP (either a new home-page with a
couple of link rel's or an xrds file) is much simpler than publishing
new DNS records.

Also, personal records for vast numbers of users has never been done
before. Today, if we share a domain between us to, I don't believe
you can have different SPF policies for each one.

But that is expected from blogs or people sharing the same social site.

Anyway, I like DNS based approaches for several reasons, but in this
case, I don't think they are a good match.

Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo (AT) simplicidade (DOT) org
Use XMPP!

[Pedro Melo]

Hi,

On Jun 20, 2008, at 8:32 AM, Steven Livingstone-Perez wrote:

>> But those notifications could also be rendered as a news stream
>> the way we
> render Atom or >RSS, or it could be a ticker tape, or a tray
> notification
>
> Jean-Mark -
> Excellent! This scenario is in fact what pushed me to look at XMPP
> in the
> first place (I had been writing my own pubsub system at first due to
> confusing commercial clauses in many of the XMPP servers I first
> looked at).
>
> Do you (or anyone else out there) have pointers to applications
> that do this
> kind of thing with XMPP?

The currently-defunct Twitter IM gateway used to send a pretty cool
atom entry of each notification.

I couldn't find a URL describing a message. Its mentioned briefly here:

http://groups.google.com/group/twitter-development-talk/web/jabber-
pubsub

Best regards,

>
> Regards,
> Steven
> http://livz.org
>
> -----Original Message-----
> From: social-bounces (AT) xmpp (DOT) org [mailto:social-bounces (AT) xmpp (DOT) org] On
> Behalf Of
> Jean-Marc Liotier
> Sent: 19 June 2008 22:27
> To: XMPP and Social Networking, Two Great Tastes That Taste Great
> Together!
> Cc: diso-project (AT) googlegroups (DOT) com
> Subject: Re: [Social] [diso-project] Re: [diso-project] Re:
> OpenMicroBlogging
>
> Also sprach Steve Ivy [Thu, Jun 19, 2008 at 12:20:23PM -0700] :
>>
>> At which JID should I receive these notifications? I don't really
>> want
>> "so and so would like to friend you" and "your friend is now a zombie
>> and ate your brain" messages coming to my iChat, adium, or gaim
>> window. And yet, I don't really want to maintain any more JIDs than I
>> need to.
>
> That is what publish-subscribe is about : you only susbscribe to the
> streams that you want to receive notification from.
>
> And then not all messages need to be rendered as chat on the client
> side. For now most XMPP clients are in fact chat clients - and the
> current user experience of notifications through XMPP is therefore the
> reception of a message from a "contact". But those notifications could
> also be rendered as a news stream the way we render Atom or RSS, or it
> could be a ticker tape, or a tray notification popup or whatever you
> want to develop your client as...
>
>> In addition, there's the issue of message capture by different
>> clients. If I *am* logged in via a chat client to the same JID
>> that my
>> DiSo-enabled site is using, will I lose messages if the real-time
>> client is available to receive it but my "social inbox" client has
>> not
>> connected recently?
>
> When server side history becomes widespread (probably through
> implementations of XEP-0136) this problem will cease to exist just as
> all my mail clients see the same messages on my IMAP server.
>
>

--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo (AT) simplicidade (DOT) org
Use XMPP!

[Steven Livingstone-Perez]

Hi Pedro - thanks for this link.

I actually did some work in using with Jabber PEP (sub part of PubSub spec)
to get OpenMicroblogging style posts (and Twitter style) using simple Atom
entry fragments - sending Atom feeds as well as receiving them. That post
mentions PubSub, but not PEP explicitly so not sure if it uses it.

Doing more on it just now, but it works really nicely and is well supported
by Openfire etc. Some thoughts around how to get twitter or jaiku style web
views of the notifications as they aren't explicitly "friends" but there are
ways around it.

I hadn't seen your link so that is very useful!

Cheers,
Steven
http://livz.org

-----Original Message-----
From: social-bounces (AT) xmpp (DOT) org [mailto:social-bounces (AT) xmpp (DOT) org] On Behalf Of
Pedro Melo
Sent: 23 June 2008 14:01
To: XMPP and Social Networking, Two Great Tastes That Taste Great Together!
Cc: diso-project (AT) googlegroups (DOT) com
Subject: Re: [Social] [diso-project] Re: [diso-project] Re:
OpenMicroBlogging

Hi,

On Jun 20, 2008, at 8:32 AM, Steven Livingstone-Perez wrote:

>> But those notifications could also be rendered as a news stream
>> the way we
> render Atom or >RSS, or it could be a ticker tape, or a tray
> notification
>
> Jean-Mark -
> Excellent! This scenario is in fact what pushed me to look at XMPP
> in the
> first place (I had been writing my own pubsub system at first due to
> confusing commercial clauses in many of the XMPP servers I first
> looked at).
>
> Do you (or anyone else out there) have pointers to applications
> that do this
> kind of thing with XMPP?

The currently-defunct Twitter IM gateway used to send a pretty cool
atom entry of each notification.

I couldn't find a URL describing a message. Its mentioned briefly here:

http://groups.google.com/group/twitter-development-talk/web/jabber-
pubsub

Best regards,

>
> Regards,
> Steven
> http://livz.org
>
> -----Original Message-----
> From: social-bounces (AT) xmpp (DOT) org [mailto:social-bounces (AT) xmpp (DOT) org] On
> Behalf Of
> Jean-Marc Liotier
> Sent: 19 June 2008 22:27
> To: XMPP and Social Networking, Two Great Tastes That Taste Great
> Together!
> Cc: diso-project (AT) googlegroups (DOT) com
> Subject: Re: [Social] [diso-project] Re: [diso-project] Re:
> OpenMicroBlogging
>
> Also sprach Steve Ivy [Thu, Jun 19, 2008 at 12:20:23PM -0700] :
>>
>> At which JID should I receive these notifications? I don't really
>> want
>> "so and so would like to friend you" and "your friend is now a zombie
>> and ate your brain" messages coming to my iChat, adium, or gaim
>> window. And yet, I don't really want to maintain any more JIDs than I
>> need to.
>
> That is what publish-subscribe is about : you only susbscribe to the
> streams that you want to receive notification from.
>
> And then not all messages need to be rendered as chat on the client
> side. For now most XMPP clients are in fact chat clients - and the
> current user experience of notifications through XMPP is therefore the
> reception of a message from a "contact". But those notifications could
> also be rendered as a news stream the way we render Atom or RSS, or it
> could be a ticker tape, or a tray notification popup or whatever you
> want to develop your client as...
>
>> In addition, there's the issue of message capture by different
>> clients. If I *am* logged in via a chat client to the same JID
>> that my
>> DiSo-enabled site is using, will I lose messages if the real-time
>> client is available to receive it but my "social inbox" client has
>> not
>> connected recently?
>
> When server side history becomes widespread (probably through
> implementations of XEP-0136) this problem will cease to exist just as
> all my mail clients see the same messages on my IMAP server.
>
>

--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo (AT) simplicidade (DOT) org
Use XMPP!