Support the Account portal

[DemiMarie]

The problem you're addressing (if any)

Users need to re-enter their name and avatar photo in every application, including in ones that support the Account portal.

The solution you'd like

Implement the portal. The implementation should remember what the user chose last time but should also support responding differently, so that users can use e.g. pseudonyms.

The value to a user and who that user might be

Users will have a better experience in applications that integrate with the Account portal.

Completion criteria checklist

No response

[marmarek]

Is it specific to qubes in any way? Sounds like something the VM can do on its own, depending on what a distribution used there provides.
Or do you mean some global one shared across qubes? In that case, IMO it's a bad idea, really easy to leak some data between qubes.

[DemiMarie]

I believe that normal distros implement this as follows:

• The account portal allows sandboxed applications to ask for this information. For instance, it might be used by an email client to determine what should name should be used when sending email. The example from the documentation is, “Allows your personal information to be included with recipes you share with your friends.”
• If the user declines, the application should prompt the user to enter the fields manually or leave them blank. If it does not, I consider the application buggy.
• The portal reads the information and returns it to the calling application.

This portal is therefore purely a convenience feature for users, who do not need to re-enter their name and avatar URL over and over.

That said, I’m not sure there are even any users of the portal, so I think this can be closed as “no demand”.

[github-actions]

This issue has been closed as "declined." This means that the issue describes a legitimate bug (in the case of bug reports) or proposal (in the case of enhancements and tasks), and it is actionable, at least in principle. Nonetheless, it has been decided that no action will be taken on this issue. Here are some examples of reasons why an issue may be declined:

• No solution can be found.
• The proposed action is not possible.
• The proposed action would weaken security to an unacceptable degree.
• The proposed action would be too costly (in time, money, or other resources) relative to the benefits it would provide.
• The proposed action would make some things better while making other things worse, and the trade-off is not worthwhile.

These are just general examples. If the specific reason for this particular issue being declined has not already been provided, please feel free to leave a comment below asking for an explanation.

We respect the time and effort you have taken to file this issue, and we understand that this outcome may be unsatisfying. Please accept our sincere apologies and know that we greatly value your participation and membership in the Qubes community.

If anyone reading this believes that this issue was closed in error or that the resolution of "declined" is not accurate, please leave a comment below saying so, and the Qubes team will review this issue again. For more information, see How issues get closed.