monkinetic weblog | redmonk.net

Today at O’Reilly’s OSCON, David Recordon announced the formation of a new foundation, the Open Web Foundation, with the goal of fostering development of open standards and providing an incubator for working out IPR and patent issues before standards are too widely deployed.

The Open Web Foundation is an attempt to create a home for community-driven specifications. Following the open source model similar to the Apache Software Foundation, the foundation is aimed at building a lightweight framework to help communities deal with the legal requirements necessary to create successful and widely adopted specification.

This is an awesome step and one that has been necessary for a long time. The Apache Foundation has provided a great model for software incubation, but to date there has not been an appropriate place to work out issues with new specifications. The Open Web Foundation will provide that place.

The OWF has a mailing list up for anyone wanting to get involved or follow the discussion. Details on foundation membership, etc, are still forthcoming but knowing the participants I’m certain things will be aboveboard.

I’m really excited to see the OWF come together - the environment in which web technologies are developed has changed, and the OWF is there to help provide a buffer for these new specs to be developed out in the open. As I wrote in Web Green: Cultivating The Open Web:

Like sediment in a river, or potting soil in a greenhouse, each layer we put down supports and affects the ecosystem that grows out of it. We take IP, ethernet, and their like completely for granted - they’ve been standardized and implemented across a worldwide network. That layer is foundation and fertilizer for the next: HTTP, SSL, HTML, XML, and the feed variants that have become the everyday building blocks of our applications and services. These are now settling into the foundation for the services we’re building now: near-real-time publishing and social software stacks. These, in turn, will provide for what comes after, and the philosophical foundations we build into this layer will profoundly affect the health of the next.

So here’s to the OWF: May the foundations of the next web be as open and implementable as the foundations of the first web were, and more.

grass image from pygment.com for whose proprietor I cannot find contact information.

After a fun trip skydiving with my father and two brothers this past week, I wrote up a guest post on Dustin’s new blog on 4 Tips For A Successful Man-venture.

Though a tad awkward to say, ["Man-venture"] sums up easily our two-day combination of fun, adventure, companionship, and mutual support. Ours was a roaring success, and we all came away from it both tired and invigorated, and swearing to do it again in 6-12 months.

It’s been a while since I’ve posted about what’s going on in the DiSo community, and I had started to prepare a list of recent developments to share, but on the way I felt that there was a theme I wanted to address first.

The DiSo Project is first and foremost about enabling/creating a new category of social-networking-enabled websites, not restricted to the large silos but grown organically at the edges of the web - the small and independent sites that are the forerunners and foundations of the communities we now enjoy. How can we best provide a fertile environment, one that encourages, protects, and nurtures this growth?

grass image from pygment.com for whose proprietor I cannot find contact information.

Fertile Foundations

One theme that’s been cropping up on the conference circuit lately, thanks to Chris Messina, Dave Recordon, Jeremy Keith, and others, is this idea of “building the open web“. The internet (based on public, open technical standards), and the early www (based on public, open hypertext formats and protocol specifications), gave “the web” we know its heart and soul. How did that happen, and what will perpetuate the process?

Like sediment in a river, or potting soil in a greenhouse, each layer we put down supports and affects the ecosystem that grows out of it. We take IP, ethernet, and their like completely for granted - they’ve been standardized and implemented across a worldwide network. That layer is foundation and fertilizer for the next: HTTP, SSL, HTML, XML, and the feed variants that have become the everyday building blocks of our applications and services. These are now settling into the foundation for the services we’re building now: near-real-time publishing and social software stacks. These, in turn, will provide for what comes after, and the philosophical foundations we build into this layer will profoundly affect the health of the next.

Building the Open Web

So for the next ecosystem of social and community applications to thrive, we need to make sure that these aspects - public, freely-implementable formats and open standards - are a part of the web as we know it now. Thankfully, it’s happening - witness the growth of open, enabling technoliges like:

• Microformats, basic specs for marking up machine-readable data in human-readable web pages (XFN, hCard, hCalendar, hAtom, hEtc)
• OpenID, open identity solution for web services
• OAuth, an HTTP-based protocol for authentication between services
• XRDS-Simple, which provides discovery for various web services and makes inter-app cooperation that much easier.
• XMPP, a real-time, distributed messaging system that can be integrated into other services.

All these are publicly developed and freely implementable, and active communities have evolved around them to discuss, implement, and evangelize them. This is what building the open web is about: collaborating to build a web that is larger than any company or organization - a web that will encourage new growth.

New Growth

So, given all the effort we’re putting into creating a web that is fertile ground for what’s coming next… what’s coming next? Here’s a look at a few areas DiSo is focusing on as we work on the building blocks of the distributed social network:

Identity

OpenID has focused a lot of attention on putting the User’s online identity back under their control. Rather than maintaining an account on each and every site they use, the User can maintain one or more OpenID accounts, using them as credentials on any of the 10,000+ sites that accept an OpenID for registration and login. With the technology in place, we turn our attention to what identity means, how much of that identity we’re willing to share, and with whom.

Activity

Since the mid 90’s we’ve been working on the problem of how to track what our friends and contacts are doing online, and figure out where the stuff that’s really interesting and relevant to us is happening. Look at the social network silos, and you’ll see that a huge part of what they offer users is the ability (or at least impression) that the user can know what their friends are up to. Sites like Twitter and FriendFeed are making progress on bringing this activity tracking into the light, but to really distribute it all there’s still a lot of work to do.

Here at the edges, we’re making it easy to agregate your own activity, and working on ways to track/follow updates of your friends activity in near-real-time.

Messaging

With OpenID providing a common form of identity, we’ve begun looking at what services can be enabled using that endpoint. One of the services we’re exploring is distributed messaging - friend requests, subscription requests, and direct messages - directed to that endpoint, authenticated via OAuth, and filtered by a messaging service based on user preferences.

Cultivating the Open Web

As the builders - or growers - of this web, it’s our responsibility to look beyond the IPO, beyond the ad-sell, beyond the current crop of buzzwords. We must decide that we’re going to invest in, and give back to, the ecosystem that has supported us. Think of it as Web “Green” - protecting and nurturing and stewarding the web ecology.

Ok, these may be really really stupid or really really practical ideas — so no comments starting with “Steve you’re an idiot!” — but I was thinking today about ways to generate power around the house.

What if electric power could be practically generated and distributed by micro or nano devices embedded in motion-generating fixtures around a house? Opening doors, drawers, running water from faucets - there’s a lot of energy that perhaps could be captured. I doubt it would be a lot of power, but enough, perhaps to charge small devices?

Crazy? Interesting? What do you think?

Over on the DiSo Project blog, I’ve posted about some movement in the XRDS-Simple space over the last week. Next steps: We need to identify generators, parsers, and service definitions, and start working on interop.

DiSo is built on the idea of implementing social networking concepts on existing standards where possible. One of those standards is XRDS Simple, a service description and discovery format that is a part of several recent and upcoming standards including OpenID and OAuth. This weekend I decided to build a generalized service for Movable Type that implements XRDS.

XRDS Simple for Movable Type (version 0.1)

XRDS Simple for Movable Type implements XRDS Simple service discovery. New web services like OpenID and OAuth are encouraging the use of XRDS (eXtensible Resource Descriptor Sequence) (and specifically the new, simplified version) for service discovery.

XRDS Simple for Movable Type is a faceless application that gives plugins a way to register services to be advertised in the discovery document, similar to how plugins can register new streams with Mark’s Action Streams plugin.

Registering A Plugin’s Services

Sample configuration YAML:

xrds_services:
    openid2:
        type: http://specs.openid.net/auth/2.0/server
        # media_type:
        uri: http://endpoint.example.net
        namespace_id: openid
        namespace_uri: http://openid.net/xmlns/1.0
        priority: 10
        # local_id: http://redmonk.net
        local_id_handler: sub { "http://example.com" }

A plugin registers its services with XRDS Simple by including an xrds_services section in config.yaml. In that section are any number of service definitions, each listed under a unique identifier.

Within the service definition are a number of items which generally follow the XRDS Simple spec[1]. Of note are the namespace_id, namespace_uri, and local_id_handler.

Each service can register a namespace to be included in the xml declaration of the discovery document. The namespace_id and namespace_uri parameters are used to construct an xsmlns: attribute, like:

xmlns:openid="http://openid.net/xmlns/1.0"

XRDS also supports the concept of a local id - an identifier for this site or user on the service the discovery document points to. The local_id parameter will be added to the generated document in the service definition. Sometimes the local_id will need to be set programatically. In that case, pass in a coderef as local_id_handler.

local_id_handler: sub { "http://example.com" }

What’s it good for?

XRDS is developing as the discovery mechanism for a new generation of social applications. Eventually, Movable Type’s OpenID server and delegation could be changed to use this simpler yaml-based configuration, and let the plugin generate the appropriate XRDS document, instead of generating the document itself. As Movable Type begins to offer OAuth-based services, those too can be listed - per the OAuth Discovery spec.

Check it out

As this is a faceless application, and there are currently no services in MT using this code, this is really developer-preview code. Download and peruse the plugin - it’s very simple. I’d be interested in feedback on the code and the YAML format as well. Upcoming features include support for multiple Type and MediaType elements (per the spec), as well as support for passing a coderef for parameters instead of static values.

Download

Download XRDS Simple for Movable Type or check it out from the DiSo repository.