I don't think anyone should start by building a framework without any conception of what that framework is meant to do. But Diaspora already has an app of sorts, so they wouldn't exactly be doing that.
:)
I'm just teasing, no offense intended. I actually do agree with you and upvoted you - your comment just really reminded me of this quote from Steve Yegge (supposedly found on Reddit): "I upvoted you for the appropriate uses of 'its' and 'their' in the link title, but downvoted you because your link actually appeared on a little-known German social networking site several hours ago. I feel it is important that you understand that this is not a zero-vote of abstention, but rather a single upvote and a single downvote cancelling one another out."
Source: http://steve-yegge.blogspot.com/2009_03_01_archive.html
* Protocol
* Interface
* Framework
* Application
(with lots of intermediate layers)
A concretely realized framework isn't all that much more abstract than an application. Creating a framework doesn't mean you've created a well-defined interface, much less a well-defined protocol.
Moreover, a protocol is pretty much the only thing that has meaning over-a-wire. After all, you don't know what object you're talking to on the other side of a network connection so either you each have a well-defined protocol you're using or you don't.
For example, not many people used Tim Berner-Lee's original web browser but it did help define the standards that then went on to be picked up by Mosaic which was the first really popular web browser. However, by the point that Mosaic came out most of the features of the architecture of the web were in place and remain recognizable to this day.
Surely the goal is to provide common lower levels of a "social" protocol stack and allow as many and different user interface applications to layer on that common core?
That's one of the goals, but it's not the only goal. I think what you're bringing up is what makes social networking somewhat new terrain for open source. So far, open source has been able to dominate the server space because of superior tech implementations for an insanely low price point.
For social applications, that doesn't matter as much when you're trying to draw users. You need a usable UI, you need to learn all the lessons that the proprietary systems have learned over the years. It's not good enough to just have a better technology, you have to present it as well or better than the competition.
I think it's a new trajectory, because there's less incentive for walled gardens to open up than there was for Netscape to use http. So I think this is a necessary trail for open source to blaze through.
So in a lot of ways, there's very much a chicken-or-the-egg dilemma: Usable protocol stack that others can build on, or sizable enough user base that developers want to build on it. And the closest I've seen to open source dealing with these questions was actually, the gnu/linux desktop projects.
It would be interesting if there was an equivalent for social applications... a common server component, an application library and maybe a reference application but with plenty of scope for people to innovate in the UI without the need to continually reinvent the core communication components if they don't want to.
The killer feature that moves people over to distributed social networking is not distributed social networking itself. But third party developers building onto a distributed social networking framework is what will allow the next killer feature to be built.