Notify about remote ID deletions and ask what to do

[bugith]

When a pair removes my device, or removes my device out of a folder, I should be notified so that I can choose to stop automatically ask him to come back again (i.e. depending on my answer, my device would remove either the pair or only the pair in the folder['s|s'] list (and optionally removes the folder(s) whose pair list is then empty).

[calmh]

The way I could see this working would be something like,

• We remember devices we've deleted (so we don't actually delete them; we just set a flag in the config...)
• We answer with a specific error code when those devices still try to connect to us
• We react to that error code by pausing the device (maybe) and adding a notice to the GUI

[xor-gate]

Sounds like a reasonable solution which is robust and intuitive.

[bugith]

Jakob's idea is good for the device deletion case, but I can't figure how pausing a device will handle the case when this device only removed me out of a share. If one don't want me anymore there, there is no need I go on knocking the door : would it be bad if I got a notification based on the same behaviour/handshake Jakob described above for devices? I.e. either I reply "OK I quit" then the other really removes my flagged entry out of his <folder> section, or I reply "No, I'd rather stay, did you really want to remove me out of here?" : then he gets my question and replies either "Get away!" and I'm forcibly removed on both sides in <folder> section or "Sorry, my mistake" and my flag in its conf is removed.

[calmh]

I don't think this has to interact much with paused folders, it's "just" about a device being removed entirely (no connection desired, ever).

[bugith]

Well Jakob, when I wrote "ID deletions" in the title of this issue I had in mind both device IDs and/or folder IDs only. Okay, for a first thinking let's focus only on device ID deletion, although I've the vague feeling that first dealing with folder ID deletion would be a more general case.

But I see now it is possible I misunderstood the way you propose because in the 3 steps you use "We" and "us" so that I can't well figure where are the differences between the "remover" side and the "removed" side (because I haven't a good understanding of the protocol(s)). Please let me rephrase your post and tell me if I'm wrong, assuming L is my Local device ID, and R is say some friend's Remote device ID that wants no more speak to me in any way "ever", i.e. ASAP and so that I don't automatically knock back (the main reason here is R doesn't like the idea of filling his conf with an unrequired blacklist entry - note here that blacklisting is still wanted for unpolite/rude dev IDs) :

We remember devices we've deleted (so we don't actually delete them; we just set a flag in the config...)

R sets in his config some "delete pending" flag on L. Right? (starting at this time R must still be able to speak to/ear from L but should drop any running sync with L and refuse new - just an idea that could be used elsewhere: maybe adding L ID in .stignore for all and new folders where L would be involved. This would require implementing device IDs in .stignore and cleaning parsing the .stignore files for when the ID is really removed).

We answer with a specific error code when those devices still try to connect to us

Then when R receives a connection attempt from L, R answers back to L with a specific error code. Still right? (kind of "from:R-ID: Remove me!"). Note here that in current development status, devices still try to connect us as they are not aware they are no more welcome: in fact they can't behave in another way as we have completely forgotten them (good point for your "remember" way, no other is possible), so they now are new, and as so behave as new, 101% consistent. This is the reason of this issue.

We react to that error code by pausing the device (maybe) and adding a notice to the GUI

This is the point that puzzles me. If We here is R in my scenario, this means that when the error code is hit at R side (i.e. L is flagged and L connects), R only pauses L and then what? This makes no difference as if R would have directly paused L. Unless not pausing it at first is a way to give a last chance to L to connect a last time?

Instead, if We meant L, L receives this error code from R, then L reacts to this error code by notifying/prompting in L's GUI for either deleting or pausing R. Always right? There, L would send an ack to R before pausing it, so that R can definitively remove L (R replying something like "from:noreply@R-ID : Now removing you", on which reception L deletes R)

If I understood well (that is you said "right" to the 3 points above), now I see R would also need the reply option from L to, either definitively delete both the device and flag (if deletion request was accepted by L), elif, on L replying to R "R paused by delete-pending flagged L" do something else (keep the device flagged for a while until some deadline then...delete?, prompt to add L to some blacklist as for new device?...), elif, (the case when reply was not received at all) R waits for some deadline then removes definitively L.

I find this ... say somewhat complicated for such a simple situation : why not simply send to L on connect an imperative and effective "remove R out of L", then on tcp ack remove L out of R config? So the need to remember in R config that L is delete-pending is mandatory only when an immediate ack from L is not received (L not connected at the moment). If fact we need to remember the delete-pending in RAM until TCP timeout or reply in TCP TTL (hummm hoping R won't crash in the lap time, but it's the usual fate of unsaved data lost on app crash), then (on first event out of tcp timeout and clean quit) write the flag to R config.xml. I don't guess any potential security issue there, as removing a device (here R in L conf) is far less insecure than adding a device in the way the "Introducer" feature can add one.

Further more, a handshake based on notifications in GUI with reply options leaves behind the case when L runs headless or very seldom GUI.

[AudriusButkevicius]

I think you are over thinking something. There is no delete pending or acks or what not. I just remember devices that I have deleted, and tell them to buzz off if they connect, and which points they set me as paused which means they will stop connecting to me and potentially inform the user that I have started refusing them and would they like to remove me. I keep devices I removed (the ones I tell to buzz off) recorded in the config potentially forever.

[bugith]

Hi Audrius
I had a look at my own conf file but I didn't see any list of devices I already deleted. Do you talk about some job you are currently doing?

I keep devices I removed (the ones I tell to buzz off) recorded in the config potentially forever.

I understand that doing a real deletion instead of storing a blacklist would be huge development burden.

[AudriusButkevicius]

This ticket is talking about being notified when other side removes me. To be able distinguish between removal and no prior existance you'd have to store the removed ids somewhere. Currently this does not exist, so I we are speculating of what is needed to make this happen. I am not aware of anyone working on this so nobody is doing any job at the moment.

This ticket is more or less talking about "When I remove X, stop showing me 'X wants to connect with you prompts' which will inevitably happen as the other side will keep connecting".

I am failing to see any benefit of real deletions, apart from complexity and a potential attack surface.

[bugith]

This ticket is more or less talking about "When I remove X, stop showing me 'X wants to connect with you prompts' which will inevitably happen as the other side will keep connecting".

Neither more nor less: this is exactly the subject of this ticket.

I am failing to see any benefit of real deletions

Real deletions, as of current behaviour, keep config light/untainted from storing a blacklit of no longer needed IDs on the long term (for short term relationship standby, Pause is great). Based on a reciprocal collaborative agreement triggered by one side only (like Pause, Introducer & even dropping-files-in-a-share are BTW) and propagating to the other, preferably remove (although Pause the remover at removed side would do the job) it would allow a further seamless collaboration restart (don't have to remember "Oh I remember now I removed this damned-won't-connect ID last year, I have to manually edit my config.xml file to search and figure and delete the blacklisted ID entry" | support forum full of "did you ever deleted this ID before? Check your conf")

potential attack surface

? or just because:

complexity

I can't say less ;-) (see my overthinking).

Don't borrow, I think I have a good feeling of your concerns about growing complexity to push to the ultimate polish. All in all, if I'm fed up with buzzing IDs and don't want to BL them, I just can fire my smoke signal or pick my phone or mail the same way we did when we added each other ID, and tell them to remove me. This is not that often.

Bye man

[acolomb]

Not really a solution to the issue here, but one step toward showing when a remote device does not currently share back a folder we share to them: #8201. Tracking when this condition arises after it had previously been accepted could be implemented on top of that.

That's only for folders not (or no longer) shared from a remote device though, not for remote devices rejecting us overall.