Conversation
|
questions:
notes:
|
iurimatias
force-pushed
the
spec/mutual_contacts
branch
2 times, most recently
from
70755e1 to
9e0736a
Compare
iurimatias
force-pushed
the
spec/mutual_contacts
branch
from
9e0736a to
f3057d2
Compare
| 3. system displays the username of the requester, time of request, and the motivation text for the request | ||
| 4. User accepts contact request | ||
| 4.1 alternative: User rejects contact request | ||
| 5. system makes contact request as accepted or rejected |
There was a problem hiding this comment.
shouldn't it remove the contact request from the list once it's accepted or rejected, how/when does that happen?
There was a problem hiding this comment.
In the Activity Centre, an accepted or rejected contact request should be treated the same way as an @mention message in the Activity Centre that has been read. By this I mean that if the user has selected 'hide read messages' then accepted and rejected contact requests should be hidden, and if the user has selected 'show read messages' then then accepted and rejected contact requests should be displayed
| 2. User fills reason for contact request e.g "Say who you are / why you want to become a contact.." | ||
| 3. User sends contact request | ||
| 4. System notifies user `Contact Request Send` | ||
| 5. System opens A 1 on 1 chat with that user, it displays that a contact request to that user is pending. The user cannot send messages on the 1 on 1 while the request is pending. |
There was a problem hiding this comment.
are there other ways a user can see they have a pending contact request?
There was a problem hiding this comment.
Users will be able to see if they have pending contact requests in:
- the Activity Centre
- The contacts area of the new Settings
| 1. User selects a profile and asks application sends contact request | ||
| 2. User fills reason for contact request e.g "Say who you are / why you want to become a contact.." | ||
| 3. User sends contact request | ||
| 4. System notifies user `Contact Request Send` |
There was a problem hiding this comment.
should there be notifications for a contact request accepted or rejected?
There was a problem hiding this comment.
A user should not be notified if a contact requested they have made is rejected.
But yes we should push a notification if a contact request the user has made is accepted.
There was a problem hiding this comment.
designs for how these notifications should appear IF Status is running and infocus are here https://www.figma.com/file/IPpvkpDWabBKJTeo6bFop0/Kuba%E2%8E%9CDesktop?node-id=2090%3A252386 If Status is not infocus e.g. it's minimized then OS notifications should be used.
| 2. User checks pending contact requests | ||
| 3. system displays the username of the requester, time of request, and the motivation text for the request | ||
| 4. User accepts contact request | ||
| 4.1 alternative: User rejects contact request |
There was a problem hiding this comment.
If the user rejects the contact request, could the sender attempt to send another contact request immediatly?
There was a problem hiding this comment.
No, once a user has said no to a contact request, the same originating user can never send that same user another contact request. But the user who has received the contact request and rejected it, can later go back and change that rejection to an acceptance. They will do this in the new contacts area of settings that will list all the user's rejected contact requests.
| - User A MAY send a contact request to User B containing a message | ||
| - The message for the contact request MUST NOT exceeed 280 characters | ||
| - If User A has sent a contact request they MUST see that the contact request is pending and the message they have sent | ||
| - If User A has sent a contact request they MUST be able to cancel the contact request |
There was a problem hiding this comment.
Could this be a vector to spam an user with contact requests? Could be a good idea to allow the user to reject a contact request and block the sending user immediatly
There was a problem hiding this comment.
It shouldn't be a spam vector because once a user has declined a contact request, the user they declined can never send another contact request to them again. But the user who opted to decline the contact request can change their mind at any point in the future and go back and change their decline to an accept
| - Clicking on this type of activity item MUST open that chat and jump to that message | ||
|
|
||
| ## Notes | ||
|
|
There was a problem hiding this comment.
I don't know if it should be part of the spec, but what happens in the following scenario:
- Alice and Bob are already contacts
- Alice loses her phone, but has the seed phrase, and restores her account in a new mobile device
Since Alice has no way to sync her previous contacts (due to losing her phone), what will happen in this case. Bob already has Alice in his contact list, but Alice will not be able to contact Bob without sending a contact request. The rule in line 59 says that A User CANNOT receive contact requests from users that are already in their contact list
There was a problem hiding this comment.
@richard-ramos very good point, this scenario is the main reason why mutual contacts haven't gone live in Status Mobile yet. The solution to this problem that the mobile team have been working on (and that is now very close to completion) is that every 8 hours (or the next time a Status client goes online if the gap since it was last online was more than 8 hours), every Status client will upload an encrypted backup of the user's state to Waku.
Then if the user looses their phone or their laptop, as long as they login to Status with the same seed phrase within 30 days of the last backup to waku happening, all their user state is automatically restored. One of the beauties of this backup to waku service is that it happens entirely in the background with zero user intervention.
This same mechanism will also kind-of sync any two devices that the user is logged into with the same keys, however we should discourage users from doing this and instead encourage them to set up direct syncing between devices, because syncing multiple devices via 8 hourly backups to waku is a much worse UX with a higher probability of user state change conflicts causing what a user will perceive as unpredictable behaviour.
The initial MVP of this 'back up to waku' mechanism that should be ready soon will only back up mutual contacts to waku. Then after this is live, we will expand the scope of this service to eventually include exactly the same set of user state data that we sync between two devices.
If you have more questions about how this will work, ping Cammellos and he can point you in the right direction.
If user A has blocked user B, then if user B sends a contact request to User A, User A should never see this contact request (even though the contact request was sent). In this scenario, if User A happens to unblock User B in the future, it is at this moment that User A would see that User B sent them a contact request previously. tdlr, the only thing that blocking another user should do is hide everything that user does from the UI of the user who has blocked them. So contact requests should be sent as usual, just if the person a contact request is sent to has already
In our new Settings designs, the user has granularity as to what type of actions result in notifications, see mock below:
|
3 participants
No description provided.