OpenMicroBlogging

[Chris Messina]

Evan Promodou has put out an early draft of an OpenMicroBlogging spec and I was hoping for some feedback/review from the group:

http://openmicroblogging.org/

Implementation:

http://identi.ca/

Source:

http://identi.ca/doc/source

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).

We definitely need cross-site messaging, and it's something that Steve, Will and Scott Kveton and I brainstormed about recently (Will, how're the videos coming?) so this first go at a spec seems useful to consider.

Chris

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

[Stephen Paul Weber]

> 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: singp...@gmail.com

[B.K. DeLong]

I can't claim to be a technical expert by any means but I'm inclined to agree.

There's a certain communications platform recently plagued with frustrating downtime allegedly tied to its architecture. Even I was questioning why it wasn't using XMPP plus XML extensions as the framework for its unique microblogging vision. Or the fact that, (in theory), IRC has many similar capabilities and most likely could be creatively plugged into utilizing bots. Why recreate the wheel with protocols not designed for fast messaging?

--

B.K. DeLong (K3GRN)
bkde...@pobox.com
+1.617.797.8471

http://www.wkdelong.org Son.
http://www.ianetsec.com Work.
http://www.bostonredcross.org Volunteer.
http://www.carolingia.eastkingdom.org Service.
http://bkdelong.livejournal.com Play.


PGP Fingerprint:
38D4 D4D4 5819 8667 DFD5 A62D AF61 15FF 297D 67FE

FOAF:
http://foaf.brain-stream.org

[Eran Hammer-Lahav]

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

[Steven Livingstone-Perez]

With the intention of at least being controversial here let me put a counter point.

 

Some of the “infrastructure” technologies on the web aren’t particularly simple and often come with an unwanted about of baggage and effort (as well as being platform specific). I remember looking at XMPP for something I was working on and finding it far more complex (I use C# and it was hard to find much that was useful at the time) than I needed and furthermore the effort required to tie it in was outwith “just me”. You just need to look here [1] to see how it easy to be overwhelmed. The RFC for XMPP Core alone is 90 pages.

 

So the platform you mention and we all love got there by designing a vision of what people wanted to see rather than from a technology perspective (sure it came back to bite a bit but they’re still doing ok). You can also consider SGML did a lot of what we needed to do before Xml came along, but even Xml has been diluted to numerous formats and structures (we had Xml then RSS, JSON and so on). I remember RSS 0.91 and thinking at the time – “big deal, it’s just Xml”.

 

So my argument is that services such as microblogging are actually pretty easy to understand and use other (relatively) small protocols such as OAuth, YADIS and so on – basically you can read it in one page or so.

 

The crux of my argument (from a developer perspective) is that i Iike simple interface based stuff that can be joined together to create something complex. You implement how you see fit (one guy and his dog or an enterprise) so long as you agree to the contracts!

 

Then again, perhaps someone knows a way of using XMPP simply J Remember, I’m not necessarily saying an XMPP solution wouldn’t be technically better, just perhaps, to be controversial, harder to gain traction.

 

Regards,

Steven

http://livz.org

 

[1] http://www.xmpp.org/protocols/

[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

--
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

[Josh Patterson]

I'd have to agree here, again we have a simple smtp (afaik) message
pumping pattern, and variations on that theme.

Josh

> IM: singpol...@gmail.com

[Stephen Paul Weber]

> 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.

Yes, I agree that this is something that we want. Although the use
case here might be more that you want to publish a message in general
and the other party wants to be sure they receive it.

> 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 will be shot down, but will suggest that hCard provides us with
this. (Possibly spidering rel=me), hCard can encapsulate the
addresses/endpoints of users on at least two of the aforementioned
protocols (XMPP and SMTP).

> except that XMPP doesn't
> work well with today's shared hosting environments.

Not entirely true. Running your own XMPP *bot* doesn't play well, but
having an XMPP account at your domain is allowed by multiple shared
hosting providers (Dreamhost as an example) and if you have DNS
control over your domain name you can also use the Google Talk
component of Google Apps for your domain to get an XMPP address at
your domain. Those with no domains can just get an address with any
number of existing servers (many already have one with Google or
Livejournal). Also, sending messages over XMPP is getting easier and
easier from shared hosting, with increasingly good Jabber support in
Ruby, Python, and PHP libraries. Just *receiving* those messages in a
*script* is less easy. Certainly not insurmountable if it is
required, but I'm not sure it is.

> discovery to point to an XMPP endpoint and then offer a fallback ATOM
> endpoint in the case that XMPP would fail?

Supporting multiple protocols is often a good idea :)

> 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.

Agreed. This is the subscription model and not a push model, but it's
what is used on the open web for a lot of things today (like
actionstream aggregators, etc).

>Some of the "infrastructure" technologies on the web aren't particularly simple and often come
> with an unwanted about of baggage and effort

That's why I love library authors like @nathan.fritzclan.com, they
abstract the complexity away into a few classes/function calls.

[David Recordon]

Still in this framing I'd go back to Eran's point:

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.

I think we should be looking at Evan's spec in the realm of "Could this solve messaging" in the more generic sense rather than think about micro-messaging as a specific case to implement.  That said, I love what Evan is trying to do in terms of actually shipping a way that this stuff could work.

--David

[Stephen Paul Weber]

> I think we should be looking at Evan's spec in the realm of "Could this
> solve messaging" in the more generic sense

Agreed.

> That said, I love what
> Evan is trying to do in terms of actually shipping a way that this stuff
> could work.

++implementation
--new protocol invention

[Blaine Cook]

On Wed, Jun 18, 2008 at 11:58 AM, Chris Messina <chris....@gmail.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?
 

[Matthew Terenzio]

My point was actually, that any microblogging service in the future that didn't use XMPP might have to re-invent an IM protocol because the expectation is becoming that.

[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" <b...@wyman.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

[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 user...@openid.org  …  I am web...@openid.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

[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:web...@hotmail.com]
Sent: 19 June 2008 17:25
To: 'diso-p...@googlegroups.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 user...@openid.org  …  I am web...@openid.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-p...@googlegroups.com [mailto:diso-p...@googlegroups.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-p...@googlegroups.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!

[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.

[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

--
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-...@server.org/ichat,
my-...@server.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

[Matthew Terenzio]

Same JID, different message-type, no? Then the clients can route the messages to display, store, or handle in whatever way is appropriate

[Peter Saint-Andre]

On 06/18/2008 6:25 PM, Bob Wyman wrote:

> On Wed, Jun 18, 2008 at 4:52 PM, Blaine Cook <rom...@gmail.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.

[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 - web...@gmail.com versus web...@social.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-p...@googlegroups.com [mailto:diso-p...@googlegroups.com] On Behalf Of Steve Ivy
Sent: 19 June 2008 20:20
To: diso-p...@googlegroups.com; soc...@xmpp.org
Subject: [diso-project] Re: [Social] [diso-project] Re: OpenMicroBlogging

[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

[Blaine Cook]

My vision here is that each social app provider can expose a
user...@service.com JID. For example, if you want to contact me on
twitter, my JID is bla...@twitter.com (fully qualified, that's
xmpp:bla...@twitter.com). I don't think that over-riding your GMail
account is a viable or even desirable option.

b.

On Jun 19, 12:39 pm, "Steven Livingstone-Perez" <webl...@hotmail.com>
wrote:

> > 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 - webl...@gmail.com versus webl...@social.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.
>

> stevenhttp://livz.org

>
> -----Original Message-----
> From: diso-p...@googlegroups.com [mailto:diso-p...@googlegroups.com] On Behalf Of Steve Ivy
> Sent: 19 June 2008 20:20
> To: diso-p...@googlegroups.com; soc...@xmpp.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-...@server.org/ichat,
> my-...@server.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
>

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

>
> > On Thu, Jun 19, 2008 at 11:47 AM, Peter Saint-Andre <stpe...@stpeter.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 Ivyhttp://redmonk.net//http://diso-project.org

[Blaine Cook]

I second Steven's take here. Chris cross posted this thread to the
xmpp-social list without providing the context that this discussion
was ongoing on the diso list (*raps Chris on knuckles*), so sorry if
my earlier message seemed out of place.

ejabberd and djabberd are free to use as you see fit, and I know the
Openfire guys have recently worked to make the licensing more open
(especially around components, etc). It's really interesting to me
that Dreamhost provides free XMPP hosting as well, because it really
brings into question the assumption that we need an HTTP-based
mechanism for these things. I fully agree with Eran and Peter Saint-
Andre that re-inventing the wheel is counter-productive here.

I'm a bit at a disadvantage, as building something is worth a million
times more than weighing in on some mailing list. In my defense, and
in defense of using XMPP to do this, I built the xmpp endpoint for
twitter, and Ralph Meijer and I had federation between Twitter and
Jaiku running at the Social Graph Foo Camp. There are roughly a dozen
aggregators that are receiving real-time updates from Twitter (summize
is the highest profile example of this), and there are no less than
four high-profile websites currently working on or investigating using
XMPP to address these concerns.

Last week there were some discussions in which I conceded the point
that in order for sites hosted on dreamhost to be able to do
messaging, HTTP was ideal, but I did so reluctantly, and I offer that
all of these problems have been solved, and trying to solve them again
is a waste of time. Building tools on top of *existing* tools FTW. :-)

FWIW, if anyone has questions about *how* to build these things, I'm
happy to sit down and help work through implementation details.


On Jun 19, 9:25 am, "Steven Livingstone-Perez" <webl...@hotmail.com>
wrote:

> 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 usern...@openid.org  …  I am webl...@openid.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-p...@googlegroups.com [mailto:diso-p...@googlegroups.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-p...@googlegroups.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" <b...@wyman.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...@gmail.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.

[Chris Messina]

Blaine -- great! -- if we can move full-throttle to XMPP, go team! Are
there docs describing how these issues were fixed? Clearly if we have
instructions to follow, I'd rather try them out, see how far we get
and then work backwards.

I think XMPP is also a lot to learn for your typical Drupal/WordPress
coder, but if we do some heavy lifting and get the abstractions and
libraries done right, all those concerns melt away.

Where should we go next?

Sent by 1G iPhone.

[Steve Ivy]

Blaine,

What does having a JID on each service really do for the user, if the
idea is to have notifications all come to one or a few places?
(notifications to the web/inbox, im to the im client)?

--
Steve Ivy
http://redmonk.net // http://diso-project.org

[Steve Ivy]

Would it make sense to approach someone working on an XMPP/HTTP (or
XMPP/AtomPub bridge chris pointed to) about bringing it under the DiSo
umbrella, or at least get active community involvement / development
going?

--

[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 <j...@liotier.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]

Ok, I looked a bit more at that XMPP/AtomPub bridge and realized,
belatedly, that it's going, sort of, the wrong direction. It allows
one to post to a pubsub node via atompub, and makes the collection
available as an atom feed.

Granted, that in itself is awesome.

However, ideally a site could subscribe to the node and have new posts
be pushed put via atompub to the site. This would require some kind of
authentication, which does complicate things. :(

[Eran Hammer-Lahav]

I should write a blog post: Lessoned Learned: DNS is never the answer!

DNS is hardly every available to end users and will not work for any solutions where personal identity is involved.

EHL

[Josh Patterson]

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...@gmail.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...@wyman.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...@gmail.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

[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.

--

[Chris Messina]

I agree. How would WordPress.com or MySpace.com (for example) ever implement this kind of solution for 100s of thousands or millions of members? Or Ning? Maybe I'm missing something but it seems like doing site-wide resolution is the wrong approach, since many different accounts might be served under different paths...

For example:

Http://barcamp.ning.com/users/factoryjoe

And 

Http://foocamp.ning.com/users/factoryjoe

Would it really make sense to resolve those in DNS? I'm really asking because I don't know but am skeptical and prefer link-rel to an xrds-s document.

Chris

Sent by 1G iPhone.

[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-...@xmpp.org [mailto:social-...@xmpp.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-p...@googlegroups.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

[Stephen Paul Weber]

> However, ideally a site could subscribe to the node and have new posts
> be pushed put via atompub to the site. This would require some kind of
> authentication, which does complicate things. :(

Not if it's the site's server. If I run my own server to do this, a
fakecronjob in WP to harvest RSS (or in this case, ATOM) is just as
good as / better than the server hitting me with every message (for
web server scaling/performance, etc) - this more from my exp at
AideRSS than on share hosting, but I think it applies equally in both
places.

[Stephen Paul Weber]

> However, ideally a site could subscribe to the node and have new posts
> be pushed put via atompub to the site. This would require some kind of
> authentication, which does complicate things. :(

Not if it's the site's server. If I run my own server to do this, a

[Stephen Paul Weber]

> DNS is hardly every available to end users and will not work for any
> solutions where personal identity is involved.

And is only useful for discovery on hostnames, not specific URIs.

[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-...@xmpp.org [mailto:social-...@xmpp.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-p...@googlegroups.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,

--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: me...@simplicidade.org
Use XMPP!

[Simon Wistow]

On Thu, Jun 19, 2008 at 10:37:44PM -0400, Chris Messina said:
> How would WordPress.com or MySpace.com (for example) ever implement
> this kind of solution for 100s of thousands or millions of members? Or
> Ning? Maybe I'm missing something but it seems like doing site-wide
> resolution is the wrong approach, since many different accounts might
> be served under different paths...
>
> For example:
>
> Http://barcamp.ning.com/users/factoryjoe
>
> And
>
> Http://foocamp.ning.com/users/factoryjoe

Well, and again, I'm not trying to stir here, just trying to get my head
around the problem space so sorry if I sound combative - I wasn't
proposing a DNS entry for every endpoint but more like email (which we
know scales).

So, just like email you'd define a messaging end point and then to get
messages (say, updates to the page) from that you'd subscribe to the
XMPP stream (or similar) to that page.

So, say for example from Typepad (since I work for Six Apart) and the
domain 'example.typepad.com' - I look up the DNS record for that and get
messaging.example.typepad.com as the endpoint. Then I subscribe to

/@messaging.example.typepad.com

to get every update for the whole domain.

Or

/post/@messaging.example.typepad.com

to get a message for every post.

Or

/post/some_po...@messaging.example.typepad.com

to get every update for a given post.

Or

/pro...@messaging.example.typepad.com

to get a message everytime profiles change.

Or

/profiles/si...@messaging.example.typepad.com

to get everytime my particular profile changes. Or in your example

/users/facto...@messaging.foocamp.ning.com

Obviously that's all a bit rough and ready and I'm kind of thinking
aloud whilst I write but we can show that autocreating jabber-ids works
because we did it for every single LiveJournal user, and this fits in
with existing infrastructure rather than going the "invent new XML
standard" route.

Again, sorry if I'm missing the point here.

Simon

[Blaine Cook]

No, the Twitter PubSub endpoint never supported PEP, and though it's a good fit, there was / is some question in my mind whether it makes sense to have each JID be a PubSub endpoint, or if Twitter (or any service) should have just one pubsub endpoint (e.g., 'twitter.com') with nodes that reflect the users of the service (e.g., 'http://twitter.com/blaine')

b.

[Steven Livingstone-Perez]

Yes – I can see why that is useful. A main difference is the with PEP there is some built in security (certainly in the Jabber servers I have used) that allows you to restrict what someone can do with the endpoint (e.g. you are free to create new nodes within your account) … with general PubSub I guess you manage this yourself.

 

I actually think both are useful under different scenarios.

[David Orchard]

Hi Chris,

 

I wanted to interject partway through the thread to point out that using non-HTTP protocols with http: URIs is totally acceptable, though rarely done.  The W3C TAG is doing some work on this at http://www.w3.org/2001/tag/doc/SchemeProtocols.html.  A few days ago, while strongly criticizing XRI, Roy said "Really, it has far more to do with a basic misunderstanding of web architecture, namely that you have to use HTTP to get a representation of an "http" named resource. " in http://lists.w3.org/Archives/Public/www-tag/2008Jun/0078.html

 

Cheers,

Dave

On Wed, Jun 18, 2008 at 11:58 AM, Chris Messina <chris....@gmail.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

On Wed, Jun 18, 2008 at 11:33 AM, Eran Hammer-Lahav <er...@hueniverse.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" <singp...@gmail.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: singp...@gmail.com

--

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

[Eran Hammer-Lahav]

That statement from Roy is left completely unexplained in his own email which goes on and on about DNS. I would welcome an actual explanation of this extremely non-obvious statement about http URI and HTTP protocol not having to be bound together…

 

EHL

<br