On Wed, Jun 18, 2008 at 11:58 AM, Chris Messina <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
> 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" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>>
>>
>>
>>
>> --~--~---------~--~----~------------~-------~--~----~
>> You received this message because you are subscribed to the Google Groups
>> "DiSo Project" group.
>> To post to this group, send email to [EMAIL PROTECTED]
>> To unsubscribe from this group, send email to
>> [EMAIL PROTECTED]
>> 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
>

Reply via email to