{"action":"created","issue":{"url":"https://api.github.com/repos/siacs/Conversations/issues/1111","labels_url":"https://api.github.com/repos/siacs/Conversations/issues/1111/labels{/name}","comments_url":"https://api.github.com/repos/siacs/Conversations/issues/1111/comments","events_url":"https://api.github.com/repos/siacs/Conversations/issues/1111/events","html_url":"https://github.com/siacs/Conversations/issues/1111","id":66888875,"number":1111,"title":"Fix proposal: Sending files when peer is practically offline, but not yet timed out","user":{"login":"SafwatHalaby","id":5030488,"avatar_url":"https://avatars.githubusercontent.com/u/5030488?v=3","gravatar_id":"","url":"https://api.github.com/users/SafwatHalaby","html_url":"https://github.com/SafwatHalaby","followers_url":"https://api.github.com/users/SafwatHalaby/followers","following_url":"https://api.github.com/users/SafwatHalaby/following{/other_user}","gists_url":"https://api.github.com/users/SafwatHalaby/gists{/gist_id}","starred_url":"https://api.github.com/users/SafwatHalaby/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/SafwatHalaby/subscriptions","organizations_url":"https://api.github.com/users/SafwatHalaby/orgs","repos_url":"https://api.github.com/users/SafwatHalaby/repos","events_url":"https://api.github.com/users/SafwatHalaby/events{/privacy}","received_events_url":"https://api.github.com/users/SafwatHalaby/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":9,"created_at":"2015-04-07T13:52:05Z","updated_at":"2015-05-17T10:46:14Z","closed_at":"2015-05-16T08:23:24Z","body":"When one sends a file to a contact who appears online, but is in fact offline and is yet to timeout, the following scenario always follows:\r\n\r\n- Conversations is -rightfully- unable to tell that the contact is not really online, so it offers them the file, an \"offering\" message appears below the file on the sender's device.\r\n- Since the contact is not really there, the \"offering\" message remains as long as the contact is marked online by the server.\r\n- Once the server decides to timeout the contact, Conversations realizes that the file offer was in vain and the \"offering\" message turns into \"delivery failed\".\r\n- Since the contact is now officially offline and the delivery failed, the file will never arrive, unless the sender long-touches the file and selects \"resend\", in that case, the \"delivery failed\" message is transformed into \"waiting\".\r\n- When the contact is back online, \"waiting\" becomes \"offering\", now this is a genuine file transfer, and the file is transfered successfully. (Unless the contact gets online only very briefly, in that case, the scenario repeats itself).\r\n\r\nSince Conversations works on mobile, and mobile is unreliable, this scenario happens quite often, when a contact's connection is really bad, \"delivery failed\" can appear several times in a row and the user must click re-send numerous times. The average user is expecting a Whatsapp-like \"send-and-forget\", something which Conversations has impressively achieved with text messages. But due to this issue, the user has no guarantee of delivery when it comes to files.\r\n\r\nThere are two things that can be improved here:\r\n- When the receiver disconnects while the sender's Conversations is in the \"offering\" state, the new state should automatically become \"waiting\", it makes no sense to change the state into \"delivery failed\" and force the user to manually re-send the file.\r\n- The \"Offering\" state should be internal. From the user's perspective, the difference between \"waiting\" and \"offering\" is vague and confusing, this is especially true considering the fact that Conversations' design departs away from the Presence feature. Whether Conversations is internally \"waiting\" or \"offering\", the user should only see \"waiting\".\r\n\r\nNote that I am not suggesting that Conversations should always automatically re-send the file when delivery fails, there are numerous cases where it makes sense to not re-send. I am suggesting that Conversations should automatically re-send *only* in the scenario mentioned above (Receiver disconnects while sender is in the \"offering\" state)."},"comment":{"url":"https://api.github.com/repos/siacs/Conversations/issues/comments/102782813","html_url":"https://github.com/siacs/Conversations/issues/1111#issuecomment-102782813","issue_url":"https://api.github.com/repos/siacs/Conversations/issues/1111","id":102782813,"user":{"login":"SafwatHalaby","id":5030488,"avatar_url":"https://avatars.githubusercontent.com/u/5030488?v=3","gravatar_id":"","url":"https://api.github.com/users/SafwatHalaby","html_url":"https://github.com/SafwatHalaby","followers_url":"https://api.github.com/users/SafwatHalaby/followers","following_url":"https://api.github.com/users/SafwatHalaby/following{/other_user}","gists_url":"https://api.github.com/users/SafwatHalaby/gists{/gist_id}","starred_url":"https://api.github.com/users/SafwatHalaby/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/SafwatHalaby/subscriptions","organizations_url":"https://api.github.com/users/SafwatHalaby/orgs","repos_url":"https://api.github.com/users/SafwatHalaby/repos","events_url":"https://api.github.com/users/SafwatHalaby/events{/privacy}","received_events_url":"https://api.github.com/users/SafwatHalaby/received_events","type":"User","site_admin":false},"created_at":"2015-05-17T10:46:13Z","updated_at":"2015-05-17T10:46:13Z","body":"Is this in 1.3.1 or just the dev head?"}}