Comment 6 for bug 1881588

I have discussed this and upon closer inspection, we actually we do have an API for console-conf to get the username of a managed device, but the logic that console-conf should follow is a bit more convoluted because eventually we may have devices that are managed (and thus should not allow configuring through console-conf), but do not have any users. So console-conf should not assume that a managed has users and that a device that has users is managed.

The flow that console-conf should follow is this:

if $(snap managed) is true:
    if $(snap /v2/users) is not nil:
        for user in $(snap /v2/users):
            if /home/$user/ exists:
                display "ssh user@IP..." forever
            # else fallback to saying there are not managed users
    display "device managed without user @ IP"
else:
    display console-conf setup screen

The first API request for determining if a device is managed can be done with an HTTP GET request to the snapd /v2/system-info endpoint after a device is seeded, looking at the result.managed key. This is the equivalent of running on the command line `snap managed`.

The second API request for determining the username of managing users can be done with an HTTP GET request to the snapd /v2/users endpoint, looking at the result key which is a list of user objects. console-conf should iterate over all of these users, starting with the user with the lowest ID (note that the ID here is not a UID, it is an internal tracking mechanism for snapd, essentially first-come first serve for created users), checking if the user has a /home directory, and if the user has a home directory then we presume that the user could login via SSH. The username key is the name of the user that should be displayed in "ssh <user>@IP".

@xnox does that all make sense?