Thread by @SarahJamieLewis

Metadata resistant app question of the day.

In @cwtch_im, file sharing is done via a torrent-like protocol where the file is chunked & each part can be requested individually (maybe from different people). Only the root hash is initially sent.

How should acks work?

A few caveats:

(2) Is currently implicit in the protocol as all messages are acknowledged

(3) might not always be possible right away (in group contexts) and so requires some extra effort on the recipients end.

Option (3) Also viscerally *feels* like a read receipt to me, even though it isn't necessary (we do allow auto downloading of images e.g.) - and so I think if we went that direction I would feel compelled to make it optional (but then it isn't an ack...)

Also, ack metadata exists regardless in certain contexts.

In a 2-person session if 1 party requests all necessary chunks from another party it can probably be assumed that they have the file.

Same in group contexts if all members of the group fetch all chunks from the sender.

(you could theoretically anonymize those requests, but the overall context of the app makes it functionally pointless)

So really the question becomes - does the recipient have an obligation to tell the sender that they successfully reassembled the file - in the cases where they received chunks from other parties?

There is also a related question regarding sender-side download "progress". In many cases it is extractable from the underlying requests - but as soon as you jump to a group context with rehosting those assumptions are gone.

I don't think there is a correct answer to this, people definitely have different expectations - and maybe it is proper to treat 2-party p2p as functionally different and provide different views over the same data when compared to groups.