Actually, all the things which you mentioned I had in mind when I created this new UX. Maybe not about displaying the VCard of the user, but why not? The only thing is, that I would prefer (for privacy reasons) not to show the vcard but add a button so that user could "try" to get vcard (manual action). Why? because when we try to get vcard, in theory, it is possible to discover this fact by the other end and "mark" our account as "active" ie. by some spam bot gathering active XMPP accounts.

I was thinking about using "main window" and add better dialog in place when "chat log view" is displayed, but decided not to do that for now. I wanted to check the new UX in daily usage and then move forward (if the experiment would fail, there would be less cleanup to do).

The decision could be postponed (in theory, not now yet). As I worked on the new UX, I've created just a mockup of basic UX. There is no persistent storage for invitations or authorization requests and this will be needed if we would like to have "postponing" available.

Currently, when your account disconnects then authorization request is gone but the server will resend it upon reconnection and this is ok. However, this behavior is not true for MUC invitations and for that we will need this persistent storage which I mentioned above.

So, I'm glad that my experiment worked. I can schedule this new UX just after MIX as I've just started work on MIX in Beagle (as we have MIX on the server-side ready but not tests). I would do that in this order, as it would allow me to incorporate MIX invitation while working on this task.

• Manual/auto vcard retrieving - good point, but from the end-simple-user perspective auto is probably better. So, please make it a configurable option.
• Subscription requests - do we really need a storage for this? From what I remember in the spec and implementation, the contact in the roster is marked with status, not sure which one this really is "in_subscribe" or something. So, if the contact has this status, then the subscription request is sent to a user every time the user logins in. Automatically, so there should not be any need for additional storage for subscription requests.

You are correct, it should be configurable and we do not need to store subscription requests as those are resent by the server on each reconnection (until action is taken by the user).

We need storage for "invitations", ie. to MUC room or MIX channel and those will be (MUC invitations already are) part of "invitations" section. That is why I'm saying that we need storage as those are "messages" and will not be resent and we could retrieve them from MAM, however, we may not know the action which the user took - that is why we need storage.

We should also check if we can get vcard without subscription, I know we can with VCardTemp but now everyone is moving to VCard4 which are vcards stored in PEP and access to PEP nodes is guarded by subscriptions. So this needs to be checked before we add a presentation of vcard in this dialog. (this is mostly a reminder for me when I will work on this feature).

Thank you for updated version. However, I am not sure if I still have an option to postpone action on subscriptions requests once I click on the notification on the list. Also, I noticed that Beagle tries to do something, there is this circle showing up that Beagle is waiting for something. I guess it loads some data, vcard maybe? Might be good to add some text in the popup like: "Trying to retrieve additional user data...."

What do you think?

yes, this circle is for vcard retrieval. We can add additional text if you want.

As for postponing, just use ESC on the keyboard or click on a different chat and the 'event' will still be there waiting for you.

Ok, yes, I do not like user guessing what is going on, so some text would be useful here. I am also thinking of some way to let user know that he can postpone the action here. "postpone" button might be a solution but then we will have too many buttons. Maybe, again text: "Esc to postpone..." or something like this.