chore: lerna.json enable authentication-demo

[gobengo]

This got dropped during:

• chore: merge master into #132 #208
• ed92338#diff-2d72bdead8afa0798d18995311992d684348a694c2d5e214e8e4d2b6153e4821
• chore: mergeback next -> identity-provider/2021-01-04 #216 (comment)

This is why I tried to deliver #132 before moving to lerna all the way. Moving all the way to lerna wasn't required to do pre-releases of authentication + agent. No one disagreed with this approach at the time.

Same caveats as two weeks ago and one week ago

# until https://github.com/dfinity/dx-triage/issues/35#issuecomment-785329116
ln -s $HOME/dfinity/agent-js/apps/bootstrap/dist $(dfx cache show)/bootstrap

Where does this leave the demos?

• demos/sample-javascript demos how to do authentication without @dfinity/bootstrap
  • dev constructs their own identity
  • dev constructs their own HttpAgent -> agent
  • auth through custom auth.ic0.app on cloudflare
  • will it work with dfx@0.6.24 and its replica? (not overriding to use mercury)
  • don't think it can work with current dfx new modules like ic:canisters/{name}, because they eval before canister js, and they use-and-never-reread window.ic
• demos/authentication-demo demos how to do authentication with @dfinity/bootstrap, which 100% of our partner developers use, and I believe this is the only reasonable way of 'a developer can' right now and on Monday, when I expect open-chat will integrate along one of these two paths, depending on whether they want to ship to Mercury or Sodium.
  • @dfinity/bootstrap has, for my whole time here (and I believe after SDK.2021.D), been responsible for loading before dev canister js, constructing an HttpAgent, assigning it to window.ic.agent so all the ic:canisters/{name} modules use it when evald
  • As of feat(identity-provider): Identity Provider v1 #132 , @dfinity/bootstrap runs an IdentityActor that boots before canister js, keeps track of currentIdentity, and handles IdentityRequestedEvents by updating the event dispatcher with the currentIdentity as well as any subsequent identities changed to by canister js authenticator.useSession or the resulting BootstrapChangeIdentityCommand.
    • but that whole approach can't work if we change the 'release process' at the last minute. I am so lost on why we'd change this given our assignments in 4 sprints this year (and all of q42020), none of which required this.
  • auth through staging IDP
    • current deployment: https://identity-provider.sdk-test.dfinity.network/
    • this staging environment should probably be redeployed (big bummer it won't be as useful without /relying-party-demo, but I didn't want to do that until the product owner had accepted the proposed implementation of https://github.com/dfinity/dx-triage/35 and the code is in next (it is now after feat(identity-provider): Identity Provider v1 #132, but @stanleygjones hasn't accepted 35)

Personally, I think devs are best off if we include both of these for now as we onboard people across sodium, mercury, beta, and more, and as implementation details of ic-fe, tungsten-bootstrap, etc. shift over time and according to organizational needs and plans.

[gobengo]

video:
https://user-images.githubusercontent.com/171782/109230366-989b6100-7779-11eb-863d-735bbf402ac1.mov

[gobengo]

@hansl If you can spare a sec before tomorrow's standup, will you please weigh in on anything that seems false in "Where does this leave the demos?" above?

[hansl]

That IDP staging is old. You can either use the latest at https://auth.ic0.app/ or update the staging.

Also, you can use your own local one (it's only static files) by going in the identity-provider folder and running npm run develop.

[gobengo]

That IDP staging is old. You can either use the latest at https://auth.ic0.app/ or update the staging.

My understanding is because of this (default identityProviderUrl of Authenticator is unsafeTemporaryIdentityProvider), but I'd hoped to change that s quite fast-follow of dx-triage#35.

The main thing is that the authentication-demo doesn't specify the identityProviderUrl, just uses the default, and I agree that in the medium term (closer to short...), I also want to see that more-beautiful https://auth.ic0.app. However, first I just want to land this how I authored it before https://auth.ic0.app started resolving :)