• Read more about Facebook Places: The Third Place is Here

Today Facebook announced “Facebook Places” or “The Third Place,” a new feature that allows its 500MM users to check into a location just about anywhere.

Starting today, you can immediately tell people about your favorite spot with Facebook Places. You can share where you are and the friends you’re with in real time from your mobile device.

Highlights

At each location, Places lets you see your friends and other Facebook members (even if they’re not your friends), who are nearby, a feature called “People Here Now.”

Friends

You can tag your friends when you check in to a place. You have to allow proxy check-ins to have them post to your profile, but they’ll still post on the Place page.

What does this mean for businesses?

• Share where you are

• See where your friends are

• Find new places to go

• Will be integrated into Facebook Pages

• Reporting Places (Report, Abusive, Permanently closed, Duplicate)

Mobile Device Support

• New Facebook iPhone app with Facebook Places support is coming tonight
• Android, Blackberry and all other Facebook app enabled phones will be Places enabled in the coming months
• Places should work fine on any modern mobile browser

Developers and API

• Places available with a read API

• Write & Search API are in private beta

Places Partners

• Gowalla, Foursquare, Brightkite, Booyah, Yelp and more will integrate it instead of getting killed by the 500 pound gorilla

• Foursquare is a “partner”, but has nothing to announce concerning integration. “This basically validates that we’re on to something with check-ins”, says Holger Luedorft from Foursquare. Foursquare says they’ll continue to work on their platform and they look forward to leveraging the Facebook Places API.

• Yelp and Keith Lee from Booyah, made a new app in three weeks using the Places API, called InCrowd. It will be available for the iPhone within the next few weeks.

General Usage

• Places will be U.S. only for now. Facebook will be rolling out slowly – starting tomorrow.

Reactions and Privacy

• As expected, the ACLU has its hands all over Facebook Pages concerning privacy implications.

• Default for check-ins is “friends-only.” You can remove any tag or check-in. You can opt out of being tagged in others’ check-ins.

Demo

Your thoughts

How do you think Places will be received by the rest of the world? Will you stop using Foursquare or GoWalla in favor of Facebook Places? Let us know in the comments.

Updates

Stay tuned, we’ll keep you posted with any new updates to Facebook Places right here.

• Read more about Facebook is the Private Beta of the Semantic Web

Facebook recently announced their intentions to become the center of the universe for online identity and social connections. While the new functionality of the Facebook Open Graph is exciting and represents a real glimpse into the interconnected semantic web, it has also sparked numerous concerns about placing so much power into the hands of a single company. As it turns out, not everyone on earth is content with having their Facebook profile be the only representation of their identity on the web. To those sweating over the level of control and power this gives Facebook, I say:

Yes, if Facebook perpetually controlled identity and semantic “Liking” that would be very bad for the web as a community. And it seems like it will be difficult to overcome the hurdle of that damn “Like” button on every page on the internet, right? I mean, sites aren’t going to want a NASCAR array of “Like” buttons cluttering up the place. How can anyone be expected to compete with Facebook’s 400 million user promise?

Terraforming the Web

We should really all be thanking Facebook for what they’re doing. They’re essentially the first colonization spaceship sent out to the world wide web, a rough-and-tumble wild west crew that gets to make their own rules because they’re doing the pioneering. And while their approach may smack of self-interest, you have to realize it could have been so much worse.

The acquisition of FriendFeed seems to be the best thing that could possibly have happened to Facebook, because rather than the openness of FriendFeed being subsumed by the closed past of Facebook, the FriendFeed team seems to have done the impossible: they’ve convinced Facebook to participate in the broader conversation about open standards (even if tentatively).

The result of Facebook’s Open Graph push will basically terraform the web, reshaping it into something new where semantic applications can thrive. Of course Facebook is doing this all for their own benefit…why shouldn’t they? But they’re also doing it in such a way that they simply will not have control of it forever. So how can this shake out for the best? How can an open protocol with a proprietary “Like” button become the open, semantic web that many dream of? Simple. Browsers.

Firefox and Chrome are the Key

Ultimately the interaction with the semantic web doesn’t belong on the website to begin with. That’s Web 2.0 thinking. What we’re going to see in the next months and years is a move of semantic activity and identity being handled in the browser, either explicitly by the vendor or through extensions on their platform. Mozilla is already experimenting with this, and I would bet Google has some ideas of their own along the same lines.

So while Facebook may get to own the “Like” button on the page, once every browser comes with a “Like” button that connects to any number of services according to an open protocol, once I can log into a site using identity stored in my browser and skip the Facebook authorization dance, the semantic web will be realized in full. And the great thing is, everyone will have all of the data they need to build such services thanks to the aggressive partnerships pursued by Facebook.

In essence, everything that Facebook announced at F8 ultimately belongs in the browser, not through a single connection to a proprietary service. And the great thing is that not only is that the better solution for proponents of the open web, but it’s also even easier than Facebook for users of the browsers that eventually gain these features. Facebook has always won the war for identity based on convenience, but nothing is more convenient than the tools built in to my browser of choice.

So thanks, Facebook, for launching the private beta of the semantic web. I can’t wait to see what happens when it goes public.

• Read more about OAuth2 Gem: Just in Time For Facebook's Graph

While I’d been tracking with great interest the progress of OAuth 2.0, Facebook lit off the powderkeg yesterday by announcing that their entire API was moving to the protocol (as well as to RESTful JSON). As a developer who had been constantly confounded by the relentlessly hostile environment that Facebook seemed to present to developers, yesterday was a sudden and welcome about-face. The acquisition of FriendFeed, it seems, gave Facebook the talent they needed to do it right this time.

But anyway, on to the news! We have just released a gem for OAuth 2.0 to work with the new Facebook API. You can get it right now:

gem install oauth2

We wanted to get this into the hands of developers ASAP so for now the functionality is pretty much limited to the “web server” type of authentication (the protocol includes many different strategies, all of which will be implemented on the gem over time) and has been tested to work with Facebook’s new API.

So how do you use it? Here is an example Sinatra application containing all of the code necessary to authenticate and then perform requests against the Facebook API.

require 'rubygems' require 'sinatra' require 'oauth2' require 'json'  def client   OAuth2::Client.new('api_key', 'api_secret', :site => 'https://graph.facebook.com') end  get '/auth/facebook' do   redirect client.web_server.authorize_url(     :redirect_uri => redirect_uri,      :scope => 'email,offline_access'   ) end  get '/auth/facebook/callback' do   access_token = client.web_server.get_access_token(params[:code], :redirect_uri => redirect_uri)   user = JSON.parse(access_token.get('/me'))    user.inspect end  def redirect_uri   uri = URI.parse(request.url)   uri.path = '/auth/facebook/callback'   uri.query = nil   uri.to_s end

So now you’re ready to get started with the new Facebook API! This is still an early release, but I’ll be working on it a lot in the coming months, partially as preparation for my talk at RailsConf in which I’ll be delving into the OAuth 2.0 specification and what it means for Rails developers in-depth. The code is, of course, available on GitHub where you can report any problems you run into. Enjoy!

Update: Those who aren’t terribly familiar with the protocol may wonder why OAuth 2.0 isn’t just rolled into support of the OAuth gem (or why I didn’t fork it and do it that way). Honestly, I would have liked to, but OAuth 2.0 is an almost entirely different beast than 1.0a and they share so little functionality that it would basically be two projects living under the same gem name. So that’s why!

• Read more about Do's and Don'ts of Social Networking

I was quoted in today's Launch magazine in Do's and Don'ts of Using Social Internet Sites for Business. In the article, I offer the following advice on adding and interacting with contacts on various social networks:

Don't forget your manners.

While nearly all social networks have rules for participation (don't post obscenities or copyrighted material, for example), the etiquette for adding people to each network is defined by the mores of those on the network, Postman says. He offers a few guidelines:

• Users should be particularly careful to avoid the appearance of flirtation and inappropriate comments and messages. Use the same rules as you would in the workplace.

• Don't send blatantly commercial messages. Business networking is OK. Shameless promotion and cold calling is not.

• If the network allows, give the person you are inviting some context for the invitation.

• Do not take it badly if someone declines or ignores your invitation to connect. That's their option.

• Read more about Announcing 'Cards' - A Facebook App

Cards (along with Intridea’s future Facebook apps) will follow a strictly no-slimy-tactics policy. Application installation is only required for sending cards, not viewing the cards that you have received. Ideally, we would be very happy to have a one-to-one ratio of active users to installed users, though we leave that up to the users.

Cards allows you to:

1. Send photos you’ve uploaded to Facebook as photo cards to any of your Facebook friends.
2. Choose from a selection of pre-designed greeting cards to send to any of your Facebook friend.
3. Submit a greeting card to be considered for inclusion in Cards. If chosen, your name will live on in Facebook glory forever!

We’re really excited about Cards, and will be rolling out new features soon. Stay tuned for updates.Cards (beta) is a sweet little app that lets you send your already-uploaded Facebook photos or designs submitted by other users as greeting cards through Facebook.

• Read more about Facebook Apps on Rails - Part 1

At Intridea, we’ve been busy little beavers working on a couple of hush-hush facebook apps. Needless to say, you will be hearing about those quite soon. But first, a little discussion about Rails plugins for the Facebook F8 API is in order.

The most popular Rails plugin for the Facebook API is RFacebook. The core implementation of RFacebook relies a lot on Hpricot and method_missing (covered earlier in this post) to map the XML results from Facebook to Ruby objects.

There are a few goodies in RFacebook: SSH tunnelling, URL rewriting, and a nice debug panel that displays right on the facebook canvas. RFacebook is becoming more and more mature by the day, but unfortunately maturity sometimes does not equal usability or productivity (by Rails standards, of course). My main issue with RFacebook however, is the convoluted MVC design. For example, facebook session calls are made through a fbsession object. However, this object is accessible only within the controllers, and not the models. Moreover, fbsession objects use method_missing to transfer methods not defined in the ruby code over to Facebook, and so there is no concrete mapping between functions and their variables—it makes things like passing partials instead of strings as parameters for session calls in the controller more difficult, and lo and behold, we’re forced to use the ugliness that can only be mentioned as “html-code-in-the-controller”. Small things surely, but we use Rails and Ruby to “increase productivity and happiness”, and any libraries that have the possibility of being heavily used should be written with such things in mind.

A new contender is Facebooker written by Chad Fowler. He outlines the design points (most of which are vehement arguments against RFacebook’s way of doing things), in a very nice post. A quick look at the code (which is all I have done so far, more to come later) suggests that this is really a very concrete API, that maps functions to non-method_missing functions. However, it does have a bit of a learning curve right now and is well below RFacebook in terms of immediate user-friendliness, which is to be expected since it is still under development and has had no public announcement besides that blog post. More details as we move forward..

Running a quick search on ‘rails facebook plugins’ gives me more results today than it did a few weeks ago, so it seems apparent that there are a few more plugins left that I have missed. Along with that, the new release of Facebook’s Data Store will most definitely bring forth atleast a few more new ones.