Arrington laughed at me, just like he had laughed at me in the conference green room when I showed people photos on my phone of the chickens I was raising in my backyard. Just as I was vindicated when the TV show Portlandia later demonstrated that it is perfectly reasonable to raise chickens here in my home town, so too do I feel a little vindicated by the reported acquisition in the works of Rapportive by social network LinkedIn. OK, so both are a little silly. But the point is: Rapportive is awesome and I was right.

It wasn't a big acquisition (TechCrunch was told around $15m) but it was a validation of some big ideas.

Rapportive is a simple thing, and yet it's founded on some complex and potent technology trends. Trends like: identity as platform, harvesting of social network user data and APIs for cross-site functionality. On top of profile data and email adresses, you can build awesome tools.

Rapportive is magical; it's one of the first things I show people when I am excited to show them something about the internet. Many people immediately see the value of it. When we first wrote about it here, we titled our post Stop What You Are Doing Right Now and Install This Browser Plug-in. No one objected, it was clearly awesome. (The line Stop What You Are Doing is something best reserved for when you can really back it up.)

Since that time, Rapportive has served as one of the most compelling elements in the still-unfullfilling ecosystem of CRM applications floating around the internet. None solve all your problems, most are hard to make the time to come back to. Not Rapportive, though. Not if you're a Gmail user, anyway. It delivers relationship management value in almost every email you send and recieve.

Much of that value comes from the integration of 3rd party services. There's a whole list of apps built on Rapportive. They sit in your email, look at who you're corresponding with and then let you interact with that person or their content on other social networks. Twitter and LinkedIn have been the best in my experience, but enterprise Rapportive users may have prefered other apps on the platform.

Woe, woe to LinkedIn if they screw with this. If LinkedIn is to Rapportive as Twitter has been to Tweetdeck then I am going to be one unhappy user. If LinkedIn treats Rapportive as well as it has treated CardMunch (which is a miracle app) then we're in good shape.

LinkedIn may serve up less data in Rapportive simply because this is probably the end of Rapportive's relationship with the super-controversial social data mining service Rapleaf. Update: Rapportive contacted me to say they haven't been using Rapleaf for more than a year now. Noted! Many people hate Rapleaf, but they love the Rapportive interface that serves up some of that information. Fortunately Rapportive does not surface some of the information Rapleaf makes available, like home and car ownership and family status.

Rapportive was the best example of what could be done with aggregated user data though! All too often, when you ask someone about aggregated social network user data they immediately say "I'm opposed to it!"

As a platform for the creation of products, services, new ways to relate to the people and the web arround us though - Rapportive is a beautiful example of what the future of the web could be. It's not about apps like Path sucking your phone's contact info into its servers without telling you; it's not about services like Pinterest surreptitiously changing your shared URLs to capture affiliate revenue.

No, the future of user data as a platform, in its best form, is to show you the faces of the people you're meeting by email. It's about helping you connect with them. Hey, you might say, I see you sent me an email. I haven't had a chance to reply yet, but you'll notice that I just started following you on Twitter. (A person can also guess another person's email by guessing at variations of their name @ their company domain.com.)

I sure hope Rapportive can grow and thrive in its new home. And I hope that it will inspire whole new worlds of startups building

An era has ended for the first API that really made mashups mainstream, most famously via housingmaps.com, a mashup of Craigslist rental search results and Google Maps. Unlimited access may no longer be available for free, but some observers say it's a good move for the developer ecosystem. "For some developers this can clearly be an issue but overall it's healthy for the ecosystem," John Musser of API watch-dog site Programmable Web told us tonight. "Services need to be sustainable with business models that work for both sides."

The free vs commercial nature of Google APIs and the Maps API in particular have always been a little unclear.

"Given the value these APIs give and the cost of running them," says independent Australian developer Daniel Treadwell in words echoed by many people, "I think charging for it isn't a problem at all. The last thing anyone wants is for it to be retired like some others have been."

This Spring, there was a massacre of free Google APIs that got slated for shut down so the company could focus on other priorities. Weeks later, Google changed its mind about its Translate API in particular, announcing it would develop a paid version that developers dependent on it could rely on.

It's extremely unlikely that the Maps API would ever disappear altogether, but even if it did there are already viable alternatives including Open Street Map and MapQuest. Other up-and-coming options include DevelopmentSeed and TileMill.

So far, though, many developers appear satisfied with the way Google is handling this transition tonight. (Except some dissenters on my Google Plus thread, which is great to see. Keep it up, dissenters!) That's good for the future of location-based application development and innovation. Google Maps is a living, breathing, changing, incredibly valuable resource. If you wrote an app that has got enough traction that you're cranking on that API past a certain limit, paying something for it certainly seems fair.

Paul Rademacher, the creator of HousingMaps.com, had this to say in response to the announcement:

My concern would be that individual and small-team developers (who have fueled the geo explosion) not be scared away by this change. 25,000 maps per day is actually quite high, and should cover the long tail of API sites. It takes a lot of press or very healthy sustained traffic to reach that number. One main question developers will have is "what happens if my site suddenly hits the front page of X and gets huge traffic?" That should be ok according to the Maps API FAQ, so long as it's a short-term spike. I expect the vast majority of sites won't be affected at all by the new usage limit, some very small number of very large sites will be affected, and for those in between: talk to Google API Premier team and figure something out. To the small geo developers: please keep coding!!

Skype-powered apps have always been a source of huge unrealized potential. People say that your telephone contact list represents your real social network and the ultimate social graph to build apps on top of, but people do a whole lot of calling on Skype these days too. Add in video calling, screen sharing, text chat, file transfer and the P2P protocol it all runs on top of and what have you got? An awe inspiring opportunity. "Imagine the possibilities of Skype Video Calling directly in one or more of the desktop applications you use each and every day," the company says, "be it office productivity software or games."

Here at ReadWriteWeb, we use the Skype API for inbound and outbound messaging. We haven't used any video chat APIs to date, though options like TokBox and recently the Google Hangouts API have made that seem easier than ever. We are bloggers, though, so pantslessness is an occupational hazard and other forms of communication tend to be more viable on a day-to-day basis.

The app directory is almost entirely filled with call and chat recording apps, which are great, but Skype has so much more potential than that.

Unfortunately, signal quality is not always great on Skype. Cross-platform support is uneven: frustrating for Mac users and maddening for Linux users. Skype's mobile offerings sometimes feel out of their weight class, too, when up against a big stream of data they are asked to transmit. Many developers have fallen deeply in love with Twilio's API already, too.

"[Chris Andrews, Senior Business Development Manager at Skype] says that potential products using the API could focus on specific Skype desktop apps for kids, or seniors," writes Leena Rao at TechCrunch this morning. "He adds that some partners who are using the Video APIs are focused on distance learning and telemedicine opportunities. For, now, there are no plans for a mobile API, he says."

Will Microsoft and Skype be able to build a thriving ecosystem of apps that let seniors practice telemedicine on kids around the world, record the video, translate the dialogue in text and voice, all while transferring files?

That would certainly be fabulous if they could.

Cross-platform mobile Web apps may be poised to become a big part of the future of the Web, but they just aren't as powerful as native apps yet. Cabana, a do-it-yourself mobile Web app creation platform first seen at the Launch conference in February, announced a big new step today that will make mobile Web apps far more feature-rich as well. It's called the Cabana Exchange, and it's an API marketplace that allows app builders to incorporate some powerful 3rd party data and functionality.

The first partners in the Cabana exchange are location platform SimpleGeo and API service Mashery (disclosure: Mashery is a ReadWriteWeb sponsor). Through Mashery, the exchange will include APIs from Klout, Qwerly, FanFeeder, Rotten Tomatoes and WhitePages.com.

Each of those is a good chunk of functionality to bring to the crowded market of DIY mobile app creation tools. That's social ranking (Klout), cross-network profile discovery (Qwerly), sports stats (FanFeeder), movie ratings (Rotten Tomatoes) and contact info look-up (WhitePages.com). On a little mobile Web app! Plus SimpleGeo location data. Impressive.

There are a number of drag and drop, DIY mobile Web app creation services and most of the others offer cross-platform native app creation too, for a fee. Cabana does not yet. Either way, the possibilities become fairly nuts when you combine Web content into a mobile app you can create in a day.

Here's a description of how I made an awesome mobile Web app with competing service Genwi. Give me a marketplace of APIs to incorporate into those apps, and that's pretty exciting. I haven't tested Cabana yet, I gotta confess, so I don't know about its performance, optimization or stability (in my experience, it's much about caching content) but this new functionality is very interesting.

Not everyone thinks this is the best way to do it, of course. Sravish Sridhar is the CEO of Kinvey, a Boston-based startup that provides mobile back-end functionality as a service in the cloud. About Cabana, Sridhar says, "Cabana places emphasis on the device connecting to various services. In essence, the device becomes the platform. It's opposite to what companies like Amazon are saying with Silk, where the cloud is the platform. Both are valid ways to do it and the market will decide."

Hopefully we'll see a big battle between startups working to make the creation of new mobile apps as easy, cheap, powerful and feature-rich as possible - whether natively or on the mobile Web.

If you look around where you find yourself in the world, physically, and are aware that there's really more to life than the naked human eye can see - the new Infochimps GeoAPI could be an important tool in shedding light on the quantifiable parts of reality previously hidden in a disconnected cloud of data.

"This is a big push for us, some big break-throughs we've been pushing for for a long time," says InfoChimps founder Philip Flip Kromer.

"You have all these data sets in knowledge domains that have been previously isolated - to be able to connect them without fine scale surgery, to just progmatically tie together disparate data sets, is something there's a lot of customer demand for. If you can just build generic data consumption tools then you don't have to be a Geo API developer, you can be any kind of developer and consume any of this data generically."

Liam Dayan, Founder & CEO of the development firm createCORE, offers an illuminating quote in the Infochimps announcement: "[Infochimps] is making it possible to put some backburner projects back on the near-term roadmap because of how much less work they'll be."

Adam DuVander goes into more detail about the specific offerings and pricing over at ProgrammableWeb.

Why This Matters

This is interesting news because it could substantially lower the barrier to entry for developers seeking to build mobile and other apps that are rich with data about places in the offline world.

Kromer says that data from competitors like Factual, SimpleGeo and Fwix could all well be served up through the Chimps' API, all at once and along with data from other sources.

Here's the big-picture metaphor for geo-data, as far as I see it: There is a fast-growing world of loose, disparate data about people and places all over the world. That data is interesting when you pick up one bundle of it at a time, but it could become far more powerful if it was gathered together: from individual shards of glass (census, commercial, historical data), into a fused-together kaleidoscope (perhaps the Infochimps geo API) and finally to an integrated lens that enables new levels of clarity on our view of the world around us, in the form of multi-source geodata-informed apps.

These are early days, but the future looks bright for tools that help build tools that help us better understand the places that we find ourselves.

Like to hack on Twitter feeds, streams and APIs? Then there's good news for you this morning. Twitter has acquired a small startup company called Bagcheck, but the real score in the deal was bringing co-founder Sam Pullara onto the team. Pullara was previously the Chief Technologist at Yahoo where he lead many of the best programs at that beleaguered but technically awesome company.

Yahoo Pipes, Yahoo Query Language, Yahoo Search BOSS and other inspiring technologies that enabled hackers all around the web to roll out sophisticated mashups powered by Yahoo's backend were championed for years by Pullara. Not everyone liked him, but people who love to experiment with data have got to be excited about his coming to Twitter, the world's most promising stream of publicly available, semi-structured, real-time social data. Twitter's relationship with developers has been troubled at times, but Pullara's joining the team is the latest step the company has taken to make amends with its developer ecosystem.

What About Bagcheck?

The company Pullara co-founded may see its technology integrated into Twitter as well. Thomas Vander Wal coined the word "folksonomy" (a user-driven system of popular classification) and is a big fan of Bagcheck.

"What Bagcheck has done that is brilliant is make it easy to add things from around the web into the Bagcheck site through their 'BagIt' bookmarklet, which captures 'social objects' and keeps them well structured.

"Twitter is good (not great) for discussion of things, but is really lacking a good view of the social object, in the 'socially mediated object' sense that Karin Knorr Cetina used - where people having clear view of the object they were discussing had much better (accurate, robust, and constructive) conversations than those discussing things in the abstract.

"Bagcheck could provide that hook into social objects to bring things within clear view. This will help with resolving things like 'Which Planet of the Apes movie are you talking about?' and other ambiguous conversations."

If Sam Pullara can advance the kind of paradigm represented by Yahoo Pipes and YQL into the Twitter ecosystem, that would drop the already low technical cost of entry and greatly increase the power available to Twitter's ecosystem of developers.

Pullara can also work on big partnerships. He lead Project Hummingbird, which was Yahoo's search partnership with Twitter, but we hear he got even further with a Yahoo/Facebook partnership. Those are powerful additions to a hacker/executive resume.

You may remember when a megahyped search startup called Cuil, with tens of millions of dollars in backing, launched then faded away a few years ago? The developer that built the same interface with better performance in four hours, using Yahoo's Build Your Own Search Service (BOSS), was Sam Pullara.

This Spring, Twitter brought on Jason Costa, former developer relations manager at both Google and Facebook, to be the new Twitter developer relations manager.

Twitter is going to need to stock up on hot developer types, because Google Plus will open an API soon and the competition for developer attention is going to be massive. That's going to be great news for developers and the users who love them.

Some people say it's too late for Twitter; that it has mistreated its developer ecosystem too much to win against any viable challenger. Time will tell, but it seems clear that Twitter isn't going to just let all the hacker attention flow to the little upstart Google Plus without putting up a fight.

Web Intents, based on an existing capability in Google's Android mobile OS, will let Web apps express a simple call for an action, like 'share' or 'edit,' which receiving apps will be designed to use, without either app needing to have specific knowledge of the APIs of the other. This way, instead of having to code for each specific Web app one might want to access, developers can just use these simple requests, which will be built into the browser. The Chrome and Firefox teams are each building this functionality for their own browser, but they're combining their proposals to use a single API for Web app developers to reach both platforms.

"If I built an image gallery application and I wanted to let users edit an image so that they can remove red-eye from a photo I either have to build an application that edits the images, or integrate with a 3rd party solution. Doing this is hard and stops you from building an awesome image gallery; and what happens if the user has a favorite service that they already use to remove red-eye? Simple, you have a frustrated user."

The goal of Web intents, says Kinlan, is "to allow developers to build applications and services that could work with each other, but not need to explicitly know about each other." The concept was inspired by Android's functionality, he says, but "the API bore no resemblance."

Android has had these same capabilities for a while, which has made life easier for mobile app developers in Google's ecosystem. With the Chrome team taking big steps to advance its browser, especially by fleshing out its Web app store, Web Intents will be a timely addition to the desktop platform.

Now that each team is working on Web Intents, some pretty interesting code examples are available to play with. Here's Mozilla's demo video of how they want the user side of the experience to work:

A 6X expansion of apps built on top of Twitter between the company's 4th and 5th birthdays is truly remarkable. It's even more remarkable because it's been widely alleged that the developer community is unhappy with Twitter's leadership and feels disinclined to invest in building more apps. Happy or not, this is a huge jump in activity and I think the claim deserves a little investigation. Many people have guessed that the numbers aren't very solid, but there are a number of explanations that if combined could add up to this big, big jump.

Twitter says that there are multiple factors that contributed. Here are the things I believe have contributed to the big, big growth of app numbers.

Website integrations account for a substantial number of what are counted as apps. Tweet buttons and Follow buttons are not included in the 1 million, though, Twitter spokesperson Jodi Olson tells me. WordPress integration of a Twitter account and its Tweets does count, though. As does the @anywhere feature that lets a site display a pop-up about any Twitter whose username is hovered over. This may be a big enough portion of the growth the 1 million number feels a little dishonest; developers critical of Twitter seem to think so and say this is just another example of the company misrepresenting itself for its own benefit.

When Twitter killed the unauthenticated version of its API, that did contribute "a one-time spike" in the number of apps the company was able to count, Olson says. That's probably a very big factor, but it indicates that there were a lot more apps in the wild than the company was aware of, too.

Another factor is that many developers are not unhappy with Twitter. The company's call that developers not build Twitter clients, its acquisition of favored startups in particular sectors, its preferential granting of access to the fire hose of content and an allegedly poor history of communication with its development ecosystem all added up to create the appearance of dissatisfaction. Many people we heard from today said they weren't unhappy, though.

Mobile app integration is on the rise. Tech analyst firm IDC performs quarterly interviews with more than 2,000 mobile app developers and found that 57.5% of mobile apps under development in Q1 included Twitter API integration. In Q2 that number jumped to 62.3%, according to Scott Ellison, IDC's VP of Mobile and Consumer Platforms. When iOS integrates Twitter and makes it easy for mobile apps to do so too - well, look out numbers.

The Salesforce acquisition of Radian6 for over $300 million probably help stir up a lot of app development as well. "Since December 2010, more than $500 million has been invested in ecosystem companies," Twitter wrote today, "and more than a billion dollars has been paid out in acquisitions."

Finally, there are a shortage of alternatives. Many people I heard from today said they didn't like building on Twitter but it's the best source of social data available. That may change when Google Plus releases an API.

All of those factors put together could very well contribute to explaining a large increase in developer interest in Twitter over the past year. Especially if you're willing to accept website integration as "an app."

Instapaper stores stripped-down copies of articles you select from the web, but offline on your device so you can read without connectivity. With the latest version of the app launched a few months ago, you can designate an article for sharing out on Twitter or Facebook once you get back online later. Today WordPress founder Matt Mullenweg asked Instapaper founder Marco Arment to enable posting to a WordPress blog from inside Instapaper. "I'll make it happen," was Arment's response. Cool!

WordPress's Mullenweg says that his team is working on API changes that will make this sort of integration even easier. That makes me wonder where else we'll see WordPress integration in the future. Blogging may not seem as hip as it used to in these days of Facebook and Twitter but (and I'm totally blogging this, right now) it's still got a unique power and place in the social web. It always will - and that unique phenomenon that is blogging will likely continue to find new places to manifest itself throughout the larger technology universe. Instapaper looks like a great one of those places to me.

It just so happens that something like that may now be under development in the most official of venues. The World Wide Web Consortium (W3C) announced today the formation of a new Web Real-Time Communications Working Group to define client-side APIs to enable Real-Time Communications in Web browsers, without the need for server-side implementation. The Group is chaired by engineers from Google and Ericsson. It sounds like Opera Unite to me (see video below), but democratized across all browsers. It sounds like it could be a very big deal.

"These APIs should enable building applications that can be run inside a browser," the new Working Group's charter says, "requiring no extra downloads or plugins, that allow communication between parties using audio, video and supplementary real-time communication, without having to use intervening servers (unless needed for firewall traversal, or for providing intermediary services)."

The working group is focused on the Application Programming Interfaces (APIs) that devices will use to implement these connections, but is working with an IETF group developing a technical protocol for transmission of the data between browsers. The first indication of this work appeared two months ago with the discovery of a mysterious flag inside Google Chromium.

The W3C's new working group on all this is chaired by Harald Alvestrand of Google and Stefan Håkansson of Ericsson. It plans on meeting regularly through February 2013 and is placing a special emphasis on ensuring users have control over and are aware of what media they might be transmitting from their browsers to others.

Developers that can sign up new subscribers to Rdio's $5 or $10 per month paid services will receive a 2% to 3% commission for the lifetime of the subscriber. That could help create a small army of sales people that could sell Rdio in settings outside of the Rdio iPhone app, where Apple will soon begin taking a hefty 30% cut.

Rdio is offering three types of APIs for the Web: one based on the much-loved open OEmbed standard, a REST API and a Web Playback API. Playback APIs for iOS and Android apps are forthcoming, the company says. In other words, the functionality and affiliate sales are focused for now on Web apps.

That makes the most sense from a financial perspective, but whether streaming music service subscriptions can be sold in large numbers through the web, instead of through in-app purchases on proprietary platforms like Apple's iOS, will be a big determinant of the viability of this low-margin new business. Rdio makes no mention of Apple in its announcement, but given the industry's intense focus on Apple's controversial new plan to take a 30% cut from subscriptions sold on its platform - it's hard not to consider an affiliate program for Web-based sales of subscriptions in light of that.

The whole subscription streaming model still seems like an open question - I like it a lot myself but will it catch on generally? It's hard to say. APIs for subscription streaming are a step even further out. It's a bold experiment but it would be great if it worked. It would be even greater if a standards-based API play ended up being what helped innovative music startups thrive despite concerns about Apple's stranglehold over mobile platforms.

Rdio's APIs are built on top of the Mashery API management platform. (Disclosure: Mashery is a long-time sponsor of ReadWriteWeb.)

Below, Rdio's new Mac desktop app, just released last week.

"The important thing is that you and your ideas live outside the silo and are ported into it at your pleasure," Winer wrote in a blog post today. "You never have to worry about getting your stuff out of the silo because it never lived in there in the first place." This is very good news. It appears that the tool will live first at My.ReallySimple.org (password protected).

Throughout the past decade of massive media disruption, the only people who have played a bigger role in democratizing publishing technology than Winer may be Mark Zuckerberg and Evan Williams. Winer's work, though, has been technical enough, embedded enough in larger technical communities, so focused on the distributed Web instead of on building up one corporate brand, and so wide-ranging that he's gained far less public recognition than other major players. His near-absolute disinterest in visual design, his chronically caustic personality and his apparently principle-driven burning of bridges haven't helped either. (Disclosure: I used to co-host a podcast with Winer and am forever indebted to him for the technologies he's fostered that have dramatically changed my life and career, but believe that I can make the critical statements above based on far more than how he and I have interacted. Our personal interactions have been just one part of my assessment of the man as a challenging genius.)

None the less, Winer has stepped into the breach of profit-driven companies failing to serve the interests of users time and time again to create platforms that have touched an incalculable number of lives.

Can he do it again? User-facing technologies have never been Winer's strength; he's been much more successful revolutionizing the world of content delivery on the back-end. Can he make distributed publishing, by publishers acting as independent entities instead of sharecroppers for platforms enriching their shareholders, a part of peoples' everyday experiences the same way he helped bring us feed reading and listening to podcasts?

Unless we've all been Farmville-zombified too deeply to care anymore, My.ReallySimple is something we all ought to be cheering for.

There's more to come, too. "This is a piece," Winer writes, "of the loosely-coupled system I envision booting up over the next months and years."

Everyblock was acquired by MSNBC in 2009 and came to my city of Portland, Oregon this Spring. Things haven't been the same since. Give me a Sunday morning and Everyblock on my iPad and I'm a happy guy.

Competitor Outside.in released the 2.0 version of its API this Summer. Fwix is another hyperlocal news aggregator with an API to check out.

Everyblock was founded by Adrian Holovaty, whom tech thinker Anil Dash calls one of "the greatest data-hacker journalists of all time, along with Gina Trapani and Andy Baio." It's exciting to see that data-hacker journalist offer an API.

Will developers go for it? Though Digg's currency appears to be dropping fast, real-time streaming data from millions (?) of social media users, concerning links to content from all around the Web, has got to hold some interest for programatic analysis, UI innovation and publishing industry analytics. The flow of data coming through the API seems a little anemic, though. We spoke with some of the Web's leading data developers who see today's announcement in very different ways.

(Disclosure: Musser's blog is now owned by Alcatel-Lucent, who is also a ReadWriteWeb sponsor.)

The Upside

Pete Warden, independent social graph analysis consultant, is optimistic for what this means to the ecosystem of mashup-friendly startups.

"Despite its recent troubles, Digg is still a massively popular tool for uncovering new stories. Offering a streaming API opens up all sorts of possibilities for mining that data, everything from spotting up-and-coming stories to offering detailed real-time analytics to content publishers. I know that startups like OneTrueFan are already salivating over what they'll be able offer."

Likewise, Tweetmeme founder Nick Halstead said today that he hopes to incorporate the new Digg streaming API into his much-anticipated new startup DataSift. "Our curation abilities on top of Digg submissions would be very powerful," he told us.

The Downside

Is Digg's community exciting enough for it to still matter, though? Jeremie Miller, inventor of the Jabber/XMPP real-time/instant messaging protocol, is not so sure.

"Honestly, my gut instinct was 'digg is struggling to be relevant.' They should have published approximate flow rates with this too; some sparkly graph eyecandy woulda been nice diggs-per-second, etc. The stream is showing a flow rate of a few per second at best - Twitter's firehose is 500-1000 per second.

"Technically, their implementation definitely trumps Twitter's... whose firehose is about as un-sexy as it gets. Digg did a better job at that for sure - but it was such a low bar already.

"The only firehose I'd be surprised by and care about at this point would be Facebook's - but I expect we'll have first contact before that happens."

What Does it Mean for Digg?

If a wide range of third party startups and innovators can make meaningful use of Digg's streaming API, that could help form a virtuous circle that makes Digg more interesting to people again. If nothing substantial comes of the API, that doesn't bode well.

Witness, for example, the case of OneRiot. OneRiot is a well-funded real-time search service that put a whole lot of eggs in the basket of its ambitious API earlier this year. It's unclear that was effective in making OneRiot really stand out, though - and now the technically admirable, world-changing startup has put its tail between its legs this month and turned entirely into an advertising network.

Something like that may very well happen to Digg. Or, a streaming API could help make Digg hip and fun again.

What do you think, readers?

The company announced the availability of 20 different network-level Application Programming Interfaces (APIs) concerning device user location, messaging APIs that will enable new types of user experiences and the availability of push notifications through a startup that provides rich-media mobile push as a service. Innovation-minded mobile developers we talked to agreed - these are intriguing offerings.

Carrier Level Location Data

"Carriers already know where every phone is (to 1-2 mile accuracy in the worst case) but there has previously been no way of getting that information unless you go talk to the carriers and try to strike a deal - which of course the little guys have no way of doing," says Aaron Parecki, co-founder of a startup called Geoloqi, which is targeting a bleeding edge practice called Geofencing. "I haven't heard of anyone making that available via an API yet."

The other advantage to getting access to this device from a carrier, instead of from an app on a device? "That's the holy grail of cell phone location," Parecki says, "because it doesn't require the user to start an app to track themselves. It's 'always on' after they start using it the first time."

Duvander's caveat ("with proper privacy controls") is an important one, however. While developers, marketers and others may be thrilled at the prospect of easy, programmatic access to passive, persistent user location data, users may be more cautious in their enthusiasm. Consumer response will likely depend on how effectively best-practices emerge and how compelling the apps that get built on these APIs prove to be. The vast majority of mobile location services people use today are opt-in, explicit about sharing location selectively in a one-off fashion.

The blog Duvander edits, ProgrammableWeb, happens to be owned by Alcatel-Lucent, a major telephony middleware provider now focusing substantial energy on what it calls Application Enablement, or carrier-level APIs similar to what Verizon appears to be offering. We've asked if Alcatel was involved with the Verizon announcement today and have not yet received a response. (Note that Alcatel is also a long-term sponsor of ReadWriteWeb, and I wrote the Forward to the company's recent book about Application Enablement. Again, I have no idea if Alcatel is involved with or competing with this Verizon news.)

Photo by Laura Diaz

Messaging and Push Notifications

In addition to the location APIs, Verizon also announced the availability of messaging and push notification features as a service in the Verizon Developer Community. Portland, Oregon startup Urban Airship was selected to power push notifications, and is offering push with a multi-media payload. (Our previous coverage of Urban Airship.)

A Verizon App Platform

Verizon is not known as a great platform to develop apps on. This developer conference received almost zero press coverage - the exact opposite of what we see from the best-known mobile app platform on the market, Apple.

Every other carrier wants a piece of that action, though. Rich push and messaging APIs are probably a must-have, and may be one area in which other carriers could beat AT&T/Apple's clumsy implementation of Push.

Carrier-level location APIs though are just-plain hot, though - from a developers perspective.

Can Verizon combine market leadership, superior wireless coverage, a more compelling price-point (for inferior phones) and an ambitious developer strategy to win some hearts and minds? Who knows - but hopefully we'll see developers pushing the envelope to build some inspiring new technology with these new technical capabilities.