old nicknames confuse users

Bug #467050 reported by Toni Ruottu
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenFilepad
Confirmed
Wishlist
Unassigned

Bug Description

The application supports updating nickname. Some users have the old nickname stored on their disk. A problem rises when such a user tries enters her friends new nickname to friend finder. The friend finder then suggest her old friend with the new nickname and button show. It is unclear what would be the correct behavior here. We should however, atleast make sure she understand they are the same person.

We could probably improve the situation by publishing nicknames of the users. This would however reveal the currently secret nicknames to anyone willing to hack OpenLookup.

We could also allow the local user to set her own aliases to other users and always use her alias instead of the ones published by the other users. This may also cause confusion such as "Why did I find (alias) "Jane", while typing nickname "datagirl" into friend finder?"

Changed in qfriendslol:
milestone: none → 0.1.2
Changed in qfriendslol:
status: New → Confirmed
importance: Undecided → Wishlist
Revision history for this message
Sami Saada (samitheberber) wrote :

My suggestion for this is, that when user updates his/her nick, old nick should be removed. If this users friend has old version of the nick should be removed.

Other solution might be that the value of old nick should be the new nick's name. This nick isn't valid user id, so it would be saved as nick. When the old nick isn't found, it will be removed.

Also one solution might be a nick file. This is slow in search, but maybe it is just for updating friends nick to the newest one.

I'm waiting for some review from these suggestions.

Revision history for this message
Toni Ruottu (toni-ruottu) wrote :

Maybe we should eventually support both local aliases as well as nickname updates. I'll try to sketch it here.

We start storing nickname into OpenLookup with key 'qfriendslol-nickname'. This makes it possible for anyone to retrieve all user nicknames from the data store. We agree that this is insecure, so don't use your social security number as a nickname unless you really want to be identifiable.

Then we start storing local alias for each friend under a path like ~/.qfriendslol/friends/1-e4e8743ffd801b2a126de53607c9ccd383fb71b8/alias or similar. We however never store an alias for ourself, as that makes no sense.

This proposal makes the user interface a bit more complex. There are three places where we currently use nicknames. Friend finder, tab bar, friend view. Let's treat each one of them separately.

Friend finder should show local alias for users who have a local alias set. This allows the users to connect the finder search results to their existing friends, but the finder should also show the finder search term whenever it is different from the local alias. As a result we get something like 'localalias (userid)' e.g. 'Toni Ruottu (cyberix)'. But plain 'cyberix' when there is not local alias defined.

The tab bar should show the local alias only, as we want to keep it short so the tab bar won't expand. Thus the tab bar should use form 'localalias' e.g. 'Toni Ruottu'.

The friend view is hardest. The user interface should be similar to the one that let's users edit their own nick name, but it should be clear to the user that this nick name is just local and cannot be used as a search term by other users (unless we want to go totally mad and implement that, but even so it would raise some additional privacy concerns). We should also probably provide some way of seeing the current nickname set by the user and reverting the local alias to that.

When a user is added we should probably set the local alias to the nickname that was used for that user at the time of addition. This ensures that users don't magically "disappear" or "appear" from local users perspective when someone changes their nickname.

Changed in qfriendslol:
milestone: 0.1.2 → 0.2.1
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.