User Profile Handling

[NeonDaniel]

Is your feature request related to a problem? Please describe. Handling user preferences per-message allows for multiple users to make requests to the same core instance. It also reduces the number of times config is queried (from disk, database, etc) to once per request. It would also be useful to add more parameters to the profile (name, unit prefs, timezone, location, email, etc).

Describe the solution you'd like This has been implemented in Neon. The user profile structure is defined in neon-utils and for "default" functionality of one user per core, the profile is added to speech inputs and text inputs. This does add a distinction between "user" and "core" settings that currently isn't present in Mycroft.

Describe alternatives you've considered User settings could be read from some configuration wherever they are needed, rather than from messages, but this adds complexity for handling settings changes while an intent is being handled.

Additional context User settings have been present in Neon for awhile to handle requests from klat.com and other multi-user applications. There is a Neon skill for changing user settings via intent https://github.com/NeonGeckoCom/skill-user_settings

[krisgesling]

Yeah, this is an interesting one. I wonder if there are a few different levels for us to think about here too.

At one level - should we architect Mycroft in a way that a single instance could be used in the cloud by thousands of clients. There is a clear need to isolate any and all personal information. The data is merely being processed by some common functions.

At another level imagine multiple people in a household. Is there a single "Mycroft Assistant" that is helping two or more people. Or are they talking to their own assistants? Jane is talking to "Mycroft Assistant A" and Joe is talking to "Mycroft Assistant B"? In some ways it seems better that each can have their own more personalized assistant. But in another way, you are both talking to the same entity. Should it operate more like the house butler, whilst maintaining each users privacy?

Either way, in the future this could also enable joint actions - eg "get us a dinner reservation one night this week". Either a common assistant has access to both calendars and finds an appropriate time. Or the two independent assistants communicate to each other based upon whatever privacy rules / privileges have been defined. I lean toward the latter as it seems like a simpler structure, but haven't really put much thought into how it would be implemented.

Certainly like the concept of a User Profile. I think we'll need to put some deeper thought into what might exist there in the future. Will a config file be sufficient? Don't want to paint ourselves into a corner.

EDIT: What data might exist in a future User Profile? What personalisation would you expect or desire from that?

[NeonDaniel]

At one level - should we architect Mycroft in a way that a single instance could be used in the cloud by thousands of clients. There is a clear need to isolate any and all personal information. The data is merely being processed by some common functions.

This is a bigger question IMO; who controls the assistant and Messagebus connections? Are all of the messagebus connections secured and is the bus isolated such that nobody can listen to traffic, or do the Messages need to be independently encrypted? I think this is out of scope for this discussion, since the other traffic on the bus should be secured/isolated and adding user info would not change this.

At another level imagine multiple people in a household. Is there a single "Mycroft Assistant" that is helping two or more people.

One concept that relates to this that I'm considering is if we have an audio plugin that has speaker identification or something using the camera for face identification. If Mycroft knows who is speaking, it provides options for more/better personalization (Mycroft remembering your name for example).

Either way, in the future this could also enable joint actions

I hadn't thought of that one, but that's a cool concept. I also lean towards the latter because it is also more extensible. For an organization, they could hook that into an exchange server or some other existing calendar system to find meeting times.

Will a config file be sufficient? Don't want to paint ourselves into a corner.

I agree; right now I have profile revisions tied to the neon-utils package, so a skill that requires a newly added parameter requires that newer version of the package. I think data could be stored in any way that it can be read back into a dict, but a config file would be the most logical for a standalone device. For multiple users sharing a device I think we could just save one config file per user, or tie it into a remote database (like a new Selene service?)

What data might exist in a future User Profile? What personalisation would you expect or desire from that?

Everything I use is in this config template: https://github.com/NeonGeckoCom/neon-skill-utils/blob/dev/neon_utils/default_configurations/default_user_conf.yml . Below is a summary of the data we have found useful to save per-user

I broke config into logical sections:

• user contains personal information about the user (name, email, phone, etc)
• speech handles STT/TTS language, voice, and playback preferences
• units contains date/time formatting and unit of measure settings
• location contains location and timezone settings (this can be translated directly from mycroft.conf settings
• response_mode is a Neon set of features to control dialog (skipping the 'one moment..' dialogs, forcing use of the first option in a .dialog file, etc)
• privacy enables/disables local storage of audio and transcriptions (similar to the save_utterances flag in mycroft.conf)
• brands is essentially a leftover section that should move to skill settings for our brands skill