Just to clarify, I think this is a good example of how you can keep the authentication flow of logic within a constant signal as opposed to having to check for parameters in a callback and then call a method with another nested callback.

If we get an error that's a GitHub two factor auth error, well let's just insert into the signal the signal that comes from trying two factor auth – there's no need to fail just yet.

If we get any other error we don't have a way to recover from that, so let's just send it through the signal and maybe a subscriber somewhere farther down the line deal with it. Ultimately that's what we do within the [application `-start` method](https://github.com/andrewsardone/thingshub/blob/64e055e8a57921bd9de56ac08423a08b00df0c0e/thingshub/CDZThingsHubApplication.m#L35-L55). We'll null-out our sync engine if there's an auth error, and we'll get our exit code based on the error/no-error of authentication.

What I like about this last part is these two auth flow subscriptions are separated – there's no working with them within a single callback. You just declare [one relationship for the sync engine](https://github.com/andrewsardone/thingshub/blob/64e055e8a57921bd9de56ac08423a08b00df0c0e/thingshub/CDZThingsHubApplication.m#L35-L41) and a totally [different one for your return code](https://github.com/andrewsardone/thingshub/blob/64e055e8a57921bd9de56ac08423a08b00df0c0e/thingshub/CDZThingsHubApplication.m#L47-L55).