Skip to main content
 

Social Network Standards...

A look to the past to guide us towards the future. This is a candid, level headed, and enjoyable talk about the way we've failed users.

_Harry Halpin and Blaine Cooke go through the history of standards for social networks and identity, and why they failed._

_The Augmented Social Network_ [1] 1995
RDF/FOAF
EmotionML
RSS -> Atom -> ActivityStreams
XRIs
XMPP
OpenID
OAuth
OpenID 2.0
OpenSocial
PubSubHubbub/Salmon
OpenGraph (HTML for Facebook)
ActivityStreams 2.0 (W3C Social)
Blockchains

[1] http://journals.uic.edu/ojs/index.php/fm/article/view/1068

http://redecentralize.org/conf2015/2016/09/07/13-ten-years-of-standards-failure.html

 

firstgoogleremail

I don't have my  - but I do have the email that started the ball rolling towards my eventual employment.  Seven weeks later I started at Google.

*Date*: 8/7/10
*Subject*: Interesting moves

_I'm intrigued the recent social moves coming out of Google and wonder if there's some part for me in all of this, either from the inside or from the outside._

_Truth be told, I'm not getting my "change the internet for the better" satisfaction at the moment even with the independent time I spend on Opensocial/Shindig/OAuth._

_Would you like to have a short chat in the next week or two?_

 

Happy to see OAuth support for CalDAV.  Still sad that it's always going to be saddled with legacy vCalendar issues.

Happy to see OAuth support for CalDAV.  Still sad that it's always going to be saddled with legacy vCalendar issues.

Both CalDAV and CardDAV suffer from their history and badly need redesigning.  Not much has changed in the 10 years since I was hacking on libical.   I mean, consider the following CDATA chunk from the RFC.  No one should need to parse/generate this ancient format.  It's complicated, finicky and plain awful.

BEGIN:VCALENDAR

   VERSION:2.0

   PRODID:-//Example Corp.//CalDAV Client//EN

   BEGIN:VTIMEZONE

   LAST-MODIFIED:20040110T032845Z

   TZID:US/Eastern

   BEGIN:DAYLIGHT

   DTSTART:20000404T020000

   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4

   TZNAME:EDT

   TZOFFSETFROM:-0500

   TZOFFSETTO:-0400

   END:DAYLIGHT

   BEGIN:STANDARD

   DTSTART:20001026T020000

   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10

   TZNAME:EST

   TZOFFSETFROM:-0400

   TZOFFSETTO:-0500

   END:STANDARD

   END:VTIMEZONE

   BEGIN:VEVENT

   DTSTAMP:20060206T001102Z

   DTSTART;TZID=US/Eastern:20060102T100000

   DURATION:PT1H

   SUMMARY:Event #1

   Description:Go Steelers!

   UID:74855313FA803DA593CD579A@example.com

   END:VEVENT

   END:VCALENDAR

   

Maybe I should standardize SnmpDav?  At least it has XER which would make it slot into XML without the ugliness above.

In any case I hope that a new calendaring standard emerges from this muck that is more developer friendly.

 

I can't wait for the integrations that this will enable.

I can't wait for the integrations that this will enable.

What android app would you like to see enhanced with Google services?

Originally shared by Tim Bray

Oooh, OAuth goodness for the Android ecosystem (via the shiny new Google Play services).

 

Social 2012

Here are my new years thoughts on the social web platforms. I've been pondering what the world can do to get ourselves out of this one man/one graph/one api situation we find ourselves in and what Google can do to help.

Facebook the product and Facebook Connect/APIs have sucked up most of the social web oxygen. Open efforts have largely failed -- the Google-led consortium OpenSocial has been relegated to niche usage like enterprise or contextual gadgets, OpenID use is declining, Webfinger never took off, oEmbed has murky IP, even RSS and Atom are use is declining.

In particular OpenSocial is now paralleling a different OSF -- the _Open Software Foundation_. Remember that? DEC/IBM/etal banded together to fight off a common enemy (Solaris/AT&T or Windows). There was some decent output from it (I loved me some Tru64 OSF/1 Unix) but in the end it was Linux that disrupted and became the server standard while Windows claimed the defacto client standard. Today both OSFs are in decline and don't define the market.
So what to do? Here are a few of my ideas, what about yours?

* Obviously getting market share for Google+ the product and Google+ the platform helps, it provides an alternative. However if we're not careful we end up with a Coke/Pepsi duopoly, since much of our growth will come at the expense of the wider ecosystem before it starts to take from Facebook.

* Try to build on open standards where it sees broad based usage. OAuth 2.0 is something that everyone (including FB) has actually implemented. Activity Streams and schema.org are ascending. Add social to these where it makes sense.

* Try to nurture the next disruptor and be prepared to jump on it when it comes. Any technology that Google promotes as "open" will likely meet the similar fate as OpenSocial. (And I hope schema.org is the exception here...)

* Do something about the Terms of Service encumbered internet that's slowly taking off.

Hopefully sometime in 2012 there can be a way for everyone to work together on social. I hope to live to see the day that Facebook, Google, Twitter, LinkedIn and a hundeds of smaller players can do something that lifts all our boats and benefits users.

 

Not sure what's the process for proposing new rel attributes for XFN..

Not sure what's the process for proposing new rel attributes for XFN..

In any case posting this here for feedback.

Add a new supplementary rel value 'verified' that combines with other rel attributes to indicate that the source believes that this relationship is valid (by using an OAuth API or other means.. For example:

<a href="http://inuus.com" rel="me verified">Paul

 

Just got an email that Plaxo is discontinuing bare OpenId support and only allowing Google/Yahoo/Hotmail/Facebook...

Just got an email that Plaxo is discontinuing bare OpenId support and only allowing Google/Yahoo/Hotmail/Facebook for login. Despite OpenId's shortcomings it's sad to see things regress.

-----------------------------

Hello from Plaxo,

In an effort to improve our login experience for users, Plaxo.com is simplifying and standardizing our sign in options. As such, Plaxo will discontinue support of generic OpenID logins as of 08/23/2011. Instead we're offering login via Google, Yahoo, Hotmail, or Facebook oAuth -- or you can, of course, create a Plaxo specific account.

How will this affect me?

If you use a Google, Yahoo, Hotmail or Facebook openid to login, just click the appropriate button when signing in. Plaxo will ask for permission to use your account credentials; click accept/grant and then go on using Plaxo as you normally would.

If you use any other openid to login, please visit our Forgot Password and follow the instructions for Reset Password, which will create you a Plaxo specific password.

 

Big props to Andrew Davis, Mark W.

Big props to Andrew Davis, Mark W. and the rest of the Opensocial community for getting this done! Major accomplishment.

Originally shared by Evan Prodromou

Voting has started for the new OpenSocial 2.0 specification. If you're not already involved, and you're interested in open apps, this is a great time to get activated. The steps:

1. Sign up here: https://spreadsheets.google.com/spreadsheet/viewform?key=0Aki8A6bvOtZNcGNXZXY1cUtjMk9DQXhvUjNBYlpjWl... Participation in OpenSocial is free and open to all.

2. When you receive notification that you've been added, vote on this revision: http://code.google.com/p/opensocial-resources/source/detail?r=1520

OpenSocial 2.0 is a huge step forward for the specification, incorporating many of the systems (like ActivityStreams and OAuth) that we use on the modern social web. I'm excited by this push -- let's get it released!

 

OpenSocial Roundup

 At hi5 we've been busy busy busy getting OpenSocial up and running.  We released our developer sandbox, and are rapidly implementing features.  So check out the following URLs

 

 

 

Also, here's a copy of my response to Tim O'Reilly's blog post:

OpenSocial: It's the data, stupid

Hi folks,

Good comments all around. However I'd like to posit that data access is _not_ the problem. We've had universal standards for years now with little uptake. Tribe.net, Typepad, LiveJournal and others have supported FOAF for many, many years, which encompasses the OpenSocial Person and Friends APIs. Not much has come of that -- there isn't a large enough base there to get people interested.

Now you have a broad industry consensus on a single way to provide all of the above plus activity stream data. You have a rich client platform that allows you to crack open that data and use it in interesting ways, and finally you have a common standard for social networks to interact with each other based on the REST api.

So Patrick's statement at the Web 2.0 Expo is correct, a app running inside a container only allows you to see what that container shows you. However that does not mean that a container could not contain friend references to external social networks via it's own federation mechanism. Movable Type 4.0 has shown that you can support any OpenID login in a single system, there's no reason to believe that social networks could not leverage OAuth to do the same.

And here's a final point to consider -- you have Myspace opening up to developers. That's huge. That alone is going to draw more developer attention to this problem than much of the oh-so academic discussions of the past few years.

I suggest people that _want_ OpenSocial to solve all the social graph ills get involved on the API mailing list and make sure that those elements are addressed as OpenSocial evolves.

There's a tremendous amount of momentum. Let's not waste this chance.