When other users are informed in the case of a positive test result (based on a TAN), the current/changed ID should be sent to the servers continuously for some time to notify users that the come close to the current user during infection.
This duration should be limited to e.g. 14 days.
Also, how could this duration be extended by receiving further TANs?
This may be helpful, in particular, when users do not quarantine properly.
Basically, TANs should be used for notifying the servers that an infection has been the case in the last x days. This may also be important throughout the time fighting an infection.
When users are infected they should self quarantine and should not have contact with others. If you would allow a user to upload their infection keys after they got the test result you would open the door to abuse of the system.
Therefore this app and the BLE contact tracing system in general only works retrospectively from the point in time the user receives the test result.
I think you closed this prematurely. It is wrong to assume that after recieving a positive result and entering the result into the app self quarantine will be followed 100%. Two arguments that support this:
1) the current trend of disobeying social distancing
2) the risk, that even on person can spread the virus massivly (see current case in Seoul)
After a positive test and entering it in the app it should be active until the user is tested negative again (2 times?) Then he or she can enter a „recovered” code and this case would be closed as healed. In the meantime his or her contacts should betraced and daily transfered to the server.
So there is an epic concering entering healed status missing as well as epics concdrning continuous transfer of contacts during sickness.
The problem is that the sent IDs are not connected with a specific person (=anonymous). An additional user story does not make sense, as it would only be a copy of a positive test result: Positive test -> IDs are sent to the server
Regarding your thoughts on negative tests: As I said, there is no way to identify which person transmitted the positive IDs (which is the entire point of this infrastructure!). Therefore you can not mark IDs as healed as this would harm the users privacy. According to the DP-3T documents, infection IDs should be deleted automatically after a specific time. If a person is infectious beyond that period, new IDs will be transmitted to the server.
Then you need to clarify your requirements.
In the readme you write
This project has the goal to develop an app based on technology with a decentralized approach - heavily inspired by the DP-3T (Decentralized Privacy-Preserving Proximity Tracing) and TCN protocols and based on the Privacy-Preserving Contact Tracing specifications by Apple and Google.
There is a difference between heavily inspired and following exactly.
So either DP-3T is to be implemented or you need to document now! where you deviate.
Well, they wrote in the readme that their approach is "heavily inspired" by the DP-3T protocol and I never said that they would exactly follow it (I don't know that either; it sounds like you think that I'm associated with SAP, I just want to make clear that I'm just interested in the project and follow the issues in the repo closely 😄 But I don't have anything to do with them!).
However, "heavily inspired" means to me that they will adapt most of the methods defined there, so a expiration time for IDs seems logical to me (!). I referred to the DP-3T protocol specifications as an example on how to resolve this issue, not as a specific claim on how the devs will implement this edge case (I just thought of that approach to be the most reasonable).
I guess we'll see soon enough how they do it when they release the source code, but I still think that they won't (be able to) implement a specific feature for that except a second TAN (e.g. after 14 days) for submitting your IDs and auto-expiring keys because everything else would break the users' privacy, even though there is no point in making any speculations here.
Edit: They just wrote in #69 that they will add more documentation/user stories in the next few days, so maybe this one might(!) be added as well ¯_(ツ)_/¯