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

Public Service #21

Open
w0rp opened this issue Apr 21, 2022 · 0 comments
Open

Public Service #21

w0rp opened this issue Apr 21, 2022 · 0 comments
Labels
enhancement New feature or request

Comments

@w0rp
Copy link
Member

w0rp commented Apr 21, 2022

This issue captures a need for a public service for Pricewarp, and some considerations to be made.

Users may be comfortable installing a desktop application

See #9. For the set of users who are comfortable installing a desktop application, they can do so. This will be recommended, and will be the best possible experience. The best way to ensure privacy of portfolio data is to run the application locally and never send any data over the Internet to anyone.

Other users will not be comfortable installing a desktop application

There will be another set of users who will simply never install a desktop application. Whether through laziness or through distrust, these users simply will not install a desktop application. They will want instant gratification of portfolio management needs at a glance. We will always encourage users to install the desktop application, but we cannot simply ignore the users who do not want to.

WebAssembly won't work

It is possible to convert the database queries from being Postgres-specific to being database-agnostic so that queries can be run against an SQLite database. We could then, in turn, package the application for browsers with WebAssembly and deliver the application directly in such a manner that information will be held entirely in the client browser and associated files. There are two major flaws with this approach.

  1. Users won't know where their data is. They will inevitably lose their data as a result.
  2. SQLite is simply not fit for purpose.

SQLite does not provide, nor will it ever provide, the numeric data type we need for accurate price calculations, nor the data integrity we need for a fault-tolerant database. This means that Postgres, and only Postgres, is the single type of database we should support.

The creation of a free public instance will be necessary

The only way to capture a large set of users and meet their needs is to provide the Pricewarp application with essentially open registration, for free, forever, to anyone who wants to use it. The monthly bills for running such a service will be huge, so such a service will have to be powered by donations. It is easy to foresee that donations in future will be sufficient once the value of the service is proven.

I see no reason to assume that the service cannot run efficiently and serve the needs of tens of thousands of users, if not millions of users, worldwide, at a relatively low cost to run compared to what others might expect.

Conclusion

Self-hosted instances and desktop application instances should be targeted first. After these instances are stable and fully-realised outside of a proof-of-concept mode, the next step that should be taken is to provide a public instance that is free for anyone in the world to use, at absolutely no cost, which promises to never share the information collected with any third party whatsoever. This will be the mission statement of the project.

Live free or die.

@w0rp w0rp added the enhancement New feature or request label Apr 21, 2022
@w0rp w0rp removed the enhancement New feature or request label May 12, 2022 — with Exalate Issue Sync
@w0rp w0rp changed the title Public Service: Considerations Public Service May 12, 2022
@w0rp w0rp added the enhancement New feature or request label Jul 20, 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
None yet
Development

No branches or pull requests

1 participant