[Kavita] Upload files from web

[WeslyG]

Idea Description

I found kavita as a decent self hosted alternative to google books. For me, google's functionality is quite enough, and I really like their clean interface and approach, but I really want my data to be mine. Therefore, in kavita, I really miss the opportunity to upload a file directly to the web interface, I'm used to doing it on google, just take the necessary epub that I bought and upload it to Google, directly to the web interface, it's so convenient and fast and natural. I was very surprised that you can't do the same in kavita, and that you need to upload files to the file system, as if I didn't expect this. I need to create a folder with my hands, and upload a file, I would like to expose kavita to the nat of my network, and have access from anywhere, but I would not like to do the same with the file system, of course, all this is solvable, but I would be happy with this opportunity.

Duration of Using Kavita

a few months

Idea Category

User Experience

Agreement

• I agree that this is solely for submitting ideas, and I will search for existing ideas before posting.

[majora2007]

I'll just let you know, as this has been asked a lot, but it's not something I want to be doing with Kavita. Kavita has a policy of not touching underlying files. Opening the door to managing files like this can introduce tons of additional complexity to meet users different organization schemes. It's just not the type of thing I want to spend my time working on.

Future users, feel free to upvote and comment.

[DieselTech]

To add to that there is tons of different tools that do this better. No need to re-invent the wheel each time within every app. It's a lot of things to account for that people don't realize for something like this.

What do you do if the disk is full?
The files uploaded would then be owned by the user ID that the kavita process is running under, but that might not be the ID people want.
What permissions do uploaded files get uploaded as? (0665, rwx?)
What file types do you let users upload?
What if they upload something that is a executable file but renamed it to .pdf?
What if the upload process has a buffer overflow and executes the file?
What if you uploaded it to the wrong spot and want to change the location?
Do you let people move files around folders that were already on the file system? Or just the files they uploaded through the web?
If you let them move files are they able to browse outside of the upload folder to other parts of the machine?

These are all things that need to be accounted for and just like joe said, it's not worth it IMO. All this logic and checking is already built into apps that are dedicated transfer tools. It's best to just use them to do remote uploads.

[WeslyG]

Okay, great, now I know your position, thanks for the explanation. Hopefully others can find this discussion so they don't have to ask this question again. Have a great day, and thanks for your project!

[ivanjx]

1. tell the user that the disk is full
2. that is the user's problem, not kavita
3. the default umask is 022 (644 for files)
4. whatever kavita supports
5. kavita should validate using something like file command. a lot of projects does this.
6. thats just a bad programming and should be fixed asap
7. the point of uploading via web ui is to let kavita to manage the directory
8. kavita should support both. scan if the file does not exist anymore, remove the entry
9. ?? of course...

[fritzcloud]

I think that your argument makes sense, users with existing large libraries would not benefit from this feature, but I believe most people looking at kavita see it as a way to better manage and consume their content. I don't think it is bad if kavita had the option to manage your library for you. I think the average user looks for a simple experience with an upload button, some default paths being created and they don't have to look behind the scenes. Other services like calibre-web and audiobookshelf do it in the same way, they create the libraries for you but they are still in a nice format and you can move them without a problem. Also you increase complexity for the user by not having this feature, because if I want to download and add a book while I am not at home, I cannot just access my kavita instance and upload it, I need to have created a smb share, connect to my home network, use a file manager, manually create a new author/series and paste the file into that. This is a lot of work for something that is one click in other selfhosted applications.

[DieselTech]

Don't take this the wrong way, but

I don't think it is bad if kavita had the option to manage your library for you

You don't think it's bad because your not the dev who has to spend the dozens of hours arcitecting a solution and programming it. And then supporting it after it's out with all the users that will come asking about it. Dealing with all the questions of people asking why it doesn't do what they think it should do. Then testing against it every time a new update comes out to make sure it keeps working when new things are added to the app. So to you it just seems easy, but this isn't a burden that the dev is ready to take on yet. Not while there is so many other things that could be added to Kavita that are more inline with reading and having better support for comics / manga / pdfs.

I need to have created a smb share, connect to my home network, use a file manager, manually create a new author/series and paste the file into that.

Your going about things the wrong way if that is how you add files remotely. That's the slow and long route. The reason something like this won't exist in kavita is because better tools exist. SFTP servers let you directly manage your file system without all those extra steps.

[fritzcloud]

Oh, I apologize if I came across as rude, I am absolutely aware of how much work this would be, I am just saying that I don't think that anything is wrong with the idea itself of it. The devs will prioritize what they have time for and I am thankful for anything I get. I am voicing my support for this feature but of course there are no expectations here at all.
Thank you for mentioning FTP, I somehow totally forgot about it. That should make managing my files remotely a lot easier, I will give that a try, thanks!

[therobbiedavis]

Not to beat a dead horse, I would also try automating your ingest flow, prior to Kavita. Readarr may be a good option for that, but the idea is to essentially have automated tasks that happen when a file is downloaded like processing, creating appropriate folder structures, and moving the file to the appropriate folder.

The idea is that Kavita is to be a media server only, similar to Plex. You can't upload content to directly through Plex, Emby, Kodi, or Jellyfin that I'm aware of. Once we stray from that vision it opens the door for "Jack of all trades, master of none" further convoluting any vision for the product.

[deafmute1]

I understand the reluctance to implement this sort of feature, but will describe my use case here in case it is useful to inform future dev decisions. I have recently switch from calibre-web, mainly as that project is pretty much in long term maintenance mode, has some usability issues and its reliance on calibre metadata.db organization. I much prefer Plex style file system scanning like kavita has.

Mostly, I get ebooks over https, not bittorrent or usenet, as do many people I believe. As such, readarr is not viable and I have found lazy librarians support for http sites and overall future/stability poor. Overall prefer to not automate the download of ebook as it seems to me like I would be mostly automating my way into more work. Unlike Plex or similar, where automation of downloading content for Movies, TV is the optimal and common approach, for ebooks, using https source which are difficult to automate on a server is common. As such, most people must download their ebooks to a personal device manually. I would like to be able to, with a small bit of scripting, send any file on my personal computer to kavita on a server.

Kavita is fundamentally a tool meant to be hosted on a remote web server. Accessing the underlying file system of a web server if not really an optimal workflow. If you are on a remote network especially, there are a myriad of pragmatic and security concerns to contend with. I am happy to use sshfs+vpn as I have these things set up and am the sourcing 90% of the files myself, but this model prevents true multi-user usage (where users can provide files too) of the kavita instance. There is not really any neat way to provide multi user upload support without passing out vpn keys, setting up ssh ACL, installing sshfs/ftp client on windows etc.

Ultimately, I understand that kavita is taking an approach similar to software for other media like Plex. Its a model that makes sense, but ebook workflows are a bit different for many users.

[sunjam]

Since you want a nice multi-user experience I think you'll be very happy with Nextcloud.

Mostly, I get ebooks over https

Another great tool for this is Aria-ng + browser extensions. Supports multiple servers and locations, which makes it easy enough to share with others.

[paulcsiki]

Adding my use case to the pile.

I run a home lab with Kubernetes and the storage is mounted through iSCSI making it a rather difficult task to have multiple pods share access to the same PVC. I could use NFS however I have reasons why I am avoiding it. I understand the implications and complexity of such a feature however the only similar tool that supports uploading through clients is Librum which is extremely buggy and hard to work with.

In terms of security, this can be a feature optionally enabled at the admin's risk. Basic library management will suffice (upload and delete). Edge cases such as available disk space, file permissions, file system specifics all should be left for the admin to monitor, manage and support.