Get desktop application:
View/edit binary Protocol Buffers messages
Change the first and/or last name for the specified Persona. Last name is not required and if it is not specified then any value currently stored for it will be cleared. The specified Persona must be owned by the caller of this method; clients cannot change Personas that they do not own. The specified PersonaId cannot be a wrapper for an AliasJid; the only way to change the display info for an AliasJid is to change the info for the Genesis Persona directly that the AliasJid maps to.
PersonaInfoService is for mobile to retrieve Personas by PersonaId or lookup PersonaIds by username Mobile calls for setting/updating Persona info are in PersonaService
All the ids from the request that no Persona was found for, or the Persona is not visible to the caller
All the ids from the request that hit an error on the server side Requesting them again may result in the server successfully returning them
All the PersonaFull that were found for the requested ids
All the ids from the request that no Persona was found for Shouldn't happen if you're using valid PersonaId
All the ids from the request that hit an error on the server side Requesting them again may result in the server successfully returning them
persona is only returned if result == OK
Used in:
This result is also returned if the rate limit has been reached
Used in:
Used in:
Currently the only name format supported is first and optional last, but we may support other name formats in the future
Used in:
These first_name, last_name specifications match v1/user_info_shared.proto If any first name or last name is allowed that would be rejected by that protobuf then calls to UserInfo will fail.
Used in:
Some Personas cannot be changed even by their owner, e.g. AliasJid Personas cannot be modified directly because they just map back to the Genesis Persona. Instead the Genesis Persona should be modified directly via its PersonaId.
I don't think we need these codes for now because the only name validation done currently is extra length checking in AccountUtils.isNameValid and the byte length restrictions in here are already more restrictive. However I could see us doing more validation in the future; in fact I'm surprised we don't already check against banned words/phrases or reject URLs