finiteloop

This is Bret Taylor, CTO of Facebook.

This was a mistake on our part. In the process of dealing with a routine trademark violation issue regarding some links posted to Facebook, we inadvertently blocked all mentions of the phrase "lamebook" on Facebook. We are committed to promoting free expression on Facebook. We apologize for our mistake in this case, and we are working to fix the process that led to this happening.

The nice part of the new Facebook messages product is that it isn't a standalone or competing messaging product, unlike many other products you are alluding too. It unifies SMS, email, and IM, and it interoperates with all of them. So if your friend emails you, you can reply by SMS or by IM, and they will receive it back in their email inbox. Likewise, if your friend is online when you email them, it will pop up like an IM, so they can reply in real-time.

I think this type of product has been a growing need for people for a while. Literally every single one of my younger cousins only uses SMS and IM to communicate and every single one of my older relatives uses only email, so you end up having to choose a communication protocol based on recipient rather than just choosing a person and composing a message.

It still has a number of quirks, but I personally think this is a really nice product. (I am admittedly biased, but I am being honest.)

I was also bullied in middle school. One day, walking off the school bus, I slammed his head against the window as I walked off. The bus driver, who had witnessed his bullying me for months prior was awe-struck and kept the bus running for about a minute before driving on past my block (no clue what she was thinking or saying, but it was really awkward as I walked from the bus down my block to my house). I spent the weekend thinking I would be suspended when I got back to school on Monday, but when I got on the bus on Monday, she didn't say anything, and nothing ever happened. Apparently the bus driver appreciated the fact he had it coming. And he never bothered me again...

You added your friends email addresses in your Gmail address book. On Facebook, your friends put in their own email addresses into their profile and set the privacy settings around it. It is a subtle but important difference.

This is really cool. Wish I had this when I built my PC.

We have talked a lot about solutions like this, but most of them end up more trouble than the encryption proposal. For example, developers need to link back to your profile page and your friends' profile pages in their UI - do we change all those URLs individually for all applications, too (since they contain a user ID)?

I think it is a clever idea, but it ends up breaking down in a lot of ways, and it has the bad quality that it is not backwards compatible with existing applications.

Navigation happens within Canvas iframes, and POSTs make the browser back button more than a little screwy. We definitely considered this.

Please see http://tech.fortune.cnn.com/2010/07/21/the-massive-hole-in-f...

We strongly suspect the contract is forged. We have not seen the original (no one has). Thus, we’re focusing on the things that are not open to interpretation and are indisputable -- Mark could not have given interest in a company that didn’t exist or and idea he had not thought of yet and, even if he could, the statute of limitations has expired.

Bret Taylor, Facebook CTO

Yes, I am here, and so is someone who is more knowledgable than I am: http://news.ycombinator.com/item?id=1513470

It depends on the site.

If you run a site that uses Facebook for login, when you log someone in via Facebook, you can ask for their email address via the "email" extended permission. Your site can then support a password reset page (like most sites already do) to enable those users to create a password via email if they decide to delete their Facebook account. Requesting email address is a good "escape valve" for users if you are concerned about this aspect of Facebook login.

Yes, we now are based on OAuth 2.0. See http://developers.facebook.com/docs/authentication/. You can just do a redirect to log someone into your site.

This is Bret Taylor, CTO of Facebook.

The goal of Facebook for login is to improve signup conversion rates for your sites and make it easier for users (so they don't need to re-enter all the same information and re-find their friends on every site they use). This thread is really interesting for me and the rest of the Platform team at Facebook because it illustrates how far we have to go. Please keep the feedback coming, however harsh :)

I get the brand perception and trust issues - it is something we care a lot about and are actively working on.

Beyond that issue, we have internally been talking a lot about ways of making the user experience smoother, more familiar, and less intimidating. If all of you running startups have practical suggestions about how the experience of a user using Facebook for login could be improved to help out your site, we would be really eager to hear it. It is a great time to get the feedback, as we are actively iterating on ideas internally.

This is Bret Taylor, CTO of Facebook. I just wanted to clarify a couple of things because I think people are reading a bit too much into our actions.

First, Open Graph-enabled web pages have been appearing in search since the product launched in April. This is not new and not indicative of a change in strategy.

Likewise, only the pages your friends have liked appear in your personalized search results. While we plan on increasing the pages’ distribution through search in the future, right now, search is not the focus of the team working on product. We are focused on discovery and enabling users to build out their profile by liking things around the web.

So we aren't really declaring war on anyone. But it does make a compelling headline :)

This is Bret Taylor, CTO of Facebook.

There are a couple of things I want to clarify. First, we genuinely support data portability: we want users to be able to use their data in other applications without restriction. Our new data policies, which we deployed at f8, clearly reflect this (http://developers.facebook.com/policy/):

    "Users give you their basic account information when they connect with your application. For all other data, you must obtain explicit consent from the user who provided the data to us before using it for any purpose other than displaying it back to the user on your application."

Basically, users have complete control over their data, and as long as user gives an application explicit consent, Facebook doesn't get in the way of the user using their data in your applications beyond basic protections like selling data to ad networks and other sleazy data collectors.

Crawling is a bit of special case. We have a privacy control enabling users to decide whether they want their profile page to show up in search engines. Many of the other "crawlers" don't really meet user expectations. As Blake mentioned in his response on Pete's blog post, some sleazy crawlers simply aggregate user data en masse and then sell it, which we view as a threat to user privacy.

Pete's post did bring up some real issues with the way we were handling things. In particular, I think it was bad for us to stray from Internet standards and conventions by having an robots.txt that was open and a separate agreement with additional restrictions. This was just a lapse of judgment.

We are updating our robots.txt to explicitly allow the crawlers of search engines that we currently allow to index Facebook content and disallow all other crawlers. We will whitelist crawlers when legitimate companies contact us who want to crawl us (presumably search engines). For other purposes, we really want people using our API because it has explicit controls around privacy and has important additional requirements that we feel are important when a company is using users' data from Facebook (e.g., we require that you have a privacy policy and offer users the ability to delete their data from your service).

This robots.txt change should be deployed today. The change will make our robots.txt abide by conventions and standards, which I think is the main legitimate complaint in Pete's post.

I think you meant "The trick is to own the platform and then sell the tools you must use to develop on it at an absurdly high price."

This is a great presentation. We ended up having a good set of terms when we did the FriendFeed Series A because we were fortunate to find good advice, but I wish I had read this when I left Google to start a company. The incentives implicit in these deal terms turn out to really impact your company at its most important points (acquisition, new funding rounds, etc).

Also worth reading:

Chris Dixon on "Ideal first round deal terms": http://www.cdixon.org/?p=271

Fred Wilson's response to Chris' post: http://www.avc.com/a_vc/2009/08/the-ideal-first-round-term-s...

I think it is generally a bad idea for any entrepreneur to read things that Ted writes because if you surround yourself with the kind of blind negativity he perpetuates, you probably won't ever build anything interesting out of fear of attack. For all the YC folks here, develop thick skin and ignore shit like this.

Ignoring all the anti-FriendFeed comments, which are ironic on many levels, we didn't build Tornado to optimize requests/second. That is just something the community has focused on post-launch. We built it to handle large numbers of standing connections for FriendFeed's real-time features. That is an area that is hardly as well-developed or solved, and I am happy we contributed some useful code given how many people are becoming interested in the space.

FYI, the instructions referenced in this message with Django/Tornado getting started code is at http://groups.google.com/group/django-users/browse_thread/th...

It may actually be faster, but I am still getting the load test environment set up. I will post the load tests here or on my blog when I run tests.

Mainly, I wanted to make sure Tornado integrates with existing frameworks so that more people can play with it, and the separable parts are useful to people who don't want to use the whole Tornado stack.

Thanks! Yah, the reason we rolled our own is because all the rest were so restrictive to authors. We didn't want a template system telling us what we should and shouldn't do in templates, so ours was a very thin layer on top of what basically translates directly to Python. It is actually one of my favorite parts of the system.

I am not sure what esi type tags are. Mind sending me a link?

Suffices to say, no, we do not support that :)

Likewise, 4 extra processes does not mean 4 times as fast if you only have one or two cores on your machine. Check out the details at http://www.tornadoweb.org/documentation#performance for how we ran the test.

CherryPy is multi-threaded, so I am not sure what you are saying is correct. There are two types of servers: multi-threaded, multi-process. Tornado is multi-process. If your server is multi-threaded, it uses all of the cores without additional processes.

CherryPy did max out the CPU on all of the cores in the load test, so I think it was a fair test.

It implements a lot of HTTP/1.1, but see http://www.tornadoweb.org/documentation#caveats-and-support. In practice, we run behind an nginx reverse proxy, so we assume there are missing areas. We recommend people run in a similar fashion in production. We did not optimize for protocol completeness given our production setup.

Yah, that seems to be Twisted's problem. I think projects that don't have a real site using them day-to-day end up in this state often - lots of incomplete implementations of lots of features.

How many deployed web apps really use Twisted? There are like 3 web packages in Twisted, most of which are really buggy, and as far as I could tell, barely used (even they acknowledge this, see http://twistedmatrix.com/trac/wiki/WebDevelopmentWithTwisted).

When we were developing this, we found that Twisted introduced as many problems as it solved in terms of incomplete features and bugs. The other protocols seem to have more attention than HTTP from what I could tell.

We don't do any joins in MySQL. We query the indexes in all of the shards in parallel to get a list of entity IDs and then query the entities tables in all of the shards in paralel to get the entity bodies as a second operation.