[OMB] Changes to the OpenMicroBlogging spec

[Evan Prodromou]

Hi, everyone. I'm going to be working on a draft for the OMB 0.2 spec, 
but I'd like to throw some quick changes past people.

   1. *Scope section*. I'd like to leave some microblogging stuff out of
      scope, namely: syntax for notices, and client APIs. I'd like the
      current OMB spec to concentrate only on the hub-to-hub messaging
      part of microblogging. openmicroblogging.org might be a good home
      for future specs on those issues, but for now, they should be out
      of scope.
   2. *Server identity*. Currently the OAuth "consumer" identity is made
      up of the root URL of the server (like "http://identi.ca/") and a
      blank authorization token. So far, this has been OK, but I'm
      concerned about future problems with spoofed messages. I'd like to
      add an extension to establish a consumer relationship with a real
      authorization token, which can assure that a posted message from
      identi.ca really is coming from identi.ca.
   3. *HTML-rendered notice content*. It turns out that reading a notice
      and rendering it to HTML with hashtags, @-addresses, and all that,
      really requires access to a lot of data on the originating server.
      I'd like to skip all that and just include an HTML snippet in the
      posted message.
   4. *Attn: URIs*. Typically we specify that a notice is
      to-the-attention-of someone with an @ symbol. (We sometimes call
      these "@ replies", although I think that's a misnomer since
      they're not always replies to anything.) It would be good to
      include a list of the URIs of the people to which a notice is
      addressed.
   5. *In-Reply-To URI*. It would also be nice to specify an URI and/or
      an URL for the notice to which a posted notice is in reply.
   6. *Unauthorized posted notices*. This is for when I send an @-notice
      to someone on another server who's not subscribed to me. It's one
      of the things that the Track folks really like. Right now, a
      posted notice needs to be authorized. This would allow a server to
      post a notice with only the consumer (server) token, no
      subscription token. The receiving server would be free to accept
      or reject the notice (based on server or user policy).
   7. *Direct messages*. Notices are by default public. It would be nice
      to have a separate system that specifies that a message is private
      and directed specifically at the receiver.  This would work like
      "d messages" on Laconica or Twitter. I'm not sure if this would
      require another method besides postNotice, or if we'd just add an
      extra flag to say "this is direct and personal".
   8. *Pull-mode subscriptions*. The current subscription process starts
      on the remote service. The listener may discover the listenee on
      their local service (say, by browsing someone else's subscriptions
      list or inbox), and it might be nice to have an "immediate"
      subscription mode. Here, the listener tells the local server they
      want to receive notices, and the local server will generate
      subscription tokens and send them to the remote server directly
      (without the redirect roundtrip for authorization).
   9. *Unsubscribe notification.* It may be nice when a listener cancels
      a subscription on their local server to notify the remote server
      of that cancellation. Currently, the remote server has to send a
      notice, and if it receives a 403 (not authorized) response, then
      it knows the subscription has been canceled.
  10. *XMPP protocol switch.* There's work underway to  do some
      cross-site  microblogging with XMPP (see 
      http://metajack.im/2008/09/15/an_xmpp_microblogging_stack/ ). I
      think we might be able to make this work by including data about
      XMPP pubsub in the OMB XRDS document. Like, "or, if you're
      capable, use XMPP."

I think these are relatively simple changes that fit in pretty clearly 
with the current design of the protocol. Of all of these, I'd probably 
be happy to punt on the XMPP protocol issue -- I think the XMPP side is 
not fully baked yet, and I'm not sure it makes sense to start 
compatibility work without having something to be compatible with.

-Evan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroblogging.org/pipermail/omb/attachments/20090109/e8a14572/attachment.htm>