So basically it’s a free version of “Google Drive”, but you can upload your own files to this service which has very generous size limits. This will free up egress, account storage, and allow reuse of assets (such as your favorite CSS template that you made).
I’ve decided on this project because I don’t think that this would be too difficult (starts to think about Idkwhttph’s Pokemon Adventures)
Here are the specs:
How it works
People can create accounts (replit OR github) on this website to be able to upload files to the server under a generous quota (more then replit) to a server of their choice, namely Github or Replit (only if possible). Once the upload is complete, users will then be able to access their content through their account-name-based suffix, up to a certain limit. Users can increase this quota by donating cycles on a repl, which will be checked via GraphQL.
Linking an account on this site to the username of the Replit user is not the best idea, because if a user changes his name to Replit, he will lose his files forever, and someone else will be able to change his name to Replit to the name of the first user (the one who changed the name before)
and get access to his files.
I am not sure what you mean, because I have not linked any users or profiles in my post. I am expecting that nobody will change their username in this fashion, and if such an event should happen, then I will make sure that gets addressed.
After reading your paragraph a few more times, i realized that you were talking about the username suffix system. Well, I guess that is a very valid problem.
I would surround the username with the user id (which is constant IIRC), and provide an endpoint to automatically transition all files to the new account if I get the time.
I meant replit user id, not account id. picking usernames could be implemented later, but the big username space wouldn’t be easy to moderate (for usernames such as replit, admin, administrator, static,css,hosting,etc).
However, session tokens (aka connect.sid) wouldn’t need to be hashed or salted as using a hashed copy on the server and the client wouldn’t be useful (only to standardize the length).
Hashing is only required when there is a server leak, which is at the very bottom of the roadmap.
Ive come up with a new system: id linking (github id, replit id, email addressed for others) with custom usernames. Ive realized that having two prefixes is hard to manage
Probably not (especially since i’d have to store it in a file and all commands are strings). Instead, I’d use firebase with my auth framework.
Also, I would differentiate ids with “prefixes”, such as R-48382 for replit, G-383483 for github, and E-noreply@google.com for emails. Username changing is annoying, so why dont I DIY it and prevent username changing?
You could use Postgres (which is easy to run inside a repl, and free to use). Postgres works great with Node.js, and it’d probably be easier than Firebase to use
Also, you’d have to iterate through every single user to find someone with that method, making a DoS attack as simple as creating lots of accounts and logging in to them over and over.
