Opened 7 years ago

Last modified 5 years ago

#1484 assigned enhancement

I2P-Bote: batching delete packets

Reported by: user Owned by: str4d
Priority: maintenance Milestone: undecided
Component: apps/plugins Version: 0.9.18
Keywords: I2P-Bote Cc:
Parent Tickets: #1483 Sensitive: no


Delete packets should be sent only once the entire mail has been received, and only within a the timeframe of a mail fetching, or immediatelly thereafter.

(irc: from parent ticket, continued)

user: you'd send the deletes only when the user actually logs in, giving more information about the actual user behaviour
user: if, however, you delay the deletes again, then maybe it could be a good idea
user: so deletion must be only once the entire mail is downloaded, not already when one packet downloaded then send deletion for that, in all cases. Then in the half logged in case, once user logs in and decrypts deletion packets for all packets are queueed but only sent when next [or second next - use some randomness] regular mail check is triggered for that identity
<str4d@irc2p> But you're right that it would give more indication of user behavior
<str4d@irc2p> Queuing deletion packets for sending at email checks is a good idea
<str4d@irc2p> Yes
<str4d@irc2p> It does make sense to have all network-touching activity around a single identity occur at the same time
user: and if in the "normal" case, i.e. now, the deletion packets are not sent based on when the single packet was retrieved, but rather the entire mail then this would obscure the user activity a bit
user: because others could not tell whether [the delay in] sending deletion packets was due to user not being logged in, or because of a packet still missing and only being downloaded in a later run
user: it would, however, delete all packets belonging to the same mail at once. Would that be an issue?
user: i think it would also be otherwise wanted behaviour. A user backing up only his keys but not incomplete messages, inbox, sent, etc, should still be able to receive an undelivered mail after restoring from backup
user: were the packets deleted one by one intead of batchwise, this would not be possible anymore, if at least one packet was received already before the restoring

optional enhancement:
scatter the sending of those deletes randomly over the next e.g. 5 mail checking/fetching 'sessions'. This would with standard check interval delay it only by less than 3 hours, but would make it less obvious to infer which packets belonged to which mail. Guess that only makes sense if you scatter-fetch too.


Change History (2)

comment:1 Changed 5 years ago by zzz

Owner: set to str4d
Status: newassigned

comment:2 Changed 5 years ago by str4d

Migrated to - I will close these tickets as things are resolved rather than right now, but please make future comments on GitHub?.

Note: See TracTickets for help on using tickets.