@varun I thought about the name for keyserverAuthActionTypes - I remember there were a lot of different variations with words "identity", "olm", "auth", "login" when we were discussing all of this
I talked to @tomek, since he will be working on ENG-6081, and he noticed that:

1. using identity will be the default in the future, so it doesn't necessarily make sense to put it in the name, it will also be confusing if a keyserver endpoint has "identity" in the name
2. olm is an implementation detail
3. auth makes more sense than login, because it is also a register endpoint

And I think that from client's perspective it's important to distinguish between identity and keyserver calls, so authActionTypes would be too arbitrary
So we think keyserverAuthActionTypes make the most sense. But I wanted to ask your opinion, since you have the most context

A little confused why we need to introduce a "fake" login type. Why not introduce the real one, and have @varun start using it once he gets to it?

A little confused why we need to introduce a "fake" login type. Why not introduce the real one, and have @varun start using it once he gets to it?

@varun needs to call identity login before I'm done with this refactor. From what I understand, we want to be calling identity login/logout to check if it's working properly, without triggering changes in redux at first. @varun and I discussed this and together decided to create this fake action

Adding @varun as blocking because we have some repetition between this diff and D10490

From what I understand, we want to be calling identity login/logout to check if it's working properly, without triggering changes in redux at first.

Seems like we're introducing a "real" Redux action here, just we aren't adding any logic to process it to the reducers.

Seems like we're introducing a "real" Redux action here, just we aren't adding any logic to process it to the reducers.

But I need to implement the logic in reducers, before we are ready to reduce the actual action which we will already be dispatching

Understood – thanks for clarifying. So we'll have two actions – one that is being dispatched by @varun's code (the "real" action) and one that is being reduced by your code (the "fake" action). After things are ready, we'll replace all instances of the "fake" action with the "real" action. Does that sound right?

keyserverAuthActionTypes makes sense to me. i'll update D10490 and the rest of my stack to use that terminology

Understood – thanks for clarifying. So we'll have two actions – one that is being dispatched by @varun's code (the "real" action) and one that is being reduced by your code (the "fake" action). After things are ready, we'll replace all instances of the "fake" action with the "real" action. Does that sound right?

Yes, exactly!

In D10424#303866, @varun wrote:

keyserverAuthActionTypes makes sense to me. i'll update D10490 and the rest of my stack to use that terminology

Great, thank you!

I agree it's unnecessary for the keyserver to send the user their id and username, but right now the identity service doesn't manage avatars or notif settings. I think we should either stick with LoginResult and return the user ID and username even though they're redundant OR modify KeyserverAuthResult to return only the avatar data and notif settings from currentUserInfo.

According to this discussion avatars and notif settings will be handled by backup and tunnelbroker. But I don't think that's ready yet, so you are right.

We will just need to remember when updating the endpoint that some clients expect this data

But we should make all fields that use responses[ashoatKeyserverID] as optional, since the action may not call Ashoat's keyserver at all (See D10490)