3.0.0 plan

[silverwind]

• Replace the --home option with --configdir and --filesdir so one can decouple the locations of config and files dirs.
  • If either is left unspecified or --home is given, use the old behaviour and use ~/.droppy and ~/.droppy/files
  • Print a warning message on --home and advice the user to specifiy both new options. The warning should include what both optiones would with the current location resolved.
• Maybe tackle file search. The plan on how to do is is pretty clear (server keeps an index, client queries the server which returns the matched files). I need to decide whether to use a library for autosuggestions or implement it myself. Also, an UI redesign with action buttons for each view is likely required (https://github.com/silverwind/droppy/issues/88), so each view can have their own search box.

[silverwind]

Tagged 3.0.0. See https://github.com/silverwind/droppy/blob/master/CHANGELOG.md for details.

[Poorchop]

I was reading about managing dotfiles recently and I saw some discussion about adhering to XDG spec for the sake of management. I sort of agree with the view that the home folder shouldn't be full of dotfiles/folders from various software and I was wondering what you thought of sticking to the default spec.

This still provides for a separation of the config and file directories - the configdir would be $HOME/.config/droppy and the file directory would be $HOME/.local/share. It's not a major change so maybe these could be the defaults instead.

I also haven't installed droppy from scratch in a really long time so I was curious as to why you are now recommending /srv/droppy/ as the default base directory. Wouldn't it make more sense to point the directories to a location owned by the user rather than root?

[silverwind]

I agree, XDG Base Directory support is something that should be added. It should be quite easy do to. In addition to XDG_CONFIG_HOME and XDG_DATA_HOME, XDG_CACHE_HOME could be used for temporary upload files.

Still, I'm not sure if it's even a good idea to have the application write into the user's home directory per default. It's nice for testing purposes, but for a more permanent installation most people will likely want to have a dedicated user to run the application and use directories somewhere outside of that user's homefolder.

Wouldn't it make more sense to point the directories to a location owned by the user rather than root?

It's kind of implied that these directories are owned by the user. I added a note to the installation instructions regarding it.

[Poorchop]

but for a more permanent installation most people will likely want to have a dedicated user to run the application and use directories somewhere outside of that user's homefolder

Absolutely, and I think installing it as a systemd service makes the most sense. The local installation instructions are good for showing how quick and easy it is to get up and running, but as it stands, a novice user would have to run the package as root or otherwise use his home directory. I'm no security expert but running the software as root seems like it could open up a potential threat vector.

I just think that in addition to the local and docker installation instructions, there should be more detailed information in the README itself that outlines creating a new droppy user that will own the droppy process and the config/file folders. I think that znc does something like this too - by default, the user will own the process and configs will be in their $HOME, but the other (and better) solution is to create a znc user and possibly run it as a systemd process if the user so chooses.

[silverwind]

Agreed, there should be a full working example for a secure installation. Withd Systemd being the standard nowadays, I think it's time to feature https://github.com/silverwind/droppy/wiki/Systemd-Installation more prominently in the README. Probably needs some tweaks (like no login shell).

[Poorchop]

Sounds good. Thanks for your continued work on this project as well. It's still one of my favorite pieces of software.