Hello StatusNet community, this is Derek reporting to you from StatusNet in Montreal. We are nearing the end of our Google Summer of Code (GSoC) series, and so the student that we will be getting an update from today will be Arunoda Susiripal.

The past while Arunoda has been working hard with his StatusNet mentor Zach Copley, and today I will share with you his update on his accomplishments thus-far, and the things that he is working on for a later date. This is Arunoda's update:

Status.Net Javascript API

It's time again for a report. You might wonder why there was no such a project titled as the one above. Well, at the beginning there was none. This is the same project we named as StatusNet Everywhere, but with the advice from the community, we've changed the name to Status.Net JavaScript API.

Story so far

Phase One of the project has been completed with a huge success. And we are on schedule and we hope to build a relatively stable product at the end of the GSoC time period which has hardly happened in GSoC projects. By the way, you may be wondering about the project we are talking about here, and what it does? You can get a clear idea about the project from the Status.Net wiki. In abstract form, Status.Net Javascript API is an API Wrapper for Status.Net. It runs completely on JavaScript (in your web browser) and a set of widgets performing Status.Net functionalities on a regular web site, whether it is your Personnel, Blog or Company Website.

Stata - Working Demo

You may be wondering what you can do with this. You can do whatever you think you can when it comes to Status.Net and the opportunities for innovation are endless. We've not completed our project yet, however, we have built the API Wrapper for Status.Net. With that, we've built an app which is another User-Interface for identi.ca and it runs on your browser.

Widget Library

As GSoC continues, we are moving into our next phase that we have started, which will be to build a Widget library on the top of the API Wrapper. If we talked about widgets, they are elements displayed on a web page which does some functionality of Status.Net, or displays a summary of information gathered from Status.Net.

Widgets we are about to build include:

• Hovercards
• Profile Box
• Follow Button (like Facebook "Like" button)
• Status Box
• Friend List Box

That's it for now! This is what has been happening with the Status.Net JavaScript API. We would really appreciate your views on this project and contribution of any kind. We hope to increase the development of the project and release a set of widgets which can be used as soon as possible. Stay in touch with the project to see the amazing outcomes!

- Arunoda

Feel free to make your own contributions, and to contact Arunoda or Zach:

Wiki

Project Repository

Contact Arunoda (GSoC Student)

Contact Zach (GSoC Mentor)

A potential security vulnerability was recently announced affecting many implementations of the OpenID and OAuth authentication protocols, including the open-source libraries used by StatusNet.

As a precaution, OpenID has been temporarily disabled on StatusNet cloud-hosted sites while we confirm the situation and get a proper fix installed. We recognize this may be an inconvenience to some users but prefer to err on the side of caution; OpenID should be re-enabled within a day or two at most to minimize disruption. OAuth access to the API is still enabled, which has a lower threat profile as private account settings and major administrator functions cannot be accessed this way.

As always we are doing our best to work with other open-source projects and are submitting our provisional fixes to the authors of the libraries we use; details and links to patches are below the fold.

Details for system administrators:

While we believe the direct threat is low, disabling OpenID logins is a reasonable precaution. In StatusNet 0.9.x, the OpenID plugin is loaded by default and may be disabled by adding this line to config.php:

    unset($config['plugins']['default']['OpenID']);

For older versions of StatusNet, add this config.php setting:

    $config['openid']['enabled'] = false;

If you are brave, you can try patching the copies of the libraries shipped in StatusNet's extlib subdirectory; however these provisional patches have not been formally reviewed and are at your own risk. If you wish to try this, they're linked below:

Details for developers:

• Original vulernability pre-announcement and recommendations
• Provisional patch for php-openid
• Provisional patch for OAuth

Yesterday I spoke about the federated social web what its structure was and why people are interested.

But what will a federated social web do? We don't know, exactly: these kinds of systems tend to change when put into practical use. It took a while for email to handle file attachments reasonably well, and the HTML 5 process shows how much Web interfaces have changed over the last 15 years.

It's reasonable to assume that a federated social web will at least do what monolithic social networking applications do today. To that end, I've listed out some of the most important current features of social networks, generalizing a bit across different networks. I've then outlined where we are with federated social web protocols and software today: how close we're approximating monolithic social networks, and what we need to do next.

• Identity. Identity is your uniqueness. Your name may be John Smith of Cincinnati, OH, but you are distinct from every other John Smith in Cincinnati, past, present, and future. An important part of identity is addressability having a machine readable address that computers and people can use to find you, and only you. Real people can have more than one identity in a social network (compare email, where many people have work and home addresses), but they're not typically linked in any way.

  Because identity is important for remote login and security, it's probably the best-discussed (maybe over-discussed) part of this system.

  There are competing schools of thought on identity and addressing. OpenID borrows the URL format from the Web: http://evan.status.net/. WebFinger, on the other hand, borrows the address format from email: evan@status.net. Whatever address format we use, it's likely to be hierarchical, with an organizational part (status.net) that belongs to the network you use, and an individual part (evan) that's unique within that network.

• Profile. Profile data is any information about you: your name, your avatar, postal address, phone number, favorite color, religion, political orientation, past jobs, education history, what kind of person you want to date, your favorite color, your favorite movies, your current bedside book. Almost all social networks provide a single profile Web page for individuals with all their profile data; some allow you to restrict sensitive data to only a subset of viewers.

  Profile pages fit in well with the way the Web currently works, and it's likely that the federated social web will include dedicated profile pages for each person. Sharing that data programmatically with other systems is less clear-cut; standards like FOAF, hCard and Portable Contacts give us a way to move the data between networks, but keeping it synchronized and up-to-date is hard.

  For privacy, it's easy to have one set of data shown to logged-in users while browsing and a more restrictive set shown to people who aren't logged in. But sharing some protected data with users in your social network that aren't on your server may be trickier. Remote login technologies like OpenID or OAuth might help here.

• Relationships. Declaring relationships to friends and colleagues is the lifeblood of any social network. Some networks allow you to define the nature of the relationship. Some require that both related people approve the relationship (friends), others one one (fan or follow). In either case, some or all people on the network can navigate your list of friends.

  Reading lists of friends or colleagues on the Web is easy. Restricting access to those lists has similar problems to the profile ones mentioned above. Machine-readable relationship formats is one of the best-developed features of federation, with FOAF and XFN leading the way. But actually establishing relationships is one of the least-developed. The follow model is used for OStatus; it basically says, I'm interested enough in you to care about what you do and say.

• Media. Sharing photos, audio, links, video and rich text with friends is a big part of social networks. Some networks specialize in only one medium like photos or video; others cover the spectrum. Sharing office files like word-processing documents and spreadsheets is important for corporate networks, too. Often, other users can comment on media, fave or like it, or reshare the media to their own social network.

  Navigating the media uploaded by another user isn't hard, but, as has come up before, there are some tricky parts with setting permissions based on relationships (only for family and friends). Delivering media remotely isn't well-specified; typically it's pushed as attachments for syndicated activities (see below), if at all. OEmbed can make the presentation easier.

  It's possible with OStatus to like, reshare, and comment on media (or, more precisely, the activities associated with the media), but this happens on the subscriber's server, and the response is pushed to the publisher's server. An interface to let remote users interact with media on the site that provides it is harder, although tools like OpenLike and OExchange may improve that.

  An important subset of this functionality is events; users can post events and others can RSVP for or against. There's a nice little event schema in ActivityStreams; we intend to fit it into the OStatus system in StatusNet.

• Activities. Most social networks show a timeline of activities by a user (Evan posted a picture, Evan liked Michele's link). Some provide an activity dashboard that shows activities by all the users' friends or colleagues. Human-edited status updates are an important part of this feed, with Twitter and other social messaging sites being an extreme example. As with media, downstream users can often like, comment on, or re-broadcast their friends' activities.

  This is where the most activity is happening today in the federated social web. Generating and sharing feeds, with RSS and Atom, is a forte of the open web. The latest development is ActivityStreams, which encodes machine readable information about social activities like posting a video or joining a group. PubSubHubbub is a real-time push protocol that cuts down on the polling typical of RSS feeds. Finally, the Salmon protocol lets subscribers push comments and other notifications upstream to the publishing server. OStatus has tied together all these protocols in a cohesive way.

• Messages. According to some sources, the volume of direct messages on social networking services rivals that of email. Private, direct messages are readable only by sender or recipient and can often have embedded media or links. Some services provide an empty message feature a poke or nudge.

  This is a part of the federated social web that hasn't received enough attention. There is some work going ahead to implement remote private messaging using PubSubHubbub-enabled streams. Others have suggested that email has served this purpose for a few decades and doesn't need to be replaced.

• Groups. Grouping people together is an important part of most social networks. Users can join or quit a group (sometimes requiring the group owners' approval), send private messages to the group (which are distributed to all members), and upload images, video, or other media that belong to that group. Group admins can also announce events or provide a profile for the group.

  Most of the issues for individuals apply for groups, and the standards used for communications and relationships between individuals will largely work for groups. Joining a group is just establishing a relationship with it, for example. Similar issues with restricted browsing profile data and media. OStatus has explicit support for groups, although they're very simple.

• Search. Users on social networks can usually search for other people by name, location, interests, or profile information like age and gender. They can often restrict these searches to their own friends or friends-of-friends. On some social networks, it's possible to search for media or groups by keyword, with an emphasis or exclusive filter on your friends.

  It's unclear what part search will play in the federated social web. Making initial connections will depend on it (Does 'Evan Prodromou' have a federated social Web profile?), but usage may drop afterwards. There's a strong parallel with the email white pages and people search services of the 90s; these largely succumbed to general-purpose Web search engines. Media and groups that are publicly published will be accessible to Google and its ilk, but searching media that's available to the user, but not to Web crawlers, may be tougher to implement.

  In any event, it seems unlikely that social web search will require much in the way of protocols. Existing ping systems created for blogs, etc., will probably suffice, with search engines using crawlers to discover and share social web data.

• Client API. Some, but definitely not all, social networks provide a Web-based API that third-party developers can use to create desktop and mobile applications that access the network. Typical functionality includes establishing relationships, browsing an activity feed, and uploading or viewing media.

  Defining a standard client API that developers can use to access any social web site would significantly help uptake. However, there's been little work in this area so far. The Twitter API has become a defacto standard, and there is some work to use AtomPub to provide similar functionality.

• Data portability. This is one of the few features that is required for a federated social web that is not often implemented on existing social networks. Unfortunately, it's also not often implemented on software that aspires to federation, like StatusNet. Some possible contenders here are FOAF for the social graph plus SIOC for events, and ActivityStreams for a stream of events that could be replayed. Data portability may be the killer app of the federated social web, and it's going to be important to get it right.

We'll be discussing these and other issues in the federated social web at the summit on Sunday. One thing that's important to note is that we don't have to totally define each and every one of these elements before implementing others. Some things we think ahead of time are very important don't actually end up being useful or valuable in practice. I think that the framework we've put together in OStatus, for example, is an excellent first approach to federated social web systems.

Tomorrow, I'm going to talk strategy. What are the next steps we'll need to take to get the federated social web off the ground? What are the possible factors that will influence its adoption? Who are the important players? StatusNet is going to play an important part, but what else?

On Sunday, July 18, 2010, StatusNet developers will be part of a federated social web summit. We'll work with other developers from other companies and Open Source projects to hammer out which technologies to use to let people on different social networks connect with each other as friends and colleagues. I'd like to take the opportunity to describe exactly what we mean by federated social web.

We're actually avoiding the term open social web. Open can mean a lot of different things. A federated social web is specific: it means that there are distinct entities that control parts of the system, but those parts are connected with agreed-upon rules to make a pleasing and usable whole.

Many Internet systems work this way. The World Wide Web is a federated document database. Documents are stored on different servers, but we get a single, clean interface through our browsers. Email is a federated messaging system; we send mail from one company to another without a second thought, because the federation is so smooth and painless (at least for end users).

The great thing about federated systems is that anyone can play. Any individual, company, or organization can own a Web site and be part of the Web. Any person or company can own and run their own email server.

Also, implementation details are hidden, and under your control. Nobody else needs to care how your email server works. Your implementation choices for how to run your email (Gmail? Company email system? Your own vanity site? ISP's email?) are vast. Prices for email are rock-bottom because there's so much competition.

There are other great things about federated systems. They're incredibly robust. They encourage technical innovation. They're more secure.

But our current social web technologies don't work like this at all. From the point of view of a typical social web site, if you don't have an account on that site, you don't exist. The only way for your friends on that site to interact with you is if they invite you to join the site. Despite the fact that there are hundreds of other social networking sites on the Web, almost every single one works as if there were zero other social networks on the Web.

As the medium becomes more prevalent in business and government, however, this model is changing. Many businesses are now running social networks for their employees; it's an efficient way to share information and connect to people inside the organization. Those workers need to connect to people outside the organization, too. Your employer won't want to host social networking for your vendors' employees or your customers; it'd be better if they had their own social network that connected with yours.

There's a temptation to view the momentum towards social web federation as marginal. Initial users of the Web, and of Internet email, would probably qualify as marginal, too. But Internet email and the World Wide Web have created immense wealth and social well-being for the people who used them vastly more than the monolithic, isolated networks that preceded them.

On the other hand, it's dangerous to believe that superior architectures will inevitably win out. Making a federated social web that is ubiquitous, fun, and useful is going to be a challenge. But I think that the building blocks are in place, or almost in place, and that we're moving from the design and implementation phase to real use on the public Web. Tomorrow I'll list out the components of a federated social web, as I see them, and give an idea of where we are with the protocols needed to support them.

Montreal, Wednesday, July 7 2010 - Technology innovator Motorola has successfully rolled out of its own StatusNet-based social messaging network, MotMot, across its entire organization. StatusNet Inc has developed a case study with Motorola to help other enterprises understand how social messaging can help their business.

"Motorola's launch of MotMot has shown the great power of using StatusNet inside of a corporation at enterprise-scale," says Evan Prodromou, CEO and founder of StatusNet.

Rami Levy, Motorola's team leader of Open Source Technologies, says in the case study, "One unexpected benefit [of using StatusNet] is a reduction in company email. We initially just wanted to increase social communication and such in the company. As the value became obvious and usage grew, we decided to leverage this to reduce corporate email volume.

Motorola also uses its MotMot system to keep its teams up-to-date with changes in product lines or projects. "A lot of people appreciate the ability to monitor, as needed, relevant channels or subject areas using StatusNet," says Levy.

The case study is available for download at http://status.net/whos-using-statusnet/motorola

For More Information

* http://status.net/
* http://status.net/whos-using-statusnet/motorola

About StatusNet Inc.

StatusNet Inc, based in Montreal, Quebec, Canada, provides the Open Source microblogging server StatusNet, popularly used on Identi.ca and thousands of other websites globally. The company provides support packages, custom development, and a hosted cloud service.

About Motorola

Motorola is known around the world for innovation in communications and is focused on advancing the way the world connects. From broadband communications infrastructure, enterprise mobility and public safety solutions to mobile and wireline digital communication devices that provide compelling experiences. Motorola is leading the next wave of innovations that enable people, enterprises and governments to be more connected and more mobile. Motorola (NYSE: MOT) had sales of US $22 billion in 2009. For more information, please visit www.motorola.com.

Press Contact

Jon Phillips
+1.510.499.0894
press@status.net
http://status.net/press

Federated Social Web Summit Logo

Status.net has organized a Federated Social Web Summit to occur on July 18th, 2010 in Portland Oregon. Before you get too excited, this is a private and invite-only event for active groups developing code specific to federation of the web. The goal of the summit is for the teams working on initiatives to discuss their current work and plan for future co-operation between each other.

Status.net CEO Evan Prodomou describes federation as just means letting people on different social networks follow each other. He goes on to say There are dozens of businesses and Open Source projects working on the problem of social network federation. We want to make sure that people are working together so a robust, heterogeneous network-of-networks can emerge.

In May I wrote about how we need an open and federated social network and I'm glad to see this event being organized. I hope these groups can work together to create a foundation for this effort to progress smoothly and quickly as we will all benefit by this in the long run.

From the Status.net post:

Invitees to the event include StatusNet, Google Buzz, Diaspora, GNU Social, DiSo, BuddyPress, Dreamwidth, Onesocialweb, and others. Were focusing only on committers: people and organizations whove put code on the table to make federation work, says Jon Phillips, StatusNet Community Director. In the future, well need to coordinate marketing and promotion of the federated social web, but this event is about making code work.

via Federated Social Web Summit 2010 Announced | StatusNet.

Hey StatusNet users, this is Derek at StatusNet reporting to you from Montreal! Happy Canada Day! StatusNet has been very busy this past week with such things as the launch of the latest version, StatusNet 0.9.3, and I am very eager to share all of these details with each and everyone of you!

Latest updates

Yesterday we released the StatusNet Desktop Client to the world. It got picked up by ReadWriteWeb and some other sources. Its all open source, multi-platform (windows, mac, linux) and you can help make it even better!

The latest version of StatusNet, StatusNet 0.9.3, has been released! Why wait when you can Upgrade now! This version includes a lot of bug fixes and translation updates. If you are interested in learning about the changes that are included in this version then you should check out Brion Vibber's most recent blog post!

Recent Mentions of StatusNet

There was an article that was published this past Sunday entitled So You Want to Take Control of Your MicroBlogging in which the author talks about how StatusNet makes your life easier by offering one account that reaches out to tones of people and services, instead of you trying to manage a whole bunch of accounts on your own.

Last week Brion Vibber (Senior Architect for StatusNet) attended USENIX and was awarded, along with other members of the MediaWiki team, the STUG award.

And finally, StatusNet's own Jon Phillips was in Brussels during the last weekend of May for Libre Graphics conference. Jon was on a panel about StatusNet and network services.

Upcoming Events

StatusNet will be attending the 6th annual Wikimedia Conference Wikimania 2010. This event will take place from July 9th to the 11th in Gdask, Poland. Brion Vibber from StatusNet will be one of the attendees.

StatusNet will also be attending the Drupal Conference 2010 held in Copenhagen from August 24th until the 27th. Among the StatusNet team members attending will be James Walker.

Also, a reminder that StatusNet is helping organize and several developers are attending the Federated Social Web Summit 2010 in Portland Oregon on July 18 pre-OSCON! To learn more about this event and StatusNet's role, check out Jon Phillips recent blog post on the event!

That's all for this week here at StatusNet! Don't forget to subscribe to Status on Status.net & Be sure to Upgrade to the latest version StatusNet 0.9.3! And, you can add community news for next week's post here on our public wiki.

StatusNet released today a cross-platform desktop client for its open-source microblogging platform - the same foundation that powers the Twitter alternative identi.ca. Windows, Mac, and Linux users can download it here. It features support for multiple StatusNet sites (including identi.ca), notifications, search and more.

Sponsor

StatusNet Desktop was built with Appcelerator Titanium framework and licensed under the Apache 2. The client's quite good, especially for a first release, but it's no TweetDeck yet (and of course, unlike TweetDeck, it connects to StatusNet sites Update: correction: TweetDeck supports StatusNet).

The Montreal based company launched an enterprise support service and a public beta for its hosted service in March. Initial enterprise customers included Motorola Corporation and Canonical Ltd. We concluded though the hosted service isn't ready to replace Yammer, the enterprise offering is a strong contender. ReadWriteWeb is considering StatusNet for own status update/microblogging needs.

Socialcast, Socialtext Signals, Obayoo and blogtronixMicro are other competitors in the enterprise microblogging market.

Montreal, Wed, 30 June 2010 - StatusNet Inc. announced the launch of its Open Source multi-platform client StatusNet Desktop today. The new software runs on Linux, Mac OS X, and Windows (2000/XP/Vista/Win7) and can connect to any StatusNet social messaging server.

"StatusNet Desktop gives our users a default, Web-standards-compliant desktop client," says StatusNet Inc. founder and CEO, Evan Prodromou. "Our enterprise and community customers want an easy way to stay connected from their desktop. They can count on the StatusNet name for a no-hassles, high-quality desktop social-messaging experience."

With StatusNet Desktop, anyone can connect to multiple StatusNet sites, including secure and private installations. It is simple to post new notices and replies, and view public, user, friends, replies, tag and group timelines. StatusNet Desktop lets you directly manage your user and group subscriptions, manage your inbox of direct messages, search for notices across all timelines and have an auto-refreshed timeline with new status updates.

StatusNet Desktop is built using Appcelerator Titanium that allows for more rapid development across platforms. StatusNet Client is licensed under the Apache 2 license with the code in a public place. Anyone may download, modify and help make StatusNet Desktop better.

For More Information

• http://status.net/desktop
• http://status.net/

About StatusNet Inc.

StatusNet Inc, based in Montreal, Quebec, Canada, provides the Open Source microblogging server StatusNet, popularly used on Identi.ca and thousands of other websites globally. The company provides support packages, custom development, and a hosted cloud service.

Press Contact

Jon Phillips, Community Director
San Francisco, +1.510.499.0894
press@status.net
http://status.net/press

Attachments

• Press Release PDF
• Press Release ODT

It's that time again -- we've packaged together the latest bug fixes and minor feature enhancements, and are pushing out StatusNet 0.9.3 (codename: "Half a World Away"). The software is available for download immediately. For best compatibility with client software and site federation, and a lot of bug fixes, it is highly recommended that all public sites upgrade to the new version.

Notable changes this version:

• Enhanced API output to aid StatusNet-specific clients
• Many updates to user interface translation from translatewiki.net
• OStatus now works subscribing to SSL-protected sites by default
• OpenID now works on PHP 5.3, supports closer site integration.
• Numerous API and FOAF output fixes.
• Fixes to Facebook integration for FB API behavior changes
• PostgreSQL support updates
• Initial version of a custom theme uploader (disabled by default)
• LDAP auth plugins cleanup
• Many other bugfixes

A full changelog is available at http://status.net/wiki/StatusNet_0.9.3.

StatusNet Inc. and other social software developers will hold a one-day summit, the Federated Social Web Summit 2010, on July 18th, 2010 in Portland, OR, to coordinate the development of the federated social web. Participants in the invite-only meeting will discuss their current work on connecting social networks and plan future cooperation.

"Federation just means letting people on different social networks follow each other," says Evan Prodromou, CEO of StatusNet Inc. "There are dozens of businesses and Open Source projects working on the problem of social network federation. We want to make sure that people are working together so a robust, heterogeneous network-of-networks can emerge."

Social networking sites are very popular, but few of them allow cross-site relationships between users. Concerns about privacy issues, and growth of social networking software inside the enterprise, have focused attention on the issue of federation.

Invitees to the event include StatusNet, Google Buzz, Diaspora, GNU Social, DiSo, BuddyPress, Dreamwidth, Onesocialweb, and others. "We're focusing only on committers: people and organizations who've put code on the table to make federation work," says Jon Phillips, StatusNet Community Director. "In the future, we'll need to coordinate marketing and promotion of the federated social web, but this event is about making code work."

"The participants in this event have been developing federation tools for a while," says Prodromou. "We hope that the improved interoperability that will come out of this meeting will let early adopters and social web thought leaders begin using the tools. This is the point where we breathe life into a federated social web."

Shared by robdiana
I could swear tweetdeck had identi.ca support at one time.

First off, thank you for making Twitter the amazing tool it is. Without you Twitter would have never caught on the way it has. I hope Twitter has stopped to thank you.

I have a few requests I REALLY, REALLY want and I think it would be relatively easy for you guys to do (says the non-programmer).

Yammer

Seriously you've added Foursquare but not Yammer? It seems like such a no brainer. Who checks in to Foursquare from TweetDeck? I'm really glad you added Foursquare just so I can filter is out but Yammer seems like it would be so much more useful.

Please, please, please add Yammer. It would really help out at work.

Your Own Hosted Microblogging Channel

Aren't all of these Twitter outages super annoying? It's got to be really frustrating as a Twitter Client to be dependent on a product that stops working at the most crucial times. I have a great idea and you don't have to look far to figure out how to do it. There's this company you are probably familiar with called StockTwits. I know you know who they are because Betaworks is an investor in both your companies and they used you guys as a model for their Twitter Client.

What's really cool about StockTwits is that they have their own microblogging functionality built on top of Twitter. So you can choose to post only to StockTwits or when the USA soccer team scores a goal their community can keep on chatting without Twitter.

StatusNet and/or Identi.ca

You could probably even use StatusNet to create your own microblogging channel. While you're at it adding Identi.ca support would be awesome. In fact you could probably just do Identi.ca and not StatusNet but I think you'd get a lot of value out of having your own branded community built in to TweetDeck. This wouldn't compete Twitter or anything. At least not anymore than them buying Tweetie competed with you

Thanks Again

That's it really. I sometimes wish TweetDeck had tabs so I didn't have to keep scrolling left and right (I have a lot of columns) but that may just be me.

I've tried every client out there and I keep coming back to TweetDeck. Keep up the great work.

Photo credit by tveskovSimilar Posts:

• What Twitter as email would look like.

# of Comments 4

• An Open Letter to Web Startups: Please Take My Money

# of Comments 10

• The Life and Death of Darcy Validate by Twitter

# of Comments 4

• What Twitter as email would look like.
• An Open Letter to Web Startups: Please Take My Money
• The Life and Death of Darcy Validate by Twitter

Is history repeating itself with Google Buzz? I hope not. I became a fan of a service called Jaiku about two years ago and wrote about how it was so much better than Twitter from a feature perspective. It was designed for meaningful conversations, unlike Twitter which wasn't (and still isn't) really designed for conversations. Jaiku even did location long before Foursquare, Gowalla and other services were doing much at all. In many ways, Jaiku even did a couple things FriendFeed is known for before FriendFeed did it. Alas none of this forward thinking on the Jaiku team's part made the service the preferred service and it pretty much chugged along until Google bought it and integrated its people into its own projects.

I remember having spirited conversations with a couple people about their perception that Twitter was superior to Jaiku at the time because everyone was on Twitter. This, more than anything, seems to be the key to Twitter's success despite repeated instability and service failures. There is no other explanation really. There are other services which do similar work and are more stable and yet Twitter seems to remain the preferred service of its kind. What I find really interesting is that despite Twitter being preferred because of its simplicity (140 character messages combined with @-replies and direct messages as the only real complexity), Twitter has become more and more complex over the last few years with the addition of lists (something FriendFeed did far better), something resembling a search engine, meta data and, more recently, location awareness for tweets. Users have carried on merrily, celebrating Twitter's new features, forgetting that they once objected strongly to anything that messed with the original, simple formula. It reminds me of the hype over Apple's innovations in the iPhone despite the fact that other devices have had those innovations for years. You would think that the Twitter team would have spent all these years since its launch and triumph over Jaiku, StatusNet (previously known as Laconica) and FriendFeed, it would have developed Twitter into a more robust and stable service. Sadly not. The last day or so has seen the biggest Twitter #failwhale in a long time with failed updates crashing the service almost completely.

Granted a couple hours without Twitter are hardly the end of the world (well, it is to some), but I find myself asking again and again why Twitter remains so popular or even relevant with its lagging feature development? I once said that FriendFeed was a far superior option and it probably would still be if Facebook hadn't bought it and effectively ended its development as a distinct service. I see Google's Buzz as FriendFeed's successor of sorts and I've written about why I think people, you, should be spending more time on Google Buzz recently. I am not alone in this belief. Matt Cutts (a Google employee for sure but I believe he is balanced in his views) and Robert Scoble have once again written about why Buzz deserves much more attention from users (Scoble hinted that upcoming features could well bring Buzz that much closer to FriendFeed parity or even help it surpass FriendFeed).

There are pros and cons when it comes to Buzz (Scoble lists a number of each in his post) but the big question is whether Buzz will suffer from the Jaiku Effect and simply not catch on despite its arguable superiority to Twitter? Buzz is a flexible and powerful service that dispenses with many of Twitter's limitations (the character limit, for one) and introduces a degree of interaction that is simply not possible with Twitter. I can even see Buzz as a possible Facebook alternative in some respects although I think Facebook has far too much momentum at this stage to be at risk from Buzz. Buzz also feels like a pretty young service and Cutts made a good point in his post which I agree with and which hopefully bodes well for Buzz:

I'll repeat what I said last week. Do you remember when you first started on Twitter, and you didn't know quite what to do with it? Who do I follow? What do I say? I didn't really get Twitter for months. But as I found interesting people to follow and got the hang of it, I began to see the appeal of Twitter and started using it more often. I've noticed Buzz is tracing that same trajectory for me: an initial burst, followed by a bit of a slump, and then a steady climb as I found people that make Buzz interesting.

That said, I was sure that FriendFeed would attract a substantial following and trump Twitter. Maybe it would have had Facebook not bought and scuttled it. Perhaps all it needed was some more time and exposure to more users and perhaps that is all Buzz needs to reach critical mass. I certainly hope so. I'd like to think that services attract the most followers because they are superior services but the trend seems to be that services attract more followers because that is where the herd has migrated, regardless of the availability of even better feeding grounds and water elsewhere. Buzz has surpassed Twitter to a large extent, just in terms of functionality, and if Google can turn the tables on its past failures to develop compelling social services, Buzz should become the next Facebook, never-mind a Twitter successor. In the meantime, you are welcome to join me on Buzz and follow me through my Google profile. Come on, it will be fun, stimulating and may even do the dishes too!

Related posts:

1. You should be spending more time on Google Buzz
2. Facebook friends FriendFeed
3. Microblog upgrades

We've had some great posts from our Google Summer of Code students - like this one last week from Ruturaj Dhekane! Here is another guest post - this time from Ian McEwen - who has been busy working on a "social music server", see here:

"Hello people of the Internet! I'm Ian McEwen (StatusNet profile), a second-year student in Computer Science (well, mostly) at Hampshire College in Amherst, Massachusetts. As @rejon's intro no doubt told you, I'm being mentored by Evan Prodromou (I can never spell that name), StatusNet Inc.'s fearless leader. I'm implementing what I initially called "libre.fm lite" (somewhat tongue-in-cheek) -- a social music server (a la last.fm), as a plugin. I've taken to calling it statusnet-music, lately. Better name suggestions welcome!

There's a whole bunch of exciting stuff that can be done with this, of course, but the first steps will be the less-than-romantic basic necessities: implement last.fm's scrobbling API, and figure out how to store and display that data. Once I've done that (during the summer or afterwards), I look forward to the various continuations of this project - awesome MusicBrainz integration, statistics, better integration with the social aspects of StatusNet, recommendations, and so forth.

In any case, I look forward to working with the excellent StatusNet team and community! I'll be hosting the project on gitorious under the project name statusnet-music and running a development instance on my own server; the 'official' plugin site as well as a work area will be found on the StatusNet wiki (unless I get inspired and make a separate site sometime, of course)."

Thanks Ian! Keep up the good work! We look forward to hearing more from our students and sharing the great work they are all doing as part of the Google Summer of Code Program!

Shared by louisgray
Salmon will be a big add for Google Buzz and other networks. Can't wait for this to come out. Looks like John also has been contributing to PubSubhubbub.

I'll be speaking at Make Web Not War 2010 today. MWNW is a conference about cross-platform use of Free and Open Source Software developed primarily for the LAMP platform on Windows-based Web servers.

We've been working hard to make StatusNet work well on Windows servers. If we can engage developers and sysadmins who are used to Microsoft platforms, we can expand the market for our commercial products, and grow the community for our project.

Our initial version of StatusNet installer for Windows has been submitted to the Windows Web App Gallery and should be available for download there soon.

We intend to improve StatusNet's integration with the Windows platform, including support for Microsoft SQL Server, Wincache, and integration with Sharepoint 2010.

Journalist Nathan Willis published an article on how to use Status.Net to keep informed about how your server is functioning. This is useful for local servers and for enterprise users managing hundreds to a thousands of servers. Willis states:

There are several different ways you can make use of a microblogging service to keep an eye on your server (or, for that matter, desktop machine), depending on what kinds of message you want to receive. You can tail log files and repeat the output in a feed, run a periodic cron job to collect statistics and send out the results as a form of "heartbeat monitor," or have batch processes send notifications when they complete. You can even configure existing open source monitoring services to use the service directly, or through email- or SMS-gateways.

Willis also notes that its wise to use Status.Net for private instances because you "also do not have to worry about a private StatusNet instance going down suddenly if Ashton Kutcher gets arrested, and in practice the public services like Identi.ca have not suffered from the "fail whale" outages that plague Twitter on a regular basis."

What is cool about this article are the code examples. Willis shows how easy it is to do some automated messaging. This provides a jump-off for others to script out other solutions. If you have a script, please do share with all on your Status.Net accounts, our wiki (http://status.net/wiki) or via the comments on this blog post.

I was happy to see that the new version of TweetDeck supports alternate API endpoints. That means that StatusNet users can use TweetDeck as their primary desktop system, or use TweetDeck as part of a multi-service approach.

To set up TweetDeck with StatusNet, follow these simple steps:

1. Download and install the latest (0.34.1 or later) version of TweetDeck for Desktop.
2. If this is your first install, you'll be asked to set up a new account. Choose the "Twitter" type. If you already have TweetDeck, you can add a new account.
   
3. Choose "Add New Account" and then use the Twitter account type.
   
4. In the account details, enter your username and password. Click the "Advanced Options" link, and add the API root of your StatusNet site to the text page. The API root is usually at "/api/" on your server, either with or without an https://. So, try "https://identi.ca/api/" or "http://example.com/statusnet/index.php/api/". You can check to see if you've got it right by clicking the "Verify Details" link.
   
5. You can add StatusNet columns like replies, all your friends, etc. just like with Twitter. There you go!

I've started using it as my primary desktop StatusNet client; it's working well.

Its all go here at TweetDeck HQ. We're working on new clients, hiring new staff and striking new deals every day. This hard work will result in some seriously exciting announcements over the coming weeks that we hope will blow your socks off.

Something enormous.

Something that shoots lasers from its eyes.

OK, not the bit about the lasers.

But it really is huge, and today we're pressing the big red button onboard the USS Calico to summon "Deckzilla", AKA TweetDeck for Desktop v0.34

Permalink | Leave a comment

Popular cross-platform social app TweetDeck is announcing an update to its desktop client this morning which will add Foursquare and Google Buzz to its arsenal of supported streams which already includes Twitter, LinkedIn, MySpace and Facebook. In addition, the version 0.34 update will allow for the addition of any Twitter-compatible APIs, including WordPress, StatusNet and Tumblr, as well as a slew of other features such as global filters and scheduled posts. The company will also announce financial news this morning, confirming that it has raised an undisclosed amount of Series B funding.

Sponsor

TweetDeck, which was invited to test the Google Buzz API announced Wednesday, is wasting no time in integrating the service into its desktop client. Users will be able to send updates to Buzz, as well as view, like and comment on their friends' posts directly from a stand-alone Buzz column in the app. TweetDeck maintains most of the Buzz experience within its column system, letting users collapse and expand comments for a streamlined experience.

The app has also added support for location, including geotagged Tweets, Buzz entries and Foursquare updates. By adding their Foursquare account to a column within TweetDeck, users will be able to view their friends' location-based updates, as well as visualize their locations with an embedded Google Map within the column. Additionally, Twitter-compatible APIs may also be added, allowing the client to interact with services like Tumblr, WordPress and StatusNet.

Rich media will also be given a front-row seat in the latest release, as uploading and recording videos to 12seconds or TwitVid is integrated into the client. Updates can also be scheduled for a later date and time, and global filters will let users automatically remove feed entries across all columns based on any terms. This latest release will also provide users with the ability to incorporate their own custom URL shortening service.

After a quick test of a pre-release of the latest version of the app, I found that the Buzz and Foursquare integration worked smoothly. When trying to add a Twitter-compatible API, WordPress failed to sync up but Tumblr was successful. I was able to publish text entries on Tumblr, but adding photos or videos did not seem to transfer the way I had hoped they would.

With this update TweetDeck is taking enormous steps toward becoming a complete social dashboard - at least on the desktop. To be honest, I had largely given up on the app because of the sluggish feel of Adobe Air applications, but the integration of Foursquare, Buzz and other services may just draw me back to it. The securing of additional funding means we can expect only bigger and better things from the company in the near future.

Popular cross-platform social app TweetDeck is announcing an update to its desktop client this morning which will add Foursquare and Google Buzz to its arsenal of supported streams which already includes Twitter, LinkedIn, MySpace and Facebook. In addition, the version 0.34 update will allow for the addition of any Twitter-compatible APIs, including WordPress, StatusNet and Tumblr, as well as a slew of other features such as global filters and scheduled posts. The company will also announce financial news this morning, confirming that it has raised an undisclosed amount of Series B funding.

Sponsor

TweetDeck, which was invited to test the Google Buzz API announced Wednesday, is wasting no time in integrating the service into its desktop client. Users will be able to send updates to Buzz, as well as view, like and comment on their friends' posts directly from a stand-alone Buzz column in the app. TweetDeck maintains most of the Buzz experience within its column system, letting users collapse and expand comments for a streamlined experience.

The app has also added support for location, including geotagged Tweets, Buzz entries and Foursquare updates. By adding their Foursquare account to a column within TweetDeck, users will be able to view their friends' location-based updates, as well as visualize their locations with an embedded Google Map within the column. Additionally, Twitter-compatible APIs may also be added, allowing the client to interact with services like Tumblr, WordPress and StatusNet.

Rich media will also be given a front-row seat in the latest release, as uploading and recording videos to 12seconds or TwitVid is integrated into the client. Updates can also be scheduled for a later date and time, and global filters will let users automatically remove feed entries across all columns based on any terms. This latest release will also provide users with the ability to incorporate their own custom URL shortening service.

After a quick test of a pre-release of the latest version of the app, I found that the Buzz and Foursquare integration worked smoothly. When trying to add a Twitter-compatible API, WordPress failed to sync up but Tumblr was successful. I was able to publish text entries on Tumblr, but adding photos or videos did not seem to transfer the way I had hoped they would.

With this update TweetDeck is taking enormous steps toward becoming a complete social dashboard - at least on the desktop. To be honest, I had largely given up on the app because of the sluggish feel of Adobe Air applications, but the integration of Foursquare, Buzz and other services may just draw me back to it. The securing of additional funding means we can expect only bigger and better things from the company in the near future.

Whenever an internet company elects to build its own database, web server or language framework (coverage), the inevitable result is a discussion of the relative merits of the new technologies versus those not chosen. The canonical example here are the endless comparisons of NoSQL infrastructure to the more traditional relational database approach (coverage). However interesting such conversations might be, they're obscuring the longer term implications of a fundamental shift in the way that software is produced, and why.

Historically, businesses web and otherwise have used a variety of mechanisms to protect their assets, to preserve their competitive advantage. In the software world, we've seen copyright, licensing, non-disclosure agreements, patents, trademarks, and a host of other legal tools employed. If you've been in the industry for any length of time, chances are you've been on one end or the other of one or all of the above at some point.

In the past ten or fifteen years or so, however, we've seen software firms increasingly ask a simple but profound question: what are the assets I must protect? Twenty or more years ago, the answer was simple: protect everything. Ten years ago, as open source was on the way to becoming a mainstream software development practice and companies built upon the resulting projects grew exponentially in size, the reply was more nuanced. A lot of software needed to be protected, but there were substantial chunks that could be shared. Today, firms appear to be asking a different question: is my value in data, or source code? And if the answer is data, what should my software development practices look like?

Facebook and Twitter, as high profile properties that grew up without the legacy protectionist mindset, might be illustrative here.

If we examine developers.facebook.com/opensource/, for example, there are several very obvious trends.

• Facebook has a strong preference for permissive licensing. Wherever possible, Facebook avoids copyleft licensing in favor of more liberal alternatives. The default licensing choice, in fact, appears to be Apache 2.0 (e.g. Cassandra, Scribe, Tornado and Thrift), with other licenses employed tactically for compliance or compatability reasons (e.g. GPL and Flashcache or PHP and Hip-Hop).
• Between their contributions to previously existing projects (e.g. Hadoop, Cfengine, memcached, MySQL, and PHP) and releases of software they built (e.g. Cassandra, Hip-Hop, Hive, Scribe, Tornado, Thrift) the core of Facebook's infrastructure is built on non-differentiating, publicly available code.
• Language usage at Facebook is fairly heterogeneous, with both dynamic languages (e.g. Javascript, PHP, Python) represented as well as traditional alternatives (e.g. C, C++, Java). Perhaps because of Facebook's emphasis on performance, however, the latter is significantly more common than the former.
• Facebook hosts very few of their own assets; Tornado appears to be the notable exception (possibly bc it came from FriendFeed). Some assets are hosted with Github (coverage), those that are not are typically housed at Apache.

As for Twitter's twitter.com/about/opensource:

• Twitter, like Facebook, has an affinity for permissive licenses in general and the Apache license specifically. Twurl, a Twitter-specific flavor of Curl, is MIT licensed, but FlockDB, Gizzard, Murder and even its GC trace script jvm-gc-stats are Apache 2.0 licensed.
• By all accounts, Twitter is run off of an infrastructure similarly undifferentiated. Its primary data storage, for example, has been MySQL based with a parallel implementation of Cassandra (which Twitter contributes to). Their social features are likewise enabled via a graph database, FlockDB, whose source is available.
• Languages at Twitter are similarly heterogeneous, though Twitter appears to rely more heavily on dynamic languages than does Facebook (Murder is 97% Python / 3% Ruby, for example) resorting to Scala when performance is at a premium (FlockDB is 83% Scala, Gizzard 100%).
• Effectively zero of Twitter's released open source projects are self-hosted; Twitter has insteaded outsourced this task to Github. There does not appear to be any predisposition to existing open source foundations, Apache or otherwise.

Though Facebook and Twitter clearly have some differentiation in their operational priorities and philosophies, then, the similarities far outweigh the differences. Following on the heels of Amazon, Google, Yahoo and the other early web firms, Facebook, Twitter et al are pushing the envelope even further: Google publishes their algorithms (e.g. MapReduce), Facebook their software (e.g. Cassandra).

If they are at all representative of the direction of application development in web native firms, then, we might reasonably expect the following:

• Default to Open Source:
  Rather than ask whether a given asset should be open source, firms are likely to increasingly try to identify which pieces should not be. We don't see many businesses running off of an entirely open source foundation, but the differentiation points are typically further up the stack. In practical terms, then, this means that it will be difficult to differentiate, competitively, on infrastructure software. And if there is no competitive advantage in your infrastructure, the benefits to using or releasing open source software whether those are better resource availability or the ability to amortize development costs are likely to outweigh the marginal benefit of developing it strictly in house.
• Language Heterogeneity:
  Traditional development best practices which typically annoint a language or set of languages as the permitted options will likely become workload specific. Performance or scale sensitive applications, for example, would be restricted to a set of predetermined language options (e.g. C/C++ at Facebook, Scala at Twitter, etc). Glue languages, however, are likely to be far less homogenous, and reflective of different influencers (e.g. developer preferences, available bindings/libraries, etc).
• No Core Competencies in Project Hosting:
  Few if any web firms are attempting to specialize in project hosting. This task is increasingly being left to specialized hosts (e.g. Github) or governance oriented foundations (e.g. Apache). This is preferable from a developer standpoint, because centralized project hosting simplifies discovery/cross-pollination and enables network effects such as social, collaborative development. Source code control is increasingly likely to be distributed by default, as well.
• Permissive Licensing Standard:
  Much has been made in some quarters over the decline of the GPL. While the decline is unquestionably overstated (coverage) considering that the license is more popular than the next ten licenses combined, my expectation entering 2010 was that permissive licensing would continue to grow at the expense of reciprocal licensing (coverage). The behavior of web firms generally validates this assertion.
• Precise Identification of Value:
  It would be absurd to argue that the value of a Twitter was in no part related to the software that powers it. But it would be equally foolish to suggest, when we have open source Twitter clones such as StatusNet freely available, that the value was all, or even mostly, in the software. The value of a Facebook or a Twitter is ultimately in the data they generate, not the code. In a very real sense, its users are its asset. When application development is considered, then, it will be considered with this in mind. If code isn't ultimately your differentiating asset, then the dynamics of development are irrevocably altered.

Many of you are doubtless curious as to how relevant the application development experiences of unique, web native businesses such as Facebook and Twitter are to traditional enterprise customers. The answer depends largely on timeframe. In the short term, the impact will be minimal both because enterprises move slowly and because their attention to web firms is fairly minimal. In the longer term, however, the web firms have the ability to substantially influence developer best practices, product direction and so on. Witness the mainstream popularity within enterprises today of dynamic languages, once popularized by web firms, or the accelerating adoption of projects such as Hadoop.

We will not see within the foreseeable future a world in which all software is open source, nor one in which there is no differentiation to be found in development. It is likely, however, that as our understanding and appreciation of what, precisely, is differentiating improves, our software development practices will evolve along with it. Where better to look, then, to understand where things are going than to firms that have grown up without preconceived notions of what must be protected at all costs?

This is a new series of posts that are written by our Google Summer of Code 2010 Students. First up is Luke Fitzgerald being mentored by the super-great Craig Andrews.

Hi, I'm Luke Fitzgerald (http://identi.ca/darkip) and this summer I'll be developing Windows Messenger and IRC chat interface plugins for StatusNet. Quickly about myself; I'm a 20 year old Computer science 2nd year undergraduate at the University of Bristol in the UK. Despite only recently discovering StatusNet, I've quickly become passionate about it and can't wait to bring some new features to this fantastic platform.

The new plugins will be designed to accept the same commands as are used by the existing XMPP plugin to allow for easy use by those already familiar with the commands. In addition to implementing the plugins, if left with enough time, I will be extending the IRC plugin to allow the bot to sit in channels and answer general queries from any user. Offered will not only be existing queries which are not specific to the user
querying, but also new additional ones which will be implemented specifically for this feature. My final extra aim is to move configuration of IM plugins from configuration files to the Admin Panel.

So, what's my plan of attack? The Windows Messenger bot will be written using phpmsnclass (http://code.google.com/p/phpmsnclass/) and once the bot is built, I'll be writing a wrapper which will allow the bot to integrate with StatusNet's existing IM architecture. The implementation of the IRC plugin will have a similar approach; write an IRC bot and then a wrapper to allow the bot to integrate with the IM architecture.

The bot will be based upon the actively developed Phergie IRC bot (http://phergie.org/). Upon completion of my two main tasks I will work on extending the IRC bot to handle general queries from IRC channels in addition to private messages. If this is also successful, I will finish up by working on moving the configuration of the IM plugins to the Admin Panel.

You can actively track Luke's progress on our public Gitorious account and hack on other Summer of Code tasks. Anyone who completes a challenge, contact me and we'll get you something cool in addition some praise up here :)

Matt Mullenweg of Automattic (the WordPress folks) had some dim judgements on the future of the Twitter API outside of Twitter. I wanted to take the opportunity to give a quick update on the future of the Twitter API at StatusNet. What we're doing, and how it's going forward.

1. We're going to continue to support our Twitter-compatible API for the foreseeable future. We've seen a lot of value in it, and our third-party support has definitely benefited.
2. We'll continue to augment it with StatusNet-specific data as we see necessary, obviously trying to avoid any collisions with future Twitter development. We've already added versioning and per-site configuration data, and future versions will include formatted HTML and full links to remote sites and users.
3. We encourage third-party developers to consider supporting the tens of thousands of public and private StatusNet sites on the Web. See StatusNet for Twitter Developers for a good overview.
4. The rest of our software is coalescing around Atom. We use ActivityStreams for OStatus, for example. We plan to roll out support for the Atom Publication Protocol in the next version of our software.
5. We're also building our own StatusNet-focused clients. They currently use the Atom side of the Twitter API, and we're going to build more Atom in to future versions.

I generally agree with Matt that we're seeing a big sea-change in desktop and mobile social messaging clients and that the window is closing for third-party developers to branch out. I think supporting other platforms is a great way for Twitter client devs to parlay their current control of 75% of Twitter's traffic into an ongoing business.

You've seen Twitter, Google, and Facebook's moves into the land of microblogging and status messages. These are the atoms that make up the new streaming systems that bring us our friends, news, and more. But these systems are not open and that makes us feel like we are in the AOL age of the Internet waiting for the Web age to show up. Well, StatusNet Inc has an answer: status.net, which is an open microblogging/status and social networking system that you can run on your own servers in a decentralized way. This has the potential to make status messages closer to email or websites, which no one or three companies control. Who likes this approach? Well, brands, who want to stop gifting their traffic to Twitter or Facebook, both of which are places that are hard to monetize on and control your image. In this conversation with StatusNet's founder and CEO, Evan Prodromou, we talk about a range of topics in the social networking and status streaming space.

More info at:
StatusNet's website: http://status.net
StatusNet's Blog: http://status.net/blog
StatusNet's CrunchBase Profile: http://www.crunchbase.com/company/statusnet