search

qTox / qTox

qTox is a chat, voice, video, and file transfer IM client using the encrypted peer-to-peer Tox protocol.
https://qtox.github.io/
GNU General Public License v3.0
4.71k stars 1.04k forks source link

Usability enhancements for automatic file transfer #5348

Closed sphaerophoria closed 5 years ago

sphaerophoria commented 5 years ago

Recently I let slip that i had the global auto accept file transfer option on to a friend. They immediately started spamming me with new messages trying to fill up my disk. Attempting to disable autoaccept via the friend specific auto accept control didn't work. This got me thinking about the usability of the feature as a whole which I now think has a few potential improvements.

These issues could be filed as separate tickets but I wanted to bring them up together as I'm imagining a bit of an overhaul of the whole autoaccept workflow

I'd like to make the changes myself as an intro to the project, but I'd like to get a go ahead / hash out the details with some current maintainers first.

Current issues

  1. Autoaccept directory grows forever until i run out of disk
  2. Per user control of autoaccept does not work well with the concept of global autoaccept
  3. Having to choose an auto accept directory doesn't have to be done in most other popular chat applications so may be a barrier to entry for a new user
  4. Global autoaccept is not really a good policy in terms of security/usability
    • I don't want to have to go into the settings dialog just so that every time i get an image I don't have to save it somewhere
    • Sure there's a user setting but I don't want to have to set a new autoaccept for every new contact either
    • Just because I trust one user doesn't mean I trust them all. I've seen in the past that some file formats can lead to remote code execution on file preview. If a user is suspicious of a contact they probably don't want to auto accept files from them.
  5. If auto-accept isn't enabled it's a pain to choose a directory for every single file sent from a friend (kind of covered in 4.)
  6. File transfers are not persisted in the chat log
  7. Images are not nice to deal with. There's a tiny image and a large filename when most of the time I would think people want a small filename and a larger thumbnail

Proposal for a new file transfer experience

~~1. Add a rotating cache directory for files in .cache on linux and the equivalent on windows/mac

  1. Remove the concept of a global autoaccept.

    • Prompt on the first file transfer from each user, if the contact is trusted we automatically download to the cache

  2. Remove the concept of an autoaccept dir.

    • Add the concept of "pinning" cached files to avoid them from rotating out of the cache
    • Add a concept of "downloading" a cached file.
      • We can have an option to automatically go to a global downloads folder or pick a location, similar to what browsers do with right-click save-as vs the download api

  3. Add file transfers to the chat log, referencing the cached content. If the cached content is rotated out we can note in the chat log that the file has gone away

  4. Rework UI for presentation of cached files to prioritize image. See Discord/Slack for ideas.~~

  5. Add a default (and possibly configurable) cache directory for files in .cache on linux and the equivalent on windows/mac

    • This should also replace the concept of an "autoaccept" dir and be referred to as a file cache directory. The intent of this folder is not for the user to access files from it directly.
    • If a user wants to keep the file out of the context of history they can "download" (i.e. copy) it to another folder.

  6. Remove the concept of a global autoaccept.

    • Prompt on the first file transfer from each user, if the contact is trusted we automatically download to the cache if the file is < 20MB

  7. Remove the concept of per user autoaccept dirs.

  8. Add a way for users to clean up the cache, maybe through an overhaul of the "File Transfers" view (which in my opinion in it's current state isn't very useful). Requirements are that they can easily delete by size, conversation, and date.

  9. Add file transfers to the chat log, if a file is removed we can still indicate to users that the file transfer was successful but the file is no longer available.

  10. Rework UI for presentation of cached files to prioritize image. See Discord/Slack for ideas.

anthonybilinski commented 5 years ago

I like all the suggestions. A couple things I thought about 1) It would be nice if the file history could be encrypted like chat history is. This would cause problems anytime someone tried to open a file from history (would need to decrypt-on-the-fly to temp, open system program on that copy?). This seems out of scope and your UX improvements don't make this any worse than current state. 2) currently it's possible for users to have a separate file dir per friend, which could be used to structure file transfers. It might be nice to structure the cache the same way. If done so, the contact's hashed public key should be used instead of their public key directly, so that it's not obvious who the friends are just from looking at the directory names, like we do for avatars: https://github.com/qTox/qTox/blob/064dccf8b49212b65c2c114fc87a9226b5ecf518/src/persistence/profile.cpp#L391

sudden6 commented 5 years ago

What improvement would the the concept of "pinning" bring over just downloading stuff from the cache you want to keep longer?

@anthonybilinski encryption would be nice, but I think it's way out of scope here at the moment

About your second point, I fully agree, the hashed PK would make for a nice subdirectory layout.

sphaerophoria commented 5 years ago

@sudden6 ah right I probably didn't make that very clear. I wanted a way for a user to keep a file transfer in chat history. The concept of pinning means that if they scroll back on the conversation later the file will still show up. When downloading we'd have no way to know what they were going to do with it after.

sudden6 commented 5 years ago

So the user would have to actively pin it to not get removed from the chat history? why would that be any different from "downloading" and saving it somewhere you find it again?

sphaerophoria commented 5 years ago

I was imagining a behavior similar to how other chat applications work. On a typical chat application with file transfer there is an on server version of the file that a user could download. What the user does with the downloaded file does not impact the chat log representation of the file because it's still on the server.

The difference for us is we want to allow users to cap file transfer history to avoid filling up their hard disk with useless stuff. This means that we need some way of telling our rotating file storage "hey don't delete this". As you suggest this is very similar to downloading, the difference being that on a downloaded file our database can't know what a user does with the downloaded file. I periodically just smoke my downloads folder on my PC and I wouildn't want that to impact how a chat log in qTox is displayed. Users could download a picture, edit it and send it back. I wouldn't personally want editing a downloaded item to affect my chat history. As a user I see those are two distinct objects.

sphaerophoria commented 5 years ago

Talked with @anthonybilinski about this today and I'm fairly convinced now that a rolling buffer is a bad idea. The thought process here is that other apps just dump stuff into Downloads and let the user deal with it.

I'm still adverse to the idea of using the Downloads folder ourselves though, because I'd say from a user perspective if I smoke my Downloads folder I wouldn't expect my chat history to get corrupted. Instead we came up with the following criteria (or something similar to it)

  1. Users should be able to easily purge file history, sorting by size of download, date of transfer, and conversation
    • This could be implemented with an in-application file transfer view or by sorting output directories and exposing a way to open the native file browser on a per-conversation or global basis
  2. Users should not have to deal with the concept of "downloading" for small files.
    • Consider how other chat applications work. When uploading a file to facebook messenger/discord/slack the idea is that that file will persist for the duration of the chat history. These companies don't want to have to be a file storage service so they cap uploads at something sane like 20MB (at least that's a limit i've hit on occasion)
    • I now think what's reasonable is that in combination with point 1., we auto accept files under 20MB to a cache directory by default. This would still be in combination with the prompt to accept file transfers from a new friend at all. If we trust this friend we prompt for a save location for any file over 20MB or else we just download it.

These amendments to the proposal allow us to remove the concept of pinning, which as @sudden6 suggested is a little confusing. I initially thought it was a good idea since we don't want to accidentally clobber our history, but in practice I think users would never click the "pin" button.

I will edit the original proposal with these changes.

zetok commented 5 years ago

The items that are listed really should be split into separate issues to ease tracking/discussion of them. Creating one huge issue with lots of problems in it results in something that rarely if ever gets to be closed, since usually there is at least one problem that hasn't been discussed/fixed yet, or even worse, good proposals mixed together with bad proposals might be rejected or not acted upon because of bad proposals.

Autoaccept directory grows forever until i run out of disk

Not a problem with qTox, but with your setup – either you didn't allocate enough space for your autoaccept directory, or you're not managing autoaccept directory well enough.

PEBKAC.

Having to choose an auto accept directory doesn't have to be done in most other popular chat applications so may be a barrier to entry for a new user

Nor it has to be chosen in qTox. By default, user doesn't even know about the autoaccept setting, and if user is interested in receiving a file transfer, they're prompted to save it in location default to their file picker.

Global autoaccept is not really a good policy in terms of security/usability

Global autoaccept is not the default setting. The default setting is to prompt user whether to receive a file transfer in the first place.

As for the usability, global autoaccept was added in the first place to address usability problem, so how exactly it is not "a good policy" when it comes to usability? If you want "policy", the sentence above addresses it.

I don't want to have to go into the settings dialog just so that every time i get an image I don't have to save it somewhere

On default settings you don't have to. If you change defaults, it is assumed that you know what you're doing and you're ready to face the consequences.

Sure there's a user setting but I don't want to have to set a new autoaccept for every new contact either

Sounds like the actual usability improvement that you're looking for is ability to mass-select contacts to enable setting for them.

Just because I trust one user doesn't mean I trust them all. I've seen in the past that some file formats can lead to remote code execution on file preview. If a user is suspicious of a contact they probably don't want to auto accept files from them.

Again, on default settings this is not a problem user would face. And if trust only some contacts, by all means, enable autoaccept for those contacts.

If auto-accept isn't enabled it's a pain to choose a directory for every single file sent from a friend (kind of covered in 4.)

Again, it sounds like you want an usability improvement to the feature, and you should make a separate issue for it.

File transfers are not persisted in the chat log

There should be a separate issue for it.

Images are not nice to deal with. There's a tiny image and a large filename when most of the time I would think people want a small filename and a larger thumbnail

Last time I've checked, there was more than one issue for it already.

That's that for the "problems". As there seems to be a misunderstanding of the target audiences, I'll allow myself to generalize them a bit into somewhat separate groups:

And going back to the sad reality we live in, non-technical group of people is still quite often expected to look at the settings and change them to make things work. But lets not talk about it, but instead focus on the core of the problem that a technical user might face that goes like this:

I did everything I could to shoot myself in the foot, and look! I've finally managed to shoot myself in the foot! Clearly, those settings are bad and need to be removed/changed!

It is great when problem in the settings is pointed out. However, the pointed out "problem" has to be a problem. The important thing to remember here is that the greater freedom of choice the greater allowance for the user to shoot themselves in the foot. And some settings inevitably do allow user to shoot themselves in the foot, since otherwise it would not be possible to provide the functionality.

Just like in the case of global autoaccept: there is no way to provide functionality without allowing user to shoot themselves in the foot.

It is also important to note that user can shoot themselves in the foot only if they go out of their way to change the default settings, and non-technical users aren't "affected" whatsoever.

After the problems lets dissect the proposed things next.

  1. Add a default (and possibly configurable) cache directory for files in .cache on linux and the equivalent on windows/mac
    • This should also replace the concept of an "autoaccept" dir and be referred to as a file cache directory. The intent of this folder is not for the user to access files from it directly.
    • If a user wants to keep the file out of the context of history they can "download" (i.e. copy) it to another folder.

Hearing that kind of proposal does make me want to start cursing. And that is because there seems to be no actual thought process behind the proposal, since if there was one, it would have brought up plenty of reasons why it's bad.

Lets start with pointing out that the proposal itself, without even focusing on what it is proposing, is bad. And what it is proposing is even worse.

  1. Remove the concept of a global autoaccept.
    • Prompt on the first file transfer from each user, if the contact is trusted we automatically download to the cache if the file is < 20MB

The global autoaccept was introduced in the first place to remove all the prompts and treat all added contacts as trusted. And you want to remove the feature because you can't use it?

What you propose as a replacement can handle only tiny files, and as for the rest of use cases.. fuck the rest of use cases, am I right? It's not like anyone needs to autoaccept big files.

Not everyone faces the limits you face, not everyone is limited to a tiny 32GB SSD for storing all their data, and there are people who have 200TB Glusterfs Odroid HC2 for their home data storage.

You might find visiting https://old.reddit.com/r/DataHoarder/ educational.

  1. Remove the concept of per user autoaccept dirs.

Same as the point above, except trust is put only in the selected contacts.

  1. Add a way for users to clean up the cache, maybe through an overhaul of the "File Transfers" view (which in my opinion in it's current state isn't very useful). Requirements are that they can easily delete by size, conversation, and date.

No. Don't add unnecessary crap. Users don't need to remove cache. Either you use the cache properly for its intended purposes and users/program can delete it at any time without incurring any loss, or you're doing things wrong. If anything, program itself without any user input should delete unneeded stuff in cache, or delete it periodically.

  1. Add file transfers to the chat log, if a file is removed we can still indicate to users that the file transfer was successful but the file is no longer available.

This is something that I've mentioned at the beginning of my post: this point doesn't belong here. It really should be put in its own issue, to avoid being smeared with dirt and mud along the other points. Lets save it from drowning along with the other points on this sinking ship of an issue.

  1. Rework UI for presentation of cached files to prioritize image. See Discord/Slack for ideas.

From what I remember there already is at least one issue for redesigning UI to prioritize images.

BTW, writing "see $proprietary_app" doesn't really work, since I have no idea how either of the mentioned by you proprietary apps look like, and how they might look like in context of transferring images. Instead, it's better to write what sort of redesign would you want, or even better yet, create a mock-up for the redesign so that people could see what you have in mind.

Anyhow. There's more to write, but writing all the above was rather tiring.

The general idea of downloading small files from trusted contacts to a temporary place before user puts it in their desired directory sounds like a good idea. The temporary dir can't be a cache though, since cache is not fit for the purpose. A subdirectory in IIRC from the spec $XDG_DATA_DIR is more appropriate. This however should be placed in its own issue, and this one should be most likely closed after being separated into its own issues, if there is still something that needs to be addressed.

If there is a need to create issue about bigger changes, creating smaller issues for each "point" + metaissue tracking completion of the smaller issues are probably a better choice.

sudden6 commented 5 years ago

Autoaccept directory grows forever until i run out of disk

Not a problem with qTox, but with your setup – either you didn't allocate enough space for your autoaccept directory, or you're not managing autoaccept directory well enough.

No, this can happen with the current implementation, be it on accident or intentionally by the other contact and this should be solved. Limiting the auto-accept size per user/globally is a very sensible thing.

Having to choose an auto accept directory doesn't have to be done in most other popular chat applications so may be a barrier to entry for a new user

Nor it has to be chosen in qTox. By default, user doesn't even know about the autoaccept setting, and if user is interested in receiving a file transfer, they're prompted to save it in location default to their file picker.

I think making qTox remember the last folder from this contact is a good candidate to move into another issue.

I don't want to have to go into the settings dialog just so that every time i get an image I don't have to save it somewhere

On default settings you don't have to. If you change defaults, it is assumed that you know what you're doing and you're ready to face the consequences.

On default settings you have to choose the directory where to save to every time, not nice. I agree with @sphaerophoria that this is quite annoying and should be replaced with a different workflow.

Sure there's a user setting but I don't want to have to set a new autoaccept for every new contact either

Sounds like the actual usability improvement that you're looking for is ability to mass-select contacts to enable setting for them.

I think this is the core problem, on one hand we can't really auto-accept from every new friend by default, on the other hand enabling it is cumbersome at the moment. My solution to this would be to prompt the user if they want to enable auto-accept for a particular friend when they first receive a file transfer.

There should be a separate issue for it.

Already done and #5354 implementing it is ready for testing.

About the location being a "cache" directory, I agree with @zetok a cache is not meant to be persistent and storing user data parts of the history there will result in data loss sooner or later.

EDIT: @zetok referencing a subreddit consisting only of people trying to amass as much storage as possible for an issue of running out of storage is quite ridiculous don't you think?

zetok commented 5 years ago

Autoaccept directory grows forever until i run out of disk

Not a problem with qTox, but with your setup – either you didn't allocate enough space for your autoaccept directory, or you're not managing autoaccept directory well enough.

No, this can happen with the current implementation, be it on accident or intentionally by the other contact and this should be solved. Limiting the auto-accept size per user/globally is a very sensible thing.

Limiting auto-accept size in qTox (as a user-adjustable setting) does sound sensible. But it does lead to more problems to solve. And it also sounds like something that a separate issue should be made for :)

I don't want to have to go into the settings dialog just so that every time i get an image I don't have to save it somewhere

On default settings you don't have to. If you change defaults, it is assumed that you know what you're doing and you're ready to face the consequences.

On default settings you have to choose the directory where to save to every time, not nice. I agree with @sphaerophoria that this is quite annoying and should be replaced with a different workflow.

I think that perhaps we should go for something resembling what browsers do, as they handle most of user-saved files and everyone is used to the browser behaviour. The 2 most popular browsers out there by default download files into "Downloads" directory. Also, as this issue is about cache, separate issue should be made for it.

EDIT: @zetok referencing a subreddit consisting only of people trying to amass as much storage as possible for an issue of running out of storage is quite ridiculous don't you think?

No, I find it perfectly reasonable? The issue is running out of storage, and you fix it by adding more storage. Either you trust all your contacts to not flood you with data, or you don't enable global autoaccept. Or, like some people, you can simply say "Good Luck" to people trying to flood you with data.

sphaerophoria commented 5 years ago

Alright I'll do my best to try to explain myself a little more thoroughly since I feel like the intent of what I was getting at was a little missed. My intent here is to make the default behavior less of a pain to prevent barrier to entry. In it's current state sharing images back and forth with a friend is a PITA and every friend I've talked to on the application has an initial "wtf" moment asking me why it is this way. With that in mind the goal here is to make default behavior more user friendly without compromising security.

The items that are listed really should be split into separate issues to ease tracking/discussion of them.

I agree, but I was concerned that if we discussed each item individually we would come to a different conclusion then if we discussed the feature as a whole. Once we hash out the bigger picture and make sure we're on the same page in terms of direction for file transfers as a whole I'll split off tickets for the approved solutions implementations.

PEBKAC.

In some way yes, you're right a user should be able to manage their own storage, but on the other hand we could also help mitigate the problem. Just because the situation is user managed now doesn't mean it has to be.

Nor it has to be chosen in qTox. By default, user doesn't even know about the autoaccept setting, and if user is interested in receiving a file transfer, they're prompted to save it in location default to their file picker.

The default behavior is that on every image (which are frequent in my chats at least) they have to open a download file picker and choose where to save the file. If I don't want to go through that process for every image my options are currently

  1. Choose auto accept directory for each user
  2. Enable global auto accept

What i'm proposing is that those features are both not really what most non-technical users would want. My thought process here was that I want some intuitive way to not have to deal with it and have it just work. My experience with my isolated sample of qTox users is that they don't want to have to accept every file manually and they don't even know about the auto accept options. I think my proposal of prompt per-user is much more in line with what I (or my friends) would expect.

Global autoaccept is not the default setting. The default setting is to prompt user whether to receive a file transfer in the first place.

My argument is that with global autoaccept off usability sucks and with global autoaccept on security sucks (as I may have untrusted friends). Manually selecting autoaccept dirs per friend is also non-intuitive. Basically I think we can come up with something better.

Again, on default settings this is not a problem user would face. And if trust only some contacts, by all means, enable autoaccept for those contacts.

Same as above

Again, it sounds like you want an usability improvement to the feature, and you should make a separate issue for it.

This is the usability improvement issue.

I did everything I could to shoot myself in the foot, and look! I've finally managed to shoot myself in the foot! Clearly, those settings are bad and need to be removed/changed!

Don't you think we should try to help users not shoot themselves in the foot? I personally would prefer that the programs I use help me avoid getting into undesirable states.

Just like in the case of global autoaccept: there is no way to provide functionality without allowing user to shoot themselves in the foot.

I think what I've proposed is at least closer.

Hearing that kind of proposal does make me want to start cursing. And that is because there seems to be no actual thought process behind the proposal, since if there was one, it would have brought up plenty of reasons why it's bad.

Seems a little harsh no? Just because I came to a different conclusion than you have doesn't mean I haven't thought about it. It's possible I didn't phrase my intentions well enough but to tell a new contributor that their idea is so bad that they must be stupid just because you don't agree with them seems like a good way to push new contributors away.

Since when the cache directory was not configurable, and how exactly do you plan to reinvent that wheel by possibly making it configurable? Or do you want to ignore the fact that it is already configurable and instead add fifth wheel to the cart by providing an option to configure already configurable thing also in qTox settings? This almost asks for its own version of "Yo dawg" meme.

My thoughts were to use XDG_CACHE_DIRECTORY by default but maybe expose it to the user since there coudl be a lot of data going in there there's a chance a user would want to specify a devoted tox directory. I don't think that's unreasonable. Also the reason it was bolded was because I was leaning away from the configurable option and just presenting it in case other people thought it was a better idea.

Do you know what a cache directory is for?

I thought this was clear but maybe not. I'm suggesting that images in the context of a conversation eventually should be discarded by default. I don't think it's unreasonable to think that a user might want their image history to go away at some point. Throughout my proposal I referenced the cached files getting removed at some point (either automatically or by the user themselves). I've used other chat applications in the past where file uploads get clobbered eventually (xmpp with http upload some servers for example) and that hasn't really caught me off guard.

I could be convinced that this should be a more persistent directory but I was thinking that it would be viewed as only semi-permanent data since my other points discussed how we would manage the data in the cache to avoid it growing forever.

So what you are proposing is creation of data that from user point of view is useless and only takes lots of disk space for no good reason (it would at a proper scale). All in the name of reducing disk usage. How does that make sense?

I'm thinking similar to how browsers work. When you have an "open file" dialog in firefox it's not expected that the user will ever go digging through the tmpfiles to open it themselves, they let firefox open it for them. For us it would be qtox showing images in file transfer history with the option to download for user use later. The idea being

  1. Chat log is preserved
  2. Easy clean up later, just smoke the cache directory and any files you cared about keeping you will have downloaded to access anyways. Imagine the workflow of sending a document back and forth with a friend. The friend will download it to a Downloads folder as well as the cache directory, modify it, and send it back. In this case in chat history you might still want each document in history and a user might be confused that modifying their Downloaded copy seemingly changes what was sent to them.

What you propose as a replacement can handle only tiny files, and as for the rest of use cases.. fuck the rest of use cases, am I right? It's not like anyone needs to autoaccept big files.

How often are you wishing that someone can drop a 10G file on your computer without you knowing about it. I agree it is a bit of a restriction but it seems like a reasonable default to me. We could add a configurable max file size to allow users to keep using it in the way you're suggesting.

BTW, writing "see $proprietary_app" doesn't really work, since I have no idea how either of the mentioned by you proprietary apps look like, and how they might look like in context of transferring images. Instead, it's better to write what sort of redesign would you want, or even better yet, create a mock-up for the redesign so that people could see what you have in mind.

I think prior art is a completely reasonable thing to reference when discussing UI decisions. I'm flushing out the design decisions at a high level and would split off a ticket for more precise work on our particular UI. For the time being I'm referencing other chat applications so people have a reasonable grasp of the direction I am proposing.

sphaerophoria commented 5 years ago

I think that perhaps we should go for something resembling what browsers do, as they handle most of user-saved files and everyone is used to the browser behaviour. The 2 most popular browsers out there by default download files into "Downloads" directory. Also, as this issue is about cache, separate issue should be made for it.

Yeah I was originally considering something similar to browsers but browsers also locally cache images and display them inline so we're in a bit of a grey area. I think there's a good use case for not prompting for some metric of small files but still prompting for big ones similar to how browsers do it.

sudden6 commented 5 years ago

I think prior art is a completely reasonable thing to reference when discussing UI decisions.

This is fine, but the program/thing you reference may not be familiar to us :) (Like discord to me) So it's probably better to include a screenshot/short video of the thing to avoid any misunderstandings.

zetok commented 5 years ago

Alright I'll do my best to try to explain myself a little more thoroughly since I feel like the intent of what I was getting at was a little missed. My intent here is to make the default behavior less of a pain to prevent barrier to entry. In it's current state sharing images back and forth with a friend is a PITA and every friend I've talked to on the application has an initial "wtf" moment asking me why it is this way. With that in mind the goal here is to make default behavior more user friendly without compromising security.

No, the intent wasn't lost, but it was mixed in with a lot of things that weren't good. At the end of my first post I did write that the generic idea behind the proposal sounds good.

PEBKAC.

In some way yes, you're right a user should be able to manage their own storage, but on the other hand we could also help mitigate the problem. Just because the situation is user managed now doesn't mean it has to be.

That depends on the kind of data that is being managed.

File transfers are user data. And user data is holy. qTox doesn't delete user data, unless user goes into settings and explicitly confirms that the data should be removed after disabling history. Even then it only happens upon user action and nothing is being done automatically without prior "request" from the user. Same goes for the file transfers, and with them situation is even better: qTox doesn't delete them at all. User can access and manage received files with software that was made for this particular purpose (file manager) and most likely will provide a lot better experience for the user than qTox can.

If it was about something other than user data, then why not, doing whatever with it as long as it's helpful would be fine.

Nor it has to be chosen in qTox. By default, user doesn't even know about the autoaccept setting, and if user is interested in receiving a file transfer, they're prompted to save it in location default to their file picker.

The default behavior is that on every image (which are frequent in my chats at least) they have to open a download file picker and choose where to save the file. If I don't want to go through that process for every image my options are currently

1. Choose auto accept directory for each user

2. Enable global auto accept

What i'm proposing is that those features are both not really what most non-technical users would want. My thought process here was that I want some intuitive way to not have to deal with it and have it just work. My experience with my isolated sample of qTox users is that they don't want to have to accept every file manually and they don't even know about the auto accept options. I think my proposal of prompt per-user is much more in line with what I (or my friends) would expect.

This in itself would be good, but in conjunction with other proposed points the result is bad.

And the thing is, other proposed points aren't needed to make this work with slight changes.

Global autoaccept is not the default setting. The default setting is to prompt user whether to receive a file transfer in the first place.

My argument is that with global autoaccept off usability sucks and with global autoaccept on security sucks (as I may have untrusted friends). Manually selecting autoaccept dirs per friend is also non-intuitive. Basically I think we can come up with something better.

The key point is actually coming up with something better that would cover the use case. You proposed removing a feature without providing a replacement.

If the usability of default file transfers sucks, then this should be focused on and improved. Trying to involve in that autoaccept doesn't seem necessary.

Again, it sounds like you want an usability improvement to the feature, and you should make a separate issue for it.

This is the usability improvement issue.

Not quite. It would have been an usability improvement issue had the feature removal not been proposed. As it is, it's an issue about removing feature and instead providing something that will result in loss of user data.

I did everything I could to shoot myself in the foot, and look! I've finally managed to shoot myself in the foot! Clearly, those settings are bad and need to be removed/changed!

Don't you think we should try to help users not shoot themselves in the foot? I personally would prefer that the programs I use help me avoid getting into undesirable states.

Just like in the case of global autoaccept: there is no way to provide functionality without allowing user to shoot themselves in the foot.

I think what I've proposed is at least closer.

You're proposing removing a feature rather than helping to prevent user from shooting themselves in the foot.

Hearing that kind of proposal does make me want to start cursing. And that is because there seems to be no actual thought process behind the proposal, since if there was one, it would have brought up plenty of reasons why it's bad.

Seems a little harsh no? Just because I came to a different conclusion than you have doesn't mean I haven't thought about it. It's possible I didn't phrase my intentions well enough but to tell a new contributor that their idea is so bad that they must be stupid just because you don't agree with them seems like a good way to push new contributors away.

Yes, it might sound a bit harsh. But only if you haven't come in contact with the original :)

Coming to a different conclusion doesn't mean that you haven't thought about something, but it might indicate that there was not enough thought put into it and/or input data might have been insufficient. While quite often not much can be done about the latter, it's possible to fairly easily improve on the former.

Whenever I want to propose something, after writing proposal I quite often take some time away from it (at least 5-15 min) to do some other, unrelated stuff. After growing a bit distant to it and coming back to look at it again, I would ask myself a question: Why is my proposal shit?

Asking yourself this question can be quite helpful.

So lemme ask you: have you asked yourself why is your proposal shit?

It's possible I didn't phrase my intentions well enough but to tell a new contributor that their idea is so bad that they must be stupid just because you don't agree with them seems like a good way to push new contributors away.

I think that there's a communication issue here. The way I see it, in no way lack of thought process behind some action(s) indicates that the person is incapable of the said thought process.

Perhaps it's a poor analogy, but: if someone didn't brew the tea, does that mean that they're incapable of brewing the tea?

Originally, I considered writing "Hey. Did you turn off your brain there for a moment? Could you turn it back on?" which does convey a lot better that I don't consider your intelligence to be lacking, but that sentence seemed too harsh, so I went with the less harsh, albeit not as clear message.

Do you know what a cache directory is for?

I thought this was clear but maybe not. I'm suggesting that images in the context of a conversation eventually should be discarded by default. I don't think it's unreasonable to think that a user might want their image history to go away at some point. Throughout my proposal I referenced the cached files getting removed at some point (either automatically or by the user themselves). I've used other chat applications in the past where file uploads get clobbered eventually (xmpp with http upload some servers for example) and that hasn't really caught me off guard.

I could be convinced that this should be a more persistent directory but I was thinking that it would be viewed as only semi-permanent data since my other points discussed how we would manage the data in the cache to avoid it growing forever.

Well, the received files are user data, about which I wrote above.

If I receive some data I would expect the data to be there the next time I look for it. If it were to suddenly disappear without my explicit action it would really throw me off, possibly pissing me off quite badly, depending on the importance of the data.

So what you are proposing is creation of data that from user point of view is useless and only takes lots of disk space for no good reason (it would at a proper scale). All in the name of reducing disk usage. How does that make sense?

I'm thinking similar to how browsers work. When you have an "open file" dialog in firefox it's not expected that the user will ever go digging through the tmpfiles to open it themselves, they let firefox open it for them. For us it would be qtox showing images in file transfer history with the option to download for user use later. The idea being

1. Chat log is preserved

2. Easy clean up later, just smoke the cache directory and any files you cared about keeping you will have downloaded to access anyways. Imagine the workflow of sending a document back and forth with a friend. The friend will download it to a Downloads folder as well as the cache directory, modify it, and send it back. In this case in chat history you might still want each document in history and a user might be confused that modifying their Downloaded copy seemingly changes what was sent to them.

Again, it's about dealing with user data.

The moment the file shows in the chat as available, it is something that users will expect to be permanent, just like message history. Unless they manually (re)move the file with a separate program made for the purpose (file manager).

And since data is to be permanent ever since the moment it was received, it doesn't make sense to store the same data in more than 1 place.

Why would the user be confused about the data that they've modified being modified? If anything, confusion is another argument against the cache, since without it user isn't mislead into thinking that there are backups of the data.

User history doesn't imply and shouldn't imply that it contains received/sent files; it should clearly signal that it's only a list of received/sent files. Browsers do that and it seems to work just fine?

What you propose as a replacement can handle only tiny files, and as for the rest of use cases.. fuck the rest of use cases, am I right? It's not like anyone needs to autoaccept big files.

How often are you wishing that someone can drop a 10G file on your computer without you knowing about it. I agree it is a bit of a restriction but it seems like a reasonable default to me. We could add a configurable max file size to allow users to keep using it in the way you're suggesting.

First of all, no file transfer should be done without user knowledge. User should always be notified about the file transfer, regardless of whether it is autoaccepted or just waiting to be received.

As for the file size – why, yes, I can think of plenty use cases where I would want to enjoy the luxury of being able to automatically receive huge files from added contacts; forget about 10GB, 25-50GB is the size range of files I would want to receive. But the sad reality is that currently file transfers in tox don't satisfy the speed and stability requirements. That being said, on LAN I did manage to transfer ~500GB file with tox, but it wouldn't really have worked over public internet. At least not yet, and there's no good reason to introduce artificial limitations in the client. I do plan to enjoy transferring bigger files with tox over public internet one day.

sphaerophoria commented 5 years ago

Alright there's a ton of text here and just to make sure we haven't crossed wires while talking I'll do my best to summarize current state of discussion

@zetok would you say that this is an accurate representation of current state of discussion?

Now that that's layed out I can try to address each one

zetok commented 5 years ago

Yeah, those are more or less the main points.

  • Removing global autoaccept with no replacement is bad

    • I'm arguing that the whole feature is not a good one and usability would be just as good with an autoaccept prompt from each user. Once we've approved autoaccept for a user it should behave almost as it did before except with a user configurable cap on max autoaccept size. The autoaccept flag would then just become extra state to manage with little benefit.

You're repeating what was written before with different wording and adding that the benefits brought by global autoaccept aren't significant enough to care about them. You're missing the point.

For plenty of users this would work. But "plenty" doesn't mean "all". And by insisting on removing global autoaccept you're neglecting the use cases where it's a perfect fit for the job, and there's no proper replacement available.

The core points of global autoaccept are:

Proposed change only can carter to the second point, but is at the opposite of the first point, since the core of change is prompting the user. Yes, proposal is about limiting amount of "prompts", but it still revolves around prompting.

Perhaps contrary to the expectations, global autoaccept from my point of view is a lot more useful for the non-technical group of users, even being a perfect fit in certain cases. And the proposed change is inherently incompatible with the use case that global autoaccept carters for.

  • The idea of duplicating data from the chat log files is stupid

    • So I do think this is actually confusing. In most chat clients the file transfer is preserved on the server in it's current form. If I download and modify something from a chat client it's still preserved in history for both people as it was at the time of transfer. I was thinking that file transfers in qTox should behave the same way, as a user I would be confused if my chatlog changed over time because I hit save on a file in my Downloads folder. I see where you're coming from that a user should understand that the thing they downloaded is where they put it, and modifications of course modify it, but I'm arguing that in the context of a chat application showing inline images that distinction may not be clear especially if they have enabled autoaccept for that transfer.

There are quire a few things mixed together in this, so to address them I've split it up.

In most chat clients the file transfer is preserved on the server in it's current form. If I download and modify something from a chat client it's still preserved in history for both people as it was at the time of transfer. I was thinking that file transfers in qTox should behave the same way, (…)

You're assuming that people wouldn't see the difference between qTox and other chat programs that were made to work in client↔server setup. This assumption is wrong, as quite often people do see the difference and are confused when there is introduced interface that even remotely resembles some stuff from other client↔server chat applications. Case in point: "login" page. Introducing profile loading page where one could type in password made people think that qTox required logging in to some remote server. Changing stuff to make profile selection page look more like "loading local save file" rather than "login into a remote service" helped to clear some confusion, but it never really felt like all the confusion was dealt with.

The simplest solution to the confusion problem is: don't introduce stuff that creates it, unless it is absolutely necessary to make the core functionality work.

In case of profile load page the core functionality was providing GUI for selecting/creating encrypted profiles.

Making file transfers behave like in some, but not all(!), client↔server chat applications would create confusion. It also would create additional problems, further confusing users.

The simplest solution is applicable here: Don't.

(…) as a user I would be confused if my chatlog changed over time because I hit save on a file in my Downloads folder.

Well, the simplest solution is applicable again: don't change the changelog.

qTox doesn't need to, and shouldn't even try to make sure that there's an immutable version of the received files. That's not qTox's job. By offering this in some cases but not in other you're only creating more confusion and uncertainty, and in the end you're also failing to achieve the goal of not changing the chatlog, since you're proposing to change it at any time, at any whim, regardless of user's wishes.

File contents are not a part of the chatlog and pretending that they are only introduces more problems.

How does not changing the chatlog fit in with not providing immutable files? Quite well, as long as you inform user that qTox can e.g. display the image only as long as it has not been modified.

In case where file has been modified/moved, qTox should clearly signal that it no longer can display the originally received file. People are familiar with this. Internet is full of no longer displayed/missing images. Of course, the file transfer should be displayed in the log, but without displaying the contents of the file, even if a modified file exists.

This not only fixes problem with confusion. Arguably, it might even be considered to be an educational service where one gets to experience what happens when they're working on the original files without backing them up first and then they don't have the original data when they need it. A valuable lesson when it comes to computing has been learned. You're welcome.

I see where you're coming from that a user should understand that the thing they downloaded is where they put it, and modifications of course modify it, but I'm arguing that in the context of a chat application showing inline images that distinction may not be clear especially if they have enabled autoaccept for that transfer.

Check if image is the originally received one → if yes display, otherwise inform about the change and don't display the contents.

sphaerophoria commented 5 years ago

You're repeating what was written before with different wording and adding that the benefits brought by global autoaccept aren't significant enough to care about them. You're missing the point.

Yes. I believe this is how discussions usually work. Since there was this 10 page wall of text between last time I outlined my position and now I figured it's good to reiterate. Then I add information that I thought may not have been clear before in order to try to change your opinion.

Proposed change only can carter to the second point, but is at the opposite of the first point, since the core of change is prompting the user. Yes, proposal is about limiting amount of "prompts", but it still revolves around prompting.

We can cater almost all the way to the first point. If we allow users to set a "small file limit" of unlimited each whitelisted conversation will have autoaccept for any file in that conversation. The only difference is that there would be one popuup per conversation. The marginal decrease in usability for the usecase where you're adding a ton of friends and want them to be able to send you files seems heavily outweighed by the fact that if I add one untrusted friend they could start polluting my hard disk with viruses. There are exploits that can be triggered just by opening a file browser with a certain file in it and I think it's reasonable to protect users from accidentally getting themselves in that position as best we can. The popup for turning on autoaccept would lay out the potential security threats and ensure that the user considers whether or not they trust the person they're talking to.

I would consider leaving the autoaccept in with a giant warning when you click it, but even then it's more state we could mismanage. The feature is already broken (doesn't play nicely with per-user autoaccept) and I personally don't want to put in effort to fix it since I think it's a bad idea in the first place.

Perhaps contrary to the expectations, global autoaccept from my point of view is a lot more useful for the non-technical group of users, even being a perfect fit in certain cases. And the proposed change is inherently incompatible with the use case that global autoaccept carters for.

"more useful"? How? One button press per user with the caveat that you can't ever add an untrusted friend. Even technical users can easily make that mistake.

You're assuming that people wouldn't see the difference between qTox and other chat programs that were made to work in client↔server setup. This assumption is wrong, as quite often people do see the difference and are confused when there is introduced interface that even remotely resembles some stuff from other client↔server chat applications. Case in point: "login" page. Introducing profile loading page where one could type in password made people think that qTox required logging in to some remote server. Changing stuff to make profile selection page look more like "loading local save file" rather than "login into a remote service" helped to clear some confusion, but it never really felt like all the confusion was dealt with. Check if image is the originally received one → if yes display, otherwise inform about the change and don't display the contents.

Whether or not it's different, I think it makes for a more usable chat program if more accurate history is preserved. I like the idea of hashing the orignial file and storing it in the DB, but I still think it's even better if we can have a consistent conversation history.

qTox doesn't need to, and shouldn't even try to make sure that there's an immutable version of the received files. That's not qTox's job. By offering this in some cases but not in other you're only creating more confusion and uncertainty, and in the end you're also failing to achieve the goal of not changing the chatlog, since you're proposing to change it at any time, at any whim, regardless of user's wishes.

Why not? If we have data that's part of our application (chatlog), isn't it sane to try to enforce rules on how it should be used? Isn't that why file attributes exist?

File contents are not a part of the chatlog and pretending that they are only introduces more problems.

I think we fundamentally disagree here. Conversations are frequently had in the context of file transfer data. The file transfer is part of the conversation. Trying to preserve that as best we can seems pretty reasonable to me.

sphaerophoria commented 5 years ago

Misclicked close button, reopening.

zetok commented 5 years ago

You're repeating what was written before with different wording and adding that the benefits brought by global autoaccept aren't significant enough to care about them. You're missing the point.

Yes. I believe this is how discussions usually work. Since there was this 10 page wall of text between last time I outlined my position and now I figured it's good to reiterate. Then I add information that I thought may not have been clear before in order to try to change your opinion.

If the discussion is intended to convince one or more parties in the discussion, rather than repeating already used arguments one should provide new, hopefully better arguments.

And the new argument you've used is that you see little benefit in keeping global autoaccept.

Proposed change only can carter to the second point, but is at the opposite of the first point, since the core of change is prompting the user. Yes, proposal is about limiting amount of "prompts", but it still revolves around prompting.

We can cater almost all the way to the first point. If we allow users to set a "small file limit" of unlimited each whitelisted conversation will have autoaccept for any file in that conversation. The only difference is that there would be one popuup per conversation. The marginal decrease in usability for the usecase where you're adding a ton of friends and want them to be able to send you files seems heavily outweighed by the fact that if I add one untrusted friend they could start polluting my hard disk with viruses. There are exploits that can be triggered just by opening a file browser with a certain file in it and I think it's reasonable to protect users from accidentally getting themselves in that position as best we can. The popup for turning on autoaccept would lay out the potential security threats and ensure that the user considers whether or not they trust the person they're talking to.

You're not getting this point:

I would consider leaving the autoaccept in with a giant warning when you click it, but even then it's more state we could mismanage. The feature is already broken (doesn't play nicely with per-user autoaccept) and I personally don't want to put in effort to fix it since I think it's a bad idea in the first place.

Just because you can't use the feature, it doesn't mean it's broken. It works perfectly for what it was intended to do.

Perhaps contrary to the expectations, global autoaccept from my point of view is a lot more useful for the non-technical group of users, even being a perfect fit in certain cases. And the proposed change is inherently incompatible with the use case that global autoaccept carters for.

"more useful"? How? One button press per user with the caveat that you can't ever add an untrusted friend. Even technical users can easily make that mistake.

Not everyone faces the limits you face, not everyone has to have untrusted contacts, and not everyone wants to deal with shitty prompts that aren't necessary to get things done.

You're assuming that people wouldn't see the difference between qTox and other chat programs that were made to work in client↔server setup. This assumption is wrong, as quite often people do see the difference and are confused when there is introduced interface that even remotely resembles some stuff from other client↔server chat applications. Case in point: "login" page. Introducing profile loading page where one could type in password made people think that qTox required logging in to some remote server. Changing stuff to make profile selection page look more like "loading local save file" rather than "login into a remote service" helped to clear some confusion, but it never really felt like all the confusion was dealt with. Check if image is the originally received one → if yes display, otherwise inform about the change and don't display the contents.

Whether or not it's different, I think it makes for a more usable chat program if more accurate history is preserved. I like the idea of hashing the orignial file and storing it in the DB, but I still think it's even better if we can have a consistent conversation history.

You're not proposing to accurately preserve the history. Your proposal is about breaking consistency of history and making it uncertain for users what is happening to the data, while you're pretending that you're preserving something.

qTox doesn't need to, and shouldn't even try to make sure that there's an immutable version of the received files. That's not qTox's job. By offering this in some cases but not in other you're only creating more confusion and uncertainty, and in the end you're also failing to achieve the goal of not changing the chatlog, since you're proposing to change it at any time, at any whim, regardless of user's wishes.

Why not? If we have data that's part of our application (chatlog), (…)

No. The data isn't a part of the application. It's user data. qTox provides a friendly UI for interacting with history data because it's too hard to interact with it for almost all users without UI for it in qTox.

(…) isn't it sane to try to enforce rules on how it should be used? Isn't that why file attributes exist?

No. Enforcing how user data should be used is batshit insane.

File attributes being read, write, executable/enter, uid, gid? No. They're there to provide for the user control over how they want the data to be managed. Not the other way around. (Actually, this was written having any sane FOSS system in mind – it might be possible that it doesn't hold true on systems that restrict user freedom.)

File contents are not a part of the chatlog and pretending that they are only introduces more problems.

I think we fundamentally disagree here. Conversations are frequently had in the context of file transfer data. The file transfer is part of the conversation. Trying to preserve that as best we can seems pretty reasonable to me.

File transfer is a part of the chatlog. File contents aren't. Nothing is stopping you from preserving file name, size, hash and date when it was sent/received.

If you want to preserve file contents like you claim, you should preserve them all, since there's no good reason to be inconsistent with only some data being preserved while other isn't. That is the best that can be done.

What you're proposing is broken by design.

Once upon a time there was a proposal to introduce a broken by design "feature" in qTox. It was implemented and people tried to use it.

Feel free to guess why the broken by design "feature" is not available anymore.

sudden6 commented 5 years ago

First the meta thing, as far as I know it is good discussion culture to try and summarize the state of the discussion every now and then, to make sure everybody has the same understanding of the topic and to avoid misunderstandings.

So now lets get on with the discussion.

There seems to be two distinct, but interlinked points here:

I will now try to summarize the opinions of @zetok and @sphaerophoria and add my own.

How should the file accept work

According to @zetok it should stay the way it is. No files are auto accepted by default. The user can enable autoaccept globally or on a per user basis.

According to @sphaerophoria small files (limit to be defined) should be automatically downloaded by default to a "cache" location. Larger files would still need to be accepted manually on ever transfer.

I think the global autoaccept is broken, because if you enable it you have to trust every user in your contact list. This includes bots, which would be a number one target for an attack to distribute malicious files, because of their high user count.

To solve this problem I propose to implement a UI element that asks the user if they want to autoaccept files from this particular friend and to which directory. Optionally we could provide three options: No autoaccept, Always autoaccept, autoaccept for small files only. The third option would only download small files automatically as @sphaerophoria proposed.

This would solve the problem that you have to trust all users in your contact list and reduce the number of clicks to 1 for contacts you trust.

Should file contents be part of the history and immutable?

According to @zetok the file contents should not be part of the history and be treated as user data, with the user responsible once it was successfully downloaded by qTox.

According to @sphaerophoria file contents should be part of the history and immutable. The user has to explicitly copy them to a user directory, where it can be modified.

For this question I favor the approach of @zetok. In my opinion it's not a good practice to store all files twice, just to keep the history consistent. I however like the idea to store file hashes and path in the db to show in the history which files were moved/modified.

And now some special words for you @zetok: Stop being rude to other people just because you disagree with them. Personal level insults will not make your points stronger, but make yourself look like an asshole.

sphaerophoria commented 5 years ago

Thanks @sudden6, I think that summarizes the state of discussion fairly well. I believe the only thing I have to add on to my side is that I don't think every file should be copied, just that if a user wants to modify a file they should have to copy it or go through some extra action to indicate "yes I understand this will break qTox program state". Either way though this turns into a minor usability difference because as soon as a user sees once that a file disappears from history they will think twice about doing whatever they did again.

zetok commented 5 years ago

According to @zetok it should stay the way it is. No files are auto accepted by default. The user can enable autoaccept globally or on a per user basis.

Not quite. I never disagreed with the opinion that status quo should be improved.

Lowering amount of prompts that user has to face is a good direction. However, removing the only option that allows users to get rid of all prompts doesn't seem to be.

And now some special words for you @zetok: Stop being rude to other people just because you disagree with them.

If I'm being rude it's not out of disagreement. If anything, it's caused by the stress of trying to communicate when the other side doesn't seem to understand certain points.

Before commenting in this issue, I was reading through and catching up with some issues, and I had this thought: "Hmm, some of my writing in the past wasn't very nice. And there's this proposal. Although I really don't like how most of proposed points would end up creating problems and breakage, I get that the person is new to qTox development and they're trying to fix the problems they've encountered in the best way they can think of. Hopefully by pointing out that proposed points would result in more problems and breakage, broken parts could be thrown away and the rest would be good to use after slight adjustments.".

And it's sort of sad that I'm being told to stop being rude right after I've put in effort doing just that.

You know what. Fuck this shit.

I'm not going to bother with it. Next time I'll see a shitty proposal I'll just say straight away what's on my mind. I'm sure it'll at least help me reduce the amount of time spent on responses, making them a lot shorter, less helpful and not very nice.

BTW, as a reminder to you, and a valuable information to new qTox developers, I'd like to repeat what I've said long time ago: if there's agreement that my removal from participation in qTox development would be beneficial, I'll gladly do just that, as I've always wanted better qTox. So if anything, lemme know.

Personal level insults will not make your points stronger, but make yourself look like an asshole.

I think that the weird impression that insults are supposed to make discussion points stronger is wrong.

Also I'm not sure from where the plural "Personal level insults" is coming from.

sudden6 commented 5 years ago

Not quite. I never disagreed with the opinion that status quo should be improved.

Ok, so you want something improved, do you also have a counter proposal? Or ideas how our proposals could be improved? Or do you think our proposals are worse than the status quo?

Lowering amount of prompts that user has to face is a good direction. However, removing the only option that allows users to get rid of all prompts doesn't seem to be.

Here I disagree with you. I would really like some use case for where a once per contact question is too much. I think letting someone put a files on your PC without confirmation is a serious act and should be worth at least one click. For this reason I would support removing the global auto-accept possibility.

... they should have to copy it or go through some extra action to indicate "yes I understand this will break qTox program state"

Here I think it would be better to just store the file wherever the user wants it to be, but keep the path and hash. This way we can visualize the file being moved or changed in the history, without needing the concept of a cache or possibly storing stuff twice.

Another idea about your "cache" concept, maybe we should change it as follows:

This concept has the following benefits:

Cons:

I think most users know that they need a copy if they want to keep the original, so in my opinion this only provides benefits.

anthonybilinski commented 5 years ago

Weighing in my opinions for the technical issues:

I think the single prompt per user is an insignificant increase in interaction compared to global autoaccept. Yes it’s technically removing a feature, but there’s no friend auto-accept so any new friend is already manual steps. IMO this feature wouldn’t be worth keeping around due solely to the cost of cluttering settings. I don’t feel that strongly on the issue.

I agree, I don’t think file transfers should be deleted automatically. An easy compromise of not having an ever-growing qTox transfer dir vs automatically pruning would to have some warning if it’s grown to some size or after some time, and opening a system file manager to that location if the user wants to clean it up.

Agreed, cache dir should be data dir.

I think it depends on whether qTox keeps a copy of files for persistent chat log in a non-user chosen data dir, in which case having the option to delete the files from qTox makes sense to me, if they’re being saved to a user-chosen dir like ~/Downloads I think nothing internal is required.

I think this ties back to “File contents are not a part of the chatlog”. File contents are part of my chats, often when I read back on chat history now it’s hard to understand what was going on without that chats don’t make sense. Small source files, images, or small text files I want to keep in their transferred state with my history. I also don’t think that teaching users “what happens when they're working on the original files without backing them up first” is the goal of a chat app. For those reason keeping an immutable copy of the files seems good, with either a manual step to mutate files in-place / move out of the data store to a familiar location with a notification that it will modify history (and then showing the file as mutated/missing in the chatlog, by storing hash in db), or an option to copy the file out of history seems best to me without much duplication of storage.

sure

definitely

For the non-technical side, I'll hold back and just say I agree with @sudden6.

sphaerophoria commented 5 years ago

Another idea about your "cache" concept, maybe we should change it as follows:

There's no "cache" but a default download directory
The UI shows an option to "Move" files from the default directory to somewhere else. (This is similar to your "Download" concept.
The database is updated with the new location
If the file is edited at the new location or deleted it's shown as "Modified/Moved" in the history

I think this is moving in the right direction, but I don't think it's worth tracking moved files. Tracking moved files provides a lot of extra complication (new ui, extra logic) for what I think is a pretty narrow edge case. How do we feel about the following?

sphaerophoria commented 5 years ago

I think we're pretty much on the same page here now at a high level. I think it's probably time to split off tickets for more targeted discussion. I'm thinking I'll do the following.

  1. File transfers in chat log (PR #5354 and issue #5350) (all agreed on)
  2. Restructure/move default autoaccept dir (not sure if this one is flushed out yet but I don't see anyone having a real problem with it)
    • Move to $XDG_DATA_DIR instead of Downloads
    • Add default directories per-conversation
  3. Add max file size for autoaccept (all agreed upon)
  4. Disable global autoaccept and prompt to enable autoaccept in each conversation (mostly agreed upon)
  5. Tracking ticket for file transfers/history interaction
    • RO vs RW still needs to be discussed
    • Should we copy/hardlink sent files to preserve history?
    • Hash files and update UI on modified files
  6. Rework UI for image presentation (apparently there's already a ticket for this I just have to find it)

@sudden6 @anthonybilinski any objections?

sudden6 commented 5 years ago

@sphaerophoria yes, seems fine for me to split it up that way.

sphaerophoria commented 5 years ago

I believe this gives me enough to start working on and further discussion can be continued in the appropriate tickets.

Thanks for the input everyone!