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

Proposal + discussion around contribution #6091

Open
elribonazo opened this issue Jun 16, 2024 · 4 comments
Open

Proposal + discussion around contribution #6091

elribonazo opened this issue Jun 16, 2024 · 4 comments
Labels

Comments

@elribonazo
Copy link

Hello,

I've been contributing to the development of a couple storages for RXDB, mainly for 14.X and I'd like to extend my development even further now, to bring those to 15.X.

Things I could contribute on:

  1. Removing the dependency for crypto-js in old and new rxdb, replacing it with a secure encryption algorithm maybe and what I'd consider more important, the encryption plugin should from my point of view, allow user's to enter their own cryptography.
    My ideal encryption plugin would not bundle cryptographic libraries/primitives but would require a protocol to be passed, people out there in the wild can choose what cryptographic layer or primitives want to be used.

  2. Is converting RXDB into workspace something that you are considering internally? I love this library... REALLY and would love to take it to its next level.

  • Nobody really has a need to have everything bundled in 1 single library, does not really benefit them.
  • Install only what you need, reduce bundle size, bugs, security issues, etc.
  • Splitting into workspaces would be maybe a pain to start but would bring great benefits to the project, more pro's than cons.
  1. Plugins & open core development:
    The free plugins lack some functionality, i've seen couple things I reported you guys on Christmas have been fixed in recent versions but my whole point is... Why not making the Plugins all open and free but maybe offering a SAAS Secure solution for those that don't want to be storing their contents in their browser, like a delegate & custodial remote storage.

I've currently got: 1 indexdb custom storage, 1 leveldb storage and 1 custom inMemory storage.
Migrations in 14.17.1 dind't support passwords (encryption) for example, so I've developed my own.
Encryption in 14.17.1 used a vulnerable dependency that my project cannot really accept :D

I may just go totally wild and re-write this in RUST, how i always envisioned, dunno. First though i want to see if we can collaborate, if there anything I could start helping you with(outside work, on my free time) =?

Thank you s o much RXDB team, marvelous work!!!
Love you guys

@pubkey
Copy link
Owner

pubkey commented Jun 16, 2024

Hi @elribonazo

  1. There is already the premium web-crypto plugin. This has the best tradoffs because it relies on the browser crypto methods and you do not have to trust anybody else.

  2. Yes that was considered many times. But this requires a huge amount of work and for me I do not think it adds that much values to justify the work. If you want to do that I am happy to accept a PR. I already own the @rxdb npm-handle so we can publish packages at this.

  3. Atm RxDB is self sustainable until eternity. I do not want to risk that by changing the business model. I considered building a cloud offering but this is planned for the intermediate-term not short-term.

I see no value on rewriting everything in rust. Instead we could collaborate on creating an RxStorage implementation in rust that can run in webassembly and maybe is much faster. But my current performance measurements show that the main-thread to webassembly bridge cost so much latency and overhead that having everything build in javascript is much faster. For example the sqlite wasm storage is not that much faster compared to indexeddb even when sqlite is used in-memory.

@elribonazo
Copy link
Author

Hello sir, nice to read from you again! Thanks for the quick reply.

I do have a custom encryption plugin but what is affecting me as a user is that my project has very strong security requirements, and despite we are able to justify that the vulnerable dependencies are not used in the project it does not look right, also our security audits will spot this and reject our release.

I agree that it would require a huge amount of work but u know it would improve so badly? Someone that just wants to use a storage can just install the test-suite package, run its tests and then be ready to release. Same for other packages, why do i need to use firebase with the vulnerable dependency if i'm not using the replicate plugin for firebase, see what I mean?

I think most of my issues would blow away if we could achieve workspaces for RXDB and i'm happy to try collaborating in that sense! thanks for your support man. Won't make shortcuts in terms of testing, etc... no matter how long it takes but yeah i really would love to see we can make this.
Going full rust would be re-writing the full core, that is what i ment... I care less about the storages, people could use wasm or not wasm as now. Anyways,let's see if we can try first approach.

For now, we are patching the package :| taking out crypto-js and the firebase replicate plugin, all good i guess for now, but its not very clean hehe :)

Have a great week!

@pubkey
Copy link
Owner

pubkey commented Jun 21, 2024

I think most of my issues would blow away if we could achieve workspaces for RXDB

PR is welcomed.

Copy link

stale bot commented Jun 28, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed soon. Please update it or it may be closed to keep our repository organized. The best way is to add some more information or make a pull request with a test case. Also you might get help in fixing it at the RxDB Community Chat If you know you will continue working on this, just write any message to the issue (like "ping") to remove the stale tag.

@stale stale bot added the stale label Jun 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants