You can always let the person in and let them get started (you know, the valuable stuff that actually causes retention), and then prompt them 24 hours later to enter an email address or phone number for account recovery purposes.

Or give them a choice to create an account if they want to but not needlessly bug them about it.

Discord basically copied IRC and added voice chat. One didn't need an account for IRC why should they need one on Discord? Maybe to retain their nickname but that's it. And it was just a password, no email no phone number no nothing else.

I really liked the temporary and anarchic nature of IRC. No one was really in control.

I'm in the other camp on this one. I think the best thing to happen to IRC were the services that let you keep your nick or your channel without needing to maintain an army of bots. Channel takeovers on EFnet were a fact of life and it made things pretty unpleasant imo.

You created another nick or another channel and moved on with life. I liked EFnet, although the conversation got disrupted by troublemakers all the time, I met some really interesting people on it. Freenode was also too nice with nick registration and nicer people and no stinking IRC network task force on the channels like on UnderNet. You totally had the option to be a nomad or register a nickname or a channel.

The next logical step would have been to make it encrypted and add p2p voice chat via DCC or some other method. SILC tried the former but failed to gain traction, people either stuck with IRC or moved on to AIM and Yahoo Messaneger.

I don't see the similarity you draw between IRC and Discord, other than the fact they both have text chat. If you think nobody was really in control of IRC then you must have missed out on some of the structure. https://en.wikipedia.org/wiki/IRC_operator#Operator_types

IRC is federated. Most of the ops were volunteers. They were technically in control of the network until troblemakers launched DoS attacks and caused a split in order to take over channels. Discord has a very similar interface to most IRC clients.

If nag me with providing personal information afterwards I will stop using your app/website. Not being upfront about the kind of information you require comes off as extremely scummy.

From layman’s perspective it’s easy to reason that deleting an app or loosing the device will result in loose of data.

You can easily offer an optional data safeguard feature for account restoration.

So you'd assume this but older members of my family regular seem to not understand this. Either they just assume that their phone number is their "account" or in some cases make no distinction between the app and their account. They installed the app so where did their data go?

This is especially pronounced now that application sync between devices is more or less universal on iOS and (to a lesser extent) Android.

To the layman, the intuitive perspective is that it "just works" and is exactly how they left it previously, regardless of whether they have wiped their phone or replaced it. This isn't a dig at tech illiterate people but it is just how things are for the normal person. Hell I have been almost burned by this in the past when I moved phones and a certain app(FGO)'s data didn't transfer over.

TLDR The most intuitive thing is working out of the box and seamlessly transferring to a new device. The easiest way to do this is to allow it to be bound to a user's Google account, Microsoft account, and Apple ID.

Japanese phone carriers had carrier specific mechanisms that plain HTTP requests invoked from link in HTML with certain parameters gets captured by a proxy to include subscriber ID for authentication.

Those little security-by-securing-all-handset mechanisms kind of worked while there weren’t any publicly known rooted phone, in the wild, that can establish a session on featurephone APN, but emergence of iPhone and Android extinguished it.

This (partly) exists for some mobile carriers.

I know of at least one carrier, but is only usable for their own customer self care portals/apps. There it is possible to auto-login to their app if it is accessed via their network and not via Wi-Fi. For security reasons only a limited amount of functionality is accessible. Neither customer data can be changed nor can any actions resulting in additional cost (buying packs / options) be performed without additional authentication mechanism of a higher security level (auto-login via SMS or use of a password).

The MSISDN is only added to the HTTP request internally in their secure network and never exposed externally.

Actually, that sounds kind of a good idea to me.

Like, have http://my.number/ return the phone number for identification (though it would need some permission, I don't want every app to have access to it).

Make a HTTP POST with some data to http://my.number/validate and have it signed by the carrier, validate it against a list of public keys per carrier. Not sure why that wouldn't work today? It could even be a private/reserved IP address routed by all carriers to their auth service.

Edit: obviously, it wouldn't work over Wi-Fi without some cooperation at the OS level.

so you mean registering with your phone or email?

For games, there’s Game Center in iOS. If that’s not an option, you can provide an option for the user to enter their e-mail, phone number or use “sign in with” service. Usually you can put it in the settings together with a badge seeking their attention.

The idea is that, they already created an account by launching your code, so you don’t have to ask for account creation. Just ask for the information that is necessary to run your services and you can provide an optional method for account recovery.

As a user who has switched back and forth between iOS and Android multiple times, Game Center isn’t gonna cut it for me. But I see how it could be enticing in some use cases.

I currently use an email based signin for a site I maintain, which doesn't require a password. (Scheme described here - http://sriku.org/blog/2017/04/29/forget-password/ ) I don't think I understand the full consequences of reducing the steps for this even more, but am very curious to consider. I do need to maintain a sense of continued identity across machines and need to communicate with the users outside of the site, as my users expect that (and email serves that well). I think it is already fairly simple (relatively). What would be an approach to simplify this even more?

Hmm not sure I am a fan of custom logins everywhere...you say as a user it is 'simpler' but its simple like fast food is simple - low effort but I still have to take out the digital trash persay.

Probably better if the browser started to come with an e-mail set in it - then web admins can query for that and users have the option to change the email when they so choose...

Lots of apps that don't require a sign-in just give you a code that allows you to re-attach to all your saved data. It does require the user to save the code, but that's not super hard.

Nobody said it was hard. But what's your percentage of people that will "save the code" in a document and remember where it is X months/years from now? But everyone will still have their email for the most part.

Saving the code for some random app? No way. I'm too lazy to save a restoration code for my gmail account...

Alternative you can link an email without it being a necessary condition.

If its opt in 90% of people wont do it and near 100% of users will change their device in 1-4 years. 90% of your users will end up losing access to their account and 50%+ will stop using your service in frustration because of creators design flaw. Sign in with google is already almost as easy you don't have to have an actual account creation flow just a button click and a screen where users browser autofills their password and they click login. 2 clicks and 10 seconds.

I don’t know about android but on iOS, restoring the new device through an iCloud backup will bring back the app data too.

So, the users who switch from iphone to an iphone don’t loose anything if they follow the default upgrade process.

How many services do you use even if occasionally and how much toleration do you have for cleverly different things like magically knowing who you are based on device with some way to link an account after the fact. I have zero. I want things to work like other things work. I don't have time nor desire to figure out the non obvious way things work just because the dev is confused about how special they are.

That’s not the case here. Think of this as each app having a folder in your iCloud disk without being able to see other apps from different developers. As long as you don’t delete the app, the folder comes with you as you move from device to device so the apps installation is not required each time.

Also, lockin...

Sounds great while iCloud is up/you use iOS...prepare for the shitestorm when its not or the user decides to leave Apple... 'Easy' and 'Convenient' won't be the terms anyone is using.

That indeed sounds great for people using ios but 90% of users aren't

I'm pretty confident you could change those numbers with a few reminders to link your email/whatever for a backup. My WA account is extremely aggressive about setting backups, so clearly it works (but you don't need to be that aggressive. You can still respect users and remind them of things.)

I'm pretty sure that if you learn the basics of stitching you will be able to close up the wound after you shoot yourself in the foot.

Give them a popup like "link your email to keep your data even after you switch devices"! Don't give them a cancel option though. Give them a "I want to lose my data" option. That will make them think.

Yep and this could be enhanced further by provide a code retrieval service by email, plus facilities to change the code.