[Enhancement] Check pending requests with command

[peter-strauss]

Pending invitations cannot be listed by calling a command, they are updated randomly after restarting the carrier.

Assuming our own carrier was online and has received an invitation from an other carrier, but the request was not accepted yet, if our own carrier is restarted then the pending requests cannot be listed at once.

[stiartsly]

Currently, all pending friend requests as well as pending invitations are cached in the memory, not cached in the persistence disk. They would be lost only if the carrier restarted. And the other side, when the request nodes restarted, the request (invitation) cookie information (waiting for response) on requester side would be lost too.

Because of decentralized property within carrier, the messaging or communication between two peers would be functional only if both peers are online (or connected to each other). So, from the application perspective, invitation/friend requests receiver or sender can't make sure the invitation is till effective to remote node.

Anyway, it indeed concerns us a lot for a long time. We are trying to figure out a way to resolve this issue if possible to meet your expectation. And we would appreciate it if you put forward your solution.

[peter-strauss]

Is there a specific reason to why pending requests, once received, are not stored on the persistent disk of the receiver until it is either accepted or denied (removed) ?

In case the sent invitation or friend request is not valid anymore, but has been accepted by the user the friend request was sent to previously, could the response to accept the invitation be turned into a friend request, but from the original receiver to the original sender?

For example, User1 sends a friend request to User2, User2 goes online, receives the pending request but does not approve it yet. The pending friend request is then stored on the persistent disk, the User2 goes offline. User1 removes the sent pending request (User2 is removed from friend list). User2 comes online, pending request from User1 is still stored on the persistent disk, then User2 accepts the pending request, User1 is listed as friend of User2. When User1 comes online again, because User2 is not anymore on the friends list, it will show a pending request from User1 to connect.

I believe this is possible with the extension of each requests being validated twice, once on each side, instead of just once by the receiver:
User1 sends request to User2 -> User2 accepts (manually) -> User2 sends second approval request back to User1 -> User1 checks if User2 is still on friend list -> if yes, allow chat, if not, show as pending request.

Would this process be viable?

[stiartsly]

“pending request from User1 is still stored on the persistent disk, then User2 accepts the pending request, User1 is listed as friend of User2. When User1 comes online again, because User2 is not anymore on the friends list, it will show a pending request from User1 to connect.” --》Actually, if User2 accept the pending request and make User1 as friend, it doesn't means User1 would receive a friend request from User2, unless User2 use "ela_add_friend" API to accept pending request.
The other side, the implementation of Tox that we highly rely on is not support it unless we try to amend it with certain modifications.
But, the idea within your suggest is great, which might result a workable solution. Anyway, we have to make out a final solution to resolve this issue, together with "Issue#16: Fix: Resolve issue for adding friends"