I will never do that again. If that was to become the standard, facebook shot themselves in the foot with their crappy APIs anyhow (see http://news.ycombinator.com/item?id=1731427 )

And I have a facebook account, and I'm really hesitiant to like or authorize anything for fear of the author (or hacker) using it for malicious purposes or Facebook one day making my actions public etc. I think a lot of folks are too.

FB may have been seen by some folks over the last few months as the magic solution to universal social media authentication but I think its becoming apparent that it is not. And thats a good thing.

I'm not quite as fearful for myself. However, if your application requests access to my friends list, you've just struck out with me. Even if I'm inclined to trust you, I don't believe that I have the right to make that decision for my friends. I won't expose them to you, so you can't have my business if you require it.

I denied that second query and was able to log in fine, but the question is, why the hell did they ask in the first place. Seemed underhanded to me (most people would have been confused and probably said, "Yeah, I want to log in, I guess so, sure").

No one is forcing you to use a site that requires Facebook, but obviously (based on the comments here like yours) companies requiring it should probably rethink this if their primary audience is tech-savvy geeks.

If I had a Facebook account, this would scare me.

So on facebook, you won't be blocking Facebook.com. But on other sites, facebook would be blocked.

  ||facebook.com^$third-party

||facebook.com^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net

||facebook.net^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net

||fbcdn.com^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net

||fbcdn.net^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net

The key is to allow FB's CDN when on FB, but to disallow it and everything else when not on FB.

I'm never on FB so this takes care of it nicely.

Is it too short? Or not insightful enough? Or.. do you disagree with his opinion?

From an ad-blocking perspective, the Google AJAX Libraries CDN and the rest of Google's properties are in no way related. The Google API, Libraries CDN, and supporting documentation is the only thing on the googleapis.com domain.

I think ultimately it's going to come down to a paid, independent service. Startups can't offer this kind of thing for free as there is no trust involved in the transaction. Likewise most large companies have already traded away their trust capital for various fiscal and political gains over the course of their existence. No, there must be some legal recourse for the consumer for the moment the authenticator screws up, and the only way to transfer risk in that way is with money.

Probably the single biggest barrier to this is the widespread desire to remaining anonymous on the web. The thing it seeks to combat is precisely the thing so many value so greatly: maintaining multiple identities, personas, existences on the web.

If your site isn't worth a separate identity, why am I interacting with it in the first place?

- Maintain a separate login and password for every site. This requires a lot of memorization and is a pain in the ass when you find yourself trying four passwords because you forgot which you used.

- Use password management software or a naming system that lets you keep track. This is effective but is a bit much for a majority of people who do not, and probably never will, use tools and reasoning to help them do things on their own volition.

- Use the same login and password almost everywhere. This is easy but is shitty security.

You might claim that using a third-party authenticator is just like option #3, but it's not. Option #3 above means that your single credentials are under the control of the least secure site you use them on, so if someone cracks some install of PHPBB version 0.0001 that you logged into, you're fucked. Using a third-party auth provider relieves you from this worry. It even means that you can switch at your leisure and start using a hardware generator or a long passphrase if the provider supports it.

This sort of authentication system should be built into the browser, entirely under my control, and every site should be given a separate identity token.

Not saying it's not possible - not trying to shoot this down at all - just I think it's a major issue.

The difference is that you control the connection and your information directly. With OpenID or Facebook the connection is directly between those entities and site you are visiting. With a browser-based system, the connection is always between the site and you or the cloud and you.

Here's what I do. I have two branches of passwords: one unsecure and easy to dictionary attack, another that was randomly generated and I got into muscle memory when I was a boy. Each secure site gets its own slightly different version of the password, with an additional suffix which is usually a small word.

It's a system that's served me well. Are there some glaring weaknesses that I should take account of and switch to something else?

Here's one possible scenario: let's say that I happened to be a member of a website that unfortunately allows an attacker to hit their login form as many times as they like and as fast as they like with various username/password combinations, and by brute forcing this login page in this way, they manage to determine what my username/password actually is. Now the attacker does know my username/password for one website I belong to and - if they're smart and determined - it may occur to them that now they know one of my usernames/passwords they might use these details as a starting point in trying to brute force other accounts that I may have on other websites.

I used to run these kinds of brute force attacks against websites back in the day when I had nothing better to do and before I had to work for a living. Often I was quite successful, but I wasn't targeting specific users and even back then I could tell that websites were getting more savvy in terms of detecting and defeating such attacks. So no doubt it would be harder to pull this kind of thing off now and it would probably depend a lot on which website(s) you targeted. But surely it wouldn't be impossible.

[1] http://blog.moertel.com/articles/2006/12/15/never-store-pass...

The harder you make it for us to visit, even if it's a minor inconvenience, the less likely we will.

Yes, it's a ridiculous example, but the vast majority of end users keep the same username and password for all of their online services. Obtain one U/P pair and you could conceivably access their identity anywhere. A centralized, specialized authentication provider could maintain multiple levels of authentication depending on what the service demanded. Perhaps your favorite news aggregator only required that you be authenticated with a username and password, but your bank could be using the same authentication service and demand a physical token or one-time password to continue to the service.

The idea is to maintain the convenience we already demand and practice in a manner which is orders of magnitude more secure.

I'm conservative about what I put on FB for this very reason. I consider logging into another site with my FB account part of "what I put on FB."

That is a loaded question that does not cover how and why google uses your emails.

"Always" is meaningless for SAAS that you don't pay for.

I don't know about Yelp but Pandora asks permission. http://www.flickr.com/photos/4braham/5030673157/

I even have a Facebook account somewhere - just don't like logging into another site like this for some reason.

People post with their real names instead of arcane nicknames from the 90ies.

With all the psychological and social results that follow.

But I rechecked a minute ago, and it really required it. It seems that they changed the policy this week.

OpenAuth (via Google or plain) or private authentication would have been fine, but those weren't options.

Take the recently released Gourmet Live app for example: http://itunes.apple.com/us/app/id391597058?mt=8

Although they made some especially poor choices in that app (you can end up navigating into sections of the app that you can't get out of without giving a Facebook/Twitter login, oops).

After the API issue last week both saw their 8+ LP scores dive down to 1! Lost commerce for both over the past few days equals multiple tens of thousands, still not seeing the scores recover.

The only time you should be really concerned about whether your user really is who they say they are is if you are (or you are interacting with) some sort of official government or similar entity that legally and officially requires proof of identity. Otherwise it should be perfectly acceptable to have multiple, disparate identities on the internet.

Which has nothing to do w/ lock-in on 3rd party websites. It has to do w/ the relative security competence of those who choose to use FB Connect vs. those who choose email.

When I see a dodgy username and password form, what I parse is "I can't wait for them to email me back my password in plaintext, and then store it without a one-way hash."

That's not to say that they are the strongest professionals in the world, of course.

The best login system is OAuth by far - it is secure, and doesn't have any risk attached.

I would like to give people the Facebook option, but I myself, don't use it unless I have to. Giving a dozen options via JanRain makes that easier.

When the plumbing works, it's a lot easier to enjoy the architecture where developers and designers deliver real services.

Facebook tends to leak personal information like crazy as it is; they don't need any help from random 3rd parties.

I too believe you should have your own auth system as a base, but maybe someone can provide some numbers proving that it actually is a waste.

I may very well do away with Twitter and email registration. Some of those 5% of new users might use Connect, and some might leave. That's fine. What I care about is streamlining the experience for the vast majority of my user base.

"I too believe you should have your own auth system as a base, but maybe someone can provide some numbers proving that it actually is a waste."

This is the way to look at it. Each service should test, analyze their numbers, and make the decision that makes sense for them. Blanket statements like "startups should never only use X for authentication" are just wrong.

My application (an alternatie to the iPhone App Store) supports Facebook Connect and Google Login (using OpenID). As I'm selling products, I can do a direct revenue breakdown on the two services, which shows a 2:1 advantage for Google accounts.

(If anyone is interested, the 2:1 Google advantage holds even if I control for "in the United States"; about 50% of my sales are in the US, so I have a great statistical sample, and the login breakdown for the rest of the world is nearly identical.)

Many sites have complex authentication and identity management systems for adding a simple comment. I don't contribute to these sites or return to them, no bookmarking. Too much of a hassle. Studies done by topix and others have shown that authentication does not increase the quality of posts. It's not even clear why comments need to be authenticated anyway. If the visitor is not purchasing something, there is no need to ascertain their true identity.

Look at both the hacker news and reddit systems for a reasonable example of doing it right. Choose a name and password and you are done. For reddit an email address is optional. Both of these sites are examples of places where there is intelligent interesting discourse. The same can not be said for sites with complex authentication systems.

I'd be more comfortable with Google doing this. It would simplify my sign in process for new websites, reduce the number of accounts and passwords I need to manage, remove the need for a password manager like 1password, and give me quick access to disable or block access to sites I no longer want to have an account with.

A startup could tackle this, but they would have to build trust and widespread adoption.

I also think it is a bad idea to outsource your authentication mechanism to a single private entity. What happens if your user deletes their account? What if Facebook thinks your site exhibits suspicious behavior and decides to not send along its users' authentication? Probably won't happen but if it does it could be a world of hurt, much like PayPal.

The use case is, I use FB sparingly because I don't have time to get sucked into that pit. I friend people I meet irl, and 'Like' sites that are relevant to my profession (personal branding & networking).

But I don't use it for any other purpose. So if your site isn't relevant to my profession, I don't want to connect via Facebook, and if that's the only login option, you've just lost me.

Every site should have OpenID and/or its own user accounts, so as not to lose users who for one reason or another don't want ot use FB.

I somewhat favor the StackOverflow approach, which is "we won't authenticate you, but here's a bunch of services that do", but inevitably I forget which service is actually tied to my account. This is how it's been with my HN account for a while, I loathe deleting the cookie, as I spent 10 minutes figuring out what ClickPass wants.

TripIt has both Facebook and Google Accounts. I'd probably expand to Yahoo! and Live Mail (if MS has anything for that) and leave it there.

And guess what, a facebook account is also an open id.

Happily, google is an openid endpoint, and basically everyone has a google account for gmail or something.

It might take 15-30 minutes to develop your own authentication system.

Even if only takes 10 with facebook, the extra 5 minutes are worth it to me to keep 100% control over my users' experience on my website.

In our system, two users are linked together for the purpose of our service. We do that via unique URLs. Do you think it is safe to match up emails for authentication.

i.e. when user 1 wants to get his profile, he has to input his email and his partner's email. If he fails to do that then we do not pull up the profile. Does this make sense and do you think it is secure enough?

It might be fine for completely non-sensitive data, but for anything else, probably not.

No idea what your service is about and if that level of security matters.

To be clear: even if it costs half your conversion rate, it may be valuable, at least until you grow in size to the point where having some support staff on hand is a non-issue, to force people to use a "well known" login provider. The users who insist on per-site accounts very well may just not make enough revenue to hire the support staff required to maintain them.

(Also, I think the privacy issues are seriously underrated: users often seem to insist that you should be willing to trust From: headers on email messages and that looking someone up by real name should be a common/valid way of finding people... I'd much rather Facebook, Google, Yahoo!, whomever, has to think about those issues rather than me.)

Edit: (typed on my iPhone, already fixed a typo)

Both have their problems, but no small company should waste support time when established techniques are available.

(EDIT: Oh, and I misunderstood your comment: no, you cannot have them initiate the request with their username, because they probably also forgot their username. I thought you were saying that they could initiate a request to look up their username before looking up their password, which has the "no stable identifier" problem I ended up going into.)

When you get users e-mailing you, incredibly angry, insisting that you help them because they are spending $X at your website and they can't even log in, you realize you can't pretend that these fully automated solutions work for normal people.

Hell, if you want to know real pain: normal users don't even have a single Gmail account, so my #1 support issue is actually users who log into my site with the wrong single-sign-on account and then get angry that none of their stuff is there anymore.

Universal Login 1.0 File:

    (ULAPI-1.0 (username "oconnore")
     (seed "a3k5...") (password-hash "pq3i...") (password-hash "ve83...") 
     (additional-information (eye-color "brown") (email "@.com") ...)))

Cool benefits of this are that you can use separate passwords for your bank and your twitter, and you can host your own ID (or pick someone you trust), only allow certain servers to request it, dynamically generate a unique ID for each site, etc.

I haven't looked into the technical details deeply but people keep talking like OpenID is safe. I assume sites that use OpenID never see my user name and password but what if the site says that it uses OpenID but actually just stores my user name and password? Would I have any way of recognizing that the site was using fake OpenID?

Sites you log into using OpenID never see your password. (For that matter, any competent OpenID provider will never store your password in cleartext, so they won't know it either.) The only thing the site knows is your OpenID url, and when you sign in using that, it redirects you there, to enter your password.

Live example. I use myopenid.com to provide OpenID services, delegated via a link rel="openid.delegate" tag on my personal site, bbot.org.

When I want to sign in via OpenID on a site, say, livejournal, I type in "bbot.org". Livejournal looks at that site, reads the link tag, and sends me to myopenid.com. I sign in there, and it sends me back to livejournal, now logged in.

In that case I guess I can live with it. I'll just have to go to the effort of setting up my own openID provider since I still don't want different sites tying my ID together so I'll have to set something up on my side.

This is all a lot more effort than it was before and I don't see any benefit at all to how I use the internet. But thanks for giving a detailed explanation of how it works. At least my security concerns are lessened (still, compromising one site and logging passwords will compromise every site you use this service with).

On that note, It is important to realize that certain sites or services on the web require some sort of social graph integration that require a login with a social networking account. In cases like this, you are developing an app for a user base that is not on FB or Twitter and then (purposely) alienating the rest.

Don't force people to user any third party login, instead, make them have a choice to sync their openid or facebook accounts to have extra features like facebook notifications, GCalendar and GDocs sync, etc.

Registering to an app must be easy, fast and intuitive. The use of third party authentication service must be unobtrusive, and should not limit your application, just improve it.

Turns out they did not go that route so I refuse to use FB login.

I found one service, where they have only Facebook login and it doesn't work for me.

I wrote to them and the assholes just ignored me.

I think it's arrogance. I mean, Google Account would make sense. Many hackers I know don't even have Facebook account.

On the other hand when I'm offered the change to login with facebook, not always I feel comfortable giving access to all my data.

This is a dangerous trend that encourages trading control over your Twitter/facebook/etc. accounts for easy registration on possibly-malicious websites. OAuth is not meant for this, and OpenID should really be being used instead.

What do you guys who are entirely not into FBC think about the last RFS?

For this site, user fraud is a big concern. I would much rather have an easy way to tell if someone is a "real" person, and Facebook gives me that.

If my market size goes from 1.5B to 500M because of this decision, that's fine. In our case, it's a calculated choice, like the dozens of calculated choices a startup makes every day.

Forcing Facebook because you think it will give you real people and verified accounts is wrong.

Authentication isn't -- and shouldn't be -- a one-size-fits-all problem. For us, Facebook has worked extremely well. (We originally supported Twitter and OpenID but dropped them when it turned out that 100% of our fraud incidents had authenticated with one of those two.)

That said, I'd love to know if our FB heuristics would "catch" you or not. Email me your fake FBUIDs and I'll publicly post their score. We can all learn something! portman.wills[at]gmail.com

With that said, my Facebook account probably wouldn't pass your test as I recently removed all my pictures, and removed all my likes disklikes, and most of my "friends". And have virtually no activity on it.

I am a bit of a privacy nut (multiple browsers, incognito, proxy servers, VPN's, multiple accounts online (including this site)) and I intentionally keep my person, work, online life etc. completely separate. So as interesting as it would be for you to test my accounts, it means I would have to kill you :)

There needs to be a term for that level of secrecy/strictness when it comes to online identity/authentication. A level so strict that if an identity gets exposed or authentication mechanism is bypassed that somebody, somewhere, will have to be killed.

Now I await eagerly for an HN reader from a three-letter organization to chime in. ;)

I spoke with a facebook employee recently and they apparently spend quite a bit of effort identifying likely duplicate accounts. Usually people make several accounts to have more farmville neighbors, so you may not get lumped in this category, but who knows.

Google does the same thing - I believe there was a post here recently about an interview where an employee said their was a console matching accounts and likely duplicate accounts the person has.

How does Facebook give you that, exactly?

Example: http://youropenbook.org/?q=panties&gender=female

Here is a very quick experiment I made:

- Get the name of one of your contact and the surname of another one and subscribe with that.

- Take the picture of a random girl on the internet that looks real, put a copy and paste famous quote in the description like "it will not rain forever".

- Subscribe to a couple of groups or pages with the word "sex" in them.

Bang, hundred of friends in a couple of days, and the profile now seems legit.

Still harder than generating fake profiles automatically, but I think that with a little bit of effort this can be automated too. There are also companies that will give you some hundred of friends for a fee.

I'm very curious how do you believe you can check that.

Startups love Facebook authentication more than users do.

Options, options, options. The internet is all about options. This stems from the fact that people would prefer to "Have it their way"... still waiting on BK to deliver that.

When people online don't have options they feel alienated. It's the expectation at this point.

Maybe I'm being harsh, and the app doesn't actually want to tweet in my name, but twitter doesn't allow it to request read-only access. Still, the permissions as displayed are clearly not what I want to grant, and I don't get to veto only the update ability.

I would rather not use a service than offer it the possibility of spamming in my name, and I have made that choice a few times now.

*Unless you make tweets private. But even then, your followers and followees are still public.

note: i am not on facebook

No: Don't force me to make another fucking password.

I have a whole shitload of passwords. I use an independent (not in the browser) password tool. I'd really like to be able to generate a password and login automatically: i.e. for my tool and the website to automatically hook up.

Oh, yeah that's called OpenID: http://openid.net/get-an-openid/

And no jokes about my tool please.

If you have a site that requires OpenID, I won't use it for the same reason I won't use your site that requires Facebook. If you're going to implement it, make sure you also implement a standard user/pass registration or you'll lose a lot potential users (as in most of them).

I can remember my email address. I can't even remember which openID provider I used to sign up for StackOverflow, let alone how they expect me to form the URL that I use for my login.

So once a month, when my cookie expires, I get to perform a forgot-password-like action, where I dig through my email to find my username, then try several combinations of it and claimid.net (or was it .org) until it lets me in. But I'm not in. I still have to type in my username and password and, click OK, then click OK on a second screen.

That's on the order of 10 more steps than it takes me to type in my email address and password. I remember my email. And I can type it in 400 milliseconds.

The thing that replaces OpenID needs to understand that.

I use my own page and use the OpenId delegate meta-tag to point to the domain that I also don't remember: http://openid.net/specs/openid-authentication-1_1.html#deleg...

This way you only have to remember your own URL like: http://openid.mydomain.com and the password that you've chosen.

Sentences that start with the word "just" should describe something easy to do. Like, you know, using your existing email address as your unique ID.

What I tell website developers is to add a login with Google, Yahoo, ... + OpenId (Google and Yahoo are openId providers) and each will redirect users to the correct OpenId endpoint (the one from yahoo, the one from google or your own).

And I don't say anything to non-technical users. They will see a "login with Yahoo" or "login with Facebook" or "login with Gmail" and they won't even ask me questions about OpenID. The ones that know what OpenId is and have their own custom URL will use it. Others will use the endpoints provided by Yahoo or Google and won't know what OpenID is and they don't need to.

You seem to think that number would be low. Experience with users & registration leads me to believe that it will be quite high. I personally don't plan to implement openID, so I can't do any testing. I'd be curious to see what your numbers say.

FB Connect actually does a pretty good job at being "easy to use". Just log into your FB account and you are set. I know it's not fair, but most people havn't posted anything to that openid website.

Google or Yahoo logins would work, since there's a recognizable brand name and there's a good chance that the user has an account on those sites.

The only time I used OpenID, it was for StackOverflow. The workflow was exactly as you describe for Facebook Connect, except substituting Gmail for Facebook. I really don't see where there's room to be tripped up, unless you can't handle the idea that you can log in using accounts from multiple places.

And then I have no users because nobody knows what that means.

Modify the services named based on expected clients. Choose one or more from the following: AOL, BBC, Facebook, Google, IBM, MySpace, Orange, PayPal, VeriSign, LiveJournal, Yandex, Ustream and Yahoo!. *

On the sign-up page, put in smaller text "You can sign up/log in with any compatible OpenID service" for the technically savvy users, if you expect any at all.

Don't straw man.

* list copied from Wikipedia.

Hell, opendns is giving me a spoofed ip address for google right now. What is that about, I thought they were secure. What else on my DNS service has been hacked? Bank sites? Probably.

2) Why does malwarenet.org want your Facebook password / to connect with your Facebook account?

That's the problem! Most people will look at this and don't know what to do. People hate choice, you generally have to lead them. On the other hand, that you even have to provide such a big list is a flaw in the OpenID spec in my opinion.

Obviously doesn't apply to everyone, but most of the time they don't want to think, they want to use the app.

Advertise one or two of the most likely sign-in credentials (so people who hate choice have it easy), and then put a small note that others are accepted too (so people who know what's going on aren't locked out).

I have been trying to seek out jobs to improve the UX of OpenID, and at MySpace I did the 1st popup login flow.

After MySpace imploded, I even tried for a short time to start an identity company called redrover, but then i had an offer to build an identity service for unity ( which was never internally supported ).

I am very passionate about making web identity work, and allowing people to have multiple web persona.

I have more idea's but i don't have a platform to innovate on.

Maybe now that I am working part time at UCSF on 'Profiles' with Harvard I have a shot again to fix OpenID, OpenSocial, and OAuth.

here is some work that Aza did to improve social bookmarking, http://www.azarask.in/blog/post/socialhistoryjs/

if you think about it a bit, you could use css inflection to determine or refine a list of potential OpenIDs that the user might use to log in.

maybe we finally make browsers smarter, or even better yet maybe with any login form on a web page

  <form type="login"
     openidprovider="http://myspace.com/{userid}"
     action="https://login.myspace.com/login">
  <!-- or something that supports webfinger -->
     <input name="username">
     <input name="password" type="password">
     <input name="openid" type="url">
  </form>

it also might be possible to link your openid to user profile in a browser, so that when you see the openid login form the browser can know what your profile is and delegate that identity transaction for you, like it handles cookies.

When I deployed a version of that on my sites, I got lots more causual users posting comments, etc. Most of them just click on google.

Do you know the endpoint for Google? I didn't know they supported it natively.

No thanks, and the fact that I'm not the only one means that if you're using FB to authenticate as a startup (IE need to get as many PURCHASING customers as possible), you're doing it wrong.

If I like your service enough, I will make sure to tell people about it. You do not need to try to do that job for me. That's insulting.

Edit: Please note that I realise that you may be an exception if it is something whose market IS a Facebook user (apps, etc), and I am simply addressing the issue as a whole as I have seen completely disparate sites that require a FB login for no reason that I can fathom.

1) It could, potentially, provide some value to you as a user. Quora gets to suggest people to follow for you based on your Facebook friends, so your experience on there is seeded with relevant information.

2) Nothing you do on the site you signed in with is published to your Facebook profile, without your explicit consent on a dialog box.

The trouble with this statement is that some users (myself included) don't believe (a) this is true even when they say it's true, or (b) that if it's true today it will still be true tomorrow.

Such paranoid users are worried that FB will make a privacy policy change that turns the privacy off "as a benefit to users," and the opt-out checkbox will be buried seven links deep. I try to use FB's controls to make my FB stuff fairly private, but I still operate on the assumption that one day FB will break my assumptions about what is or isn't shared.

The recent "Places" launch confirmed it for me. If I hadn't read someone else's blog post, I wouldn't have known that simply refusing to opt into places wasn't enough, I also had to explicitly block friends from checking me into locations.

Which brings us full-circle back tot the point of the post:

When a third-party application uses FB as its authentication mechanism, it gives the appearance of asking its users to trust FB with everything they do on that application.

So yeah, I don't put anything on FB that I can't handle becoming public some day. That doesn't mean I want it to be public, but I wouldn't knowingly put something private on there.

And that extends to third-party apps using FB for anything at all. I can't ever imagine using a linked-in kind of application that uses FB authentication. I'm not going to put certain business contacts and my business relationship with them where FB might be able to scrape the data.

I'm not dating, but if I did I wouldn't use a service that used FB for authentication. Or a personal money management application.

And my message to third party apps using FB for authentication is to take this into account. I won't say "don't," you know your market, maybe they don't care. But at least have your eyes open to people who might think twice if whatever you're managing for them might be sensitive.

Were I a startup founder, I would make it my goal to ensure that EVERY. single. potential customer can use my site, within my capabilities.

(edit: I don't know why you're getting downvoted; you stated your philosophy as part of the discussion, which I don't think is a good reason to get downvoted.)

Users will only give you one chance, if they see a reason not to come back then they won't come back, regardless of later changes you make.

When you're building a startup, in my experience you want to advance on the narrowest front you can, as you build out the feature set and reach the market. Don't provide 5 ways to do X if you can just provide 4. Or just provide 1. Etc. There'll always be room in the future to iterate and add support for additional use cases, additional integration points, and additional polish. But you generally want to get to market fast, get real users, real customers, validate your market assumptions and business model assumptions, and slow or stop your burn rate before your runway runs out.

Saying NO to some things frees up additional time/money to say YES to others. So you should prioritize.

Usually your addressable market will be something like: "English speakers over the age 22 with household income of at least $30,000 per year."

And then suddenly more people are on Facebook than not.