際際滷

際際滷Share a Scribd company logo

IIW10 NASCAR for Sharing

Download as PPTX, PDF
Will Meyer
Will Meyer

The document discusses using personal discovery protocols like XRD, WebFinger, and OExchange to allow users to share URLs across a variety of services in a personalized way. It explores using these protocols to discover what services a user is logged into or has used in the past to determine the best options to share a URL. The document also discusses challenges around deployment, caching preferences across devices and browsers, and minimizing user friction when discovering sharing options.

1 of 13
Download to read offline
NASCAR for SharingLink-Sharing as Use-Case for Personal DiscoveryXRD : XAuth : WebFinger : Host-Meta : OExchangeIf you liked NASCAR for identity, youll love it for sharing!IIW10
Now
The Use-CasePresent users with personalized options for operating on URL-based content, wherever they encounter it.Personalization must span machines, browsers, sites, and timeServices will NOT necessarily be known at design timeThe user operation:Share/Post is only one verb; see translate, save-for-later, make-PDF, like, hate, etc.
The action is a basic HTTP-GET-based URL exchange (e.g. facebook/share.php?u=<whateverA Precursor ProblemDo we have protocol support for the basics?Need a uniform definition of a service to address service personalizationExchange of Content + Discovery of AvailabilityFor now, lets say yes, via OExchange (www.oexchange.org)URL pattern for endpoints, defined flow control, and discoveryI accept URLs at my Offer endpoint:http://<me>/<whatever>?url=<url>&<etc>That and some info for humans is in my XRD doc:http://<me>/<whatever>/target.xrdYou can discover it from my host-meta or in-page Link tags:rel=http://oexchange.org//related-target
Implementing PersonalizationNow that service == URI, we can move on. But how?http://<service>/<whatever>.xrdhttp://<service>/<whatever>.xrdhttp://<service>/<whatever>.xrdhttp://<service>/<whatever>.xrdhttp://<service>/<whatever>.xrd
And Does it Even Matter?The space of potential services is THE WEB!Is this a Facebook person or a Twitter person?Thats the least of it (e.g. AddThis new-service request queue is ~1000The services across the long tail link-back at more impressive ratesSmaller, more tightly-knit online communities == more heavily endorsed contentPeople I went to high school with vs people who share interestsThere are even more interesting use-casesSend to mom, negotiate the service-in-common
Protocol RequirementsThe set of services I probably want to use:>= the set I am currently logged in to!= the set that Ive used before on this machine>= the set of services known at design timeMinimal user friction in this lookupe.g. a clickable chiclet would be good, if it was the right chiclet Express the services in the form of something discoverablefacebook or twitter strings arentHostnames arent necessarily
Some Current Anti-NASCAR TechniquesStart with a reasonable default set (based on something)Factor in observed behaviorBehavior the tools facilitateBehavior the tools dont facilitate Some employed techniques for handling the unfacilitatedCSS visited hackeryPublisher-cooperative signalsView-analyticsAll stored in cross-domain storage of some sort (3rd party cookies, HTML storage)
Discussion topics
Using XAuth (the specd version)?What it isCentral-serve JS as a means to x-domain HTML5 storageCallers set a string against their hostname, make avail to other hostsRetrievers look it up for a given hostname, if allowedHow it helpsPossible to know if a user interacted with the service on a given hostNo user friction at allHow it helps lessTokens undefined, really just boolean existence checksInformation not shared across browsers, machines, possibly timeNo mechanism for discovery of new servicesModel is somewhat unusual (less a protocol and more a shared serving infrastructure + code)
Using XAuth (a reimagined version)?What it isAdd some meaning to the tokens potentially JSON, expressing interfaces available at specific URLsAllow service-oriented rather than host-oriented lookupHow it helpsNow possible to get all implementations of this interface this user usesCould allow get all implementations of this interface that this user usesHow it helps lessStill fundamentally the same single-browser, shared-server solutionMay be better thought of as a cache (of WebFinger perhaps?)
Using WebFinger?What it isAbility to look up an XRD for a user, using an email address (for all intents and purposes), and get endpoints for specific protocolsHow it helpsServices can look up instances of a specific interface for a user using their email address onlyShared across the web, user agents, etcHow it helps lessDeployment challenges (esp. for provisioning)Potential caching challenges (how recent is the preference data?)Presents a enter your email address user friction point
Other Items?End goal is to allow a user to express the services they prefer to use to operate on URLs they encounter. How?Getting services at auth-time? (Connect)Is it more seamless for the user than an email? Does this need to be authenticated?Can you get it for other people?Protocol state of the stateXAuthWebFingerUsing discovery for even more negotiated-service intermediaries (send to mom use-case)Browser-based, shared storage of prefs

More Related Content

IIW10 NASCAR for Sharing

  • 1. NASCAR for SharingLink-Sharing as Use-Case for Personal DiscoveryXRD : XAuth : WebFinger : Host-Meta : OExchangeIf you liked NASCAR for identity, youll love it for sharing!IIW10
  • 2. Now
  • 3. The Use-CasePresent users with personalized options for operating on URL-based content, wherever they encounter it.Personalization must span machines, browsers, sites, and timeServices will NOT necessarily be known at design timeThe user operation:Share/Post is only one verb; see translate, save-for-later, make-PDF, like, hate, etc.
  • 4. The action is a basic HTTP-GET-based URL exchange (e.g. facebook/share.php?u=<whateverA Precursor ProblemDo we have protocol support for the basics?Need a uniform definition of a service to address service personalizationExchange of Content + Discovery of AvailabilityFor now, lets say yes, via OExchange (www.oexchange.org)URL pattern for endpoints, defined flow control, and discoveryI accept URLs at my Offer endpoint:http://<me>/<whatever>?url=<url>&<etc>That and some info for humans is in my XRD doc:http://<me>/<whatever>/target.xrdYou can discover it from my host-meta or in-page Link tags:rel=http://oexchange.org//related-target
  • 5. Implementing PersonalizationNow that service == URI, we can move on. But how?http://<service>/<whatever>.xrdhttp://<service>/<whatever>.xrdhttp://<service>/<whatever>.xrdhttp://<service>/<whatever>.xrdhttp://<service>/<whatever>.xrd
  • 6. And Does it Even Matter?The space of potential services is THE WEB!Is this a Facebook person or a Twitter person?Thats the least of it (e.g. AddThis new-service request queue is ~1000The services across the long tail link-back at more impressive ratesSmaller, more tightly-knit online communities == more heavily endorsed contentPeople I went to high school with vs people who share interestsThere are even more interesting use-casesSend to mom, negotiate the service-in-common
  • 7. Protocol RequirementsThe set of services I probably want to use:>= the set I am currently logged in to!= the set that Ive used before on this machine>= the set of services known at design timeMinimal user friction in this lookupe.g. a clickable chiclet would be good, if it was the right chiclet Express the services in the form of something discoverablefacebook or twitter strings arentHostnames arent necessarily
  • 8. Some Current Anti-NASCAR TechniquesStart with a reasonable default set (based on something)Factor in observed behaviorBehavior the tools facilitateBehavior the tools dont facilitate Some employed techniques for handling the unfacilitatedCSS visited hackeryPublisher-cooperative signalsView-analyticsAll stored in cross-domain storage of some sort (3rd party cookies, HTML storage)
  • 10. Using XAuth (the specd version)?What it isCentral-serve JS as a means to x-domain HTML5 storageCallers set a string against their hostname, make avail to other hostsRetrievers look it up for a given hostname, if allowedHow it helpsPossible to know if a user interacted with the service on a given hostNo user friction at allHow it helps lessTokens undefined, really just boolean existence checksInformation not shared across browsers, machines, possibly timeNo mechanism for discovery of new servicesModel is somewhat unusual (less a protocol and more a shared serving infrastructure + code)
  • 11. Using XAuth (a reimagined version)?What it isAdd some meaning to the tokens potentially JSON, expressing interfaces available at specific URLsAllow service-oriented rather than host-oriented lookupHow it helpsNow possible to get all implementations of this interface this user usesCould allow get all implementations of this interface that this user usesHow it helps lessStill fundamentally the same single-browser, shared-server solutionMay be better thought of as a cache (of WebFinger perhaps?)
  • 12. Using WebFinger?What it isAbility to look up an XRD for a user, using an email address (for all intents and purposes), and get endpoints for specific protocolsHow it helpsServices can look up instances of a specific interface for a user using their email address onlyShared across the web, user agents, etcHow it helps lessDeployment challenges (esp. for provisioning)Potential caching challenges (how recent is the preference data?)Presents a enter your email address user friction point
  • 13. Other Items?End goal is to allow a user to express the services they prefer to use to operate on URLs they encounter. How?Getting services at auth-time? (Connect)Is it more seamless for the user than an email? Does this need to be authenticated?Can you get it for other people?Protocol state of the stateXAuthWebFingerUsing discovery for even more negotiated-service intermediaries (send to mom use-case)Browser-based, shared storage of prefs