messaging-brainstorming

From DiSo wiki

Jump to: navigation, search

Contents

Messaging and Notifications

Discussion re: providing an api/ui for a messaging hub to aggregate social interaction messages. These might include:

  • direct messages (ala twitter)
  • "friend" requests
  • activity notifications "your friend uploaded 153 photos"

Flow

A conceptual model, per discussions with Chris, Will, Scott, Steve, Larry, David, Blaine, Eran... and a cast of thousands:

  • your site or a third party implements a "messaging hub" that can receive notifications
  • your XRDS-Simple doc identifies your messaging service (SP) endpoint
  • a messaging consumer does discovery on your OpenID and finds your messaging service
  • the consumer sends an RSA-SHA1-signed request to access messaging services; the request contains:
    • the requesting service identity
    • the requesting user's identity (openid)
    • the level of messaging access desired (direct message, activity notification, etc)
    • a callback location for response (since the lag between request and response is > one http conversation)
  • the provider performs XRDS discovery on the requesting user's openid to find a public key (may be scoped to the requesting service - thoughts?)
    • if (the public key validates the signed message && the receiving user approves the request)
      • reply to the callback request with an oauth token scoped to the service, user, and level of access
  • thereafter, the consumer can send authenticated messages/notifications to your messaging hub (possibly via AtomPub, XMPP, etc)
  • messaging providers compete on features:
    • UI
    • site integration
    • supported protocols (message forwarding to email, im, rss, etc)
    • filtering/intelligence
    • etc

Discuss...

Discovery

A completely hypothetical messaging endpoint discovery doc: 

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

A not-entirely hypothetical service/public key discovery doc, based on http://xmlns.com/wot/0.1/#term_PubKey: 

   <!-- the service here is simply a wrapper, since 
        http://xrds-simple.net/core/1.0/#anchor9 says:
        "Extensions MUST be restricted to add only Resource-specific descriptions."
        Eran: recommendation?
   -->
   <Service priority="10">
       <URI>http://requestor.example.com</URI>
       <LocalID>http://myopenid.example.com</LocalID>
       <wot:PubKey rdf:nodeID="KeyB"> 
         <wot:hex_id>E3C9EC9D</wot:hex_id> 
         <wot:length>1024</wot:length> 
         <wot:fingerprint>2A99C49F3482AECF1109FA52A6FF2FC2</wot:fingerprint>
         <wot:Identity>
             <wot:User>
                 <LocalID>http://myopenid.example.com</LocalID>
             </wot:User>
         </wot:Identity>
       </wot:PubKey>
   </Service>

Alternative

This is my (Blaine) simplified take on the matter.

Messages could look like this. OAuth signing is done with : 

 POST /send/ HTTP/1.1
 Host: magnolia-receiver.org
 User-Agent: Thingio/1.0
 Authorization: OAuth oauth_token="xyz",
                      oauth_signature_method="RSA-SHA1",
                      oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",
                      oauth_timestamp="137131200",
                      oauth_nonce="4572616e48616d6d65724c61686176",
                      oauth_version="1.0"
 Content-Type: application/jabber+xml
 Content-Length: nnn

 <?xml version="1.0"?>
 <message from="bob@magnolia-sender.org" to="bill@magnolia-receiver.org">
   <entry xmlns="http://www.w3.org/2005/Atom">
     <title>Atom-Powered Robots Run Amok</title>
     <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
     <updated>2003-12-13T18:30:02Z</updated>
     <author><name>John Doe</name></author>
     <content>Some text.</content>
   </entry>
 </message>

The receiver (magnolia-receiver.org) does a DNS lookup on the from address specified by the sender, and strips the user part, leaving just the domain part. In this case, we have: 

 magnolia-sender.org

Using XRDS-Simple, or something even simpler magnolia-receiver.org looks for the public RSA key hosted at magnolia-receiver.org, like so: 

 GET http://magnolia-sender.org/

Response: 

 <html>
   <head>
     ...
     <link rel="oauth-certificate" href="http://magnolia-sender.org/oauth.pub" />
     ...
   </head>
   <body> ... </body>
 </html>

Using the public key thus obtained, the receiver can verify the signed send request, and thus knows that the sending server was magnolia-sender.org.

(Blaine also brought up OTR which might be interesting.

Prior Art

Blog posts

Messaging systems in (our neck of) the wild

Activity Streams

Misc

Could this model conceivably be extended to support @-messaging and direct messaging (ala twitter) web-wide? 

   @redmonk.net haha keep dreaming, dreamer-boy

1. Service looks up redmonk.net 2. Discovery on messaging service (no, i'm not going to give up on this hub thing) 2a. Get access if necessary 3. Deliver message (with sender's source service and account info in addition to sender's openid)

Retrieved from "http://diso-project.org/wiki/messaging-brainstorming"
Personal tools