Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Send to Kindle (email to E-Reader) #132

Closed
hay-kot opened this issue May 11, 2023 · 2 comments
Closed

[FEATURE] Send to Kindle (email to E-Reader) #132

hay-kot opened this issue May 11, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@hay-kot
Copy link

hay-kot commented May 11, 2023

Is your feature request related to a problem? Please describe.

My wife and I are looking for a way to share E-books more easily. I'd like to use Stump to put all our ebooks into a shared library and she can grab the ones she wants and send them to Kindle or eq. E-Reader

Describe the solution you'd like

I'd like a drop dropdown on a books page that would allow me to send the book to a pre-defined email (or pick from a list of pre-defined emails)

Describe alternatives you've considered

This can be accomplished by downloading the book manually and emailing yourself.

Additional context

I see two ways to do this,

  1. Each users has a list of emails that can be used to "send-to" and each of those have their own entry in a dropdown menu.
  2. Each user has 1 email that is used by default in the send too option. In this case, I would like a input to manually specify an email address in case I want to send a book to my wife's e-reader directly.

I'm opened to creating a PR on this one, but would like to know which way to go before I dig in too deep.

@hay-kot hay-kot added the enhancement New feature or request label May 11, 2023
@aaronleopold
Copy link
Collaborator

Hello!

I'm not opposed to this kind of functionality living in Stump, I'm sure it would be considered useful for enough people and sounds cool, though I'm not familiar enough with Kindle specifically to understand exactly what is needed for this kind of thing. Every reader I use is either using page streaming of some kind or can load webpages/supports direct download. I personally won't have development time to give to this until after the core features for the 0.1.0 release are completed at the very least (#107 for more information), but am otherwise happy to help facilitate any outside contributions where I can 🙂

I see two ways to do this,

  1. Each users has a list of emails that can be used to "send-to" and each of those have their own entry in a dropdown menu.
  2. Each user has 1 email that is used by default in the send too option. In this case, I would like a input to manually specify an email address in case I want to send a book to my wife's e-reader directly.

I think some sort of RBAC more closely similar to the (WIP) reading list RBAC would be a good model, where the server owner can maybe assign a role of internal-emailer or external-emailer (or none):

  • none: cannot send emails
  • internal-emailer: may email any registered user with an associated email
  • external-emailer: may email any email, inherit role perms from internal-emailer

Emails are not currently collected, so that would need to be a migration on the users table, as well.

I'm also not really familiar with what Rust libraries are available for this. A brief search shows https://github.com/lettre/lettre might be viable. But, some things I would want to ensure are not bloating too much by adding this. Using that as a segue, I think a general sort of requirements would be:

  • Minimal bloat (server executable size shouldn't go too much larger), this could be a non-issue, like I said I am just unfamiliar with what is out there
  • Should be completely opt-outable by the server owner.
  • RBAC needs to be air tight so server owners' files aren't floating around if they don't want them to be.

@aaronleopold
Copy link
Collaborator

Implemented in #296

@github-project-automation github-project-automation bot moved this from In Progress to Done in v0.1.x Apr 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Done
Development

No branches or pull requests

2 participants