Rethinking about LSP

Nobody has claimed this yet.

## Background

I think it is time to rethink about LSP, the LMMS sharing platform.

The code of it was an ancient piece of history from the late 90s. And some of the coding conventions are no longer best practices today.

## UI/UX Redesign

As time went by, design patterns changed a lot during these years. Although we have redesigned the main page and adapted the LSP website accordingly, the design is not so intuitive to the people who are familiar with "more modern websites."

## Technical Practices/Debts

The LSP is a disaster in this field.

- The hash of the password is insecure (prone to multiple attacks, including but not limited to LUT attack (aka Rainbow Table Attack), length-extension attack, collision attack (demoed by Google), etc.)
- The database didn't take advantage of foreign key constraint or any other constraint checks to prevent data inconsistencies at the DBMS level
- The file drop function just making the files laying on the disk wasting inodes ([I am very sure the problem won't occur!](https://github.com/LMMS/lmms.io/issues/173))
- The HTML structures are concatenated together, making it easy for attackers (some of the contents might not be correctly escaped) and [making it challenging to translate](https://github.com/LMMS/lmms.io/issues/249))
- The LSP isn't Unicode aware, data is stored in Latin-1 encoding in the database and breaks when there are multibyte sequences (like CJKV and emojis)
- Can't be easily patched to have things like avatars (#255) or upvote-based rating system (#246)
- Anti-spam is a joke, a basic OCR engine can decode the security code correctly, and there are already spamming incidents in the past
- ...And much other nitty-gritty from both users and devs

## Possible Improvements

Okay, enough whining now, so here are the ideas I have so far:

- Implement LSP in a different language than PHP (like Python (Falcon/Flask/bottle/Django/aiohttp/...), Ruby (Sinatra/RoR/...), Rust (actix-web/hyper.rs/...), NodeJS (ExpressJS/...), etc.) one of the reason is humans are good at reusing patterns, so this is to avoid that.
- Use a separate NoSQL database (`k=v` database) like LevelDB, RockDB or Redis to store the files; this can reduce the disk I/O, inode usage and presumably boost the speed. Some of these DB comes with builtin compression mechanisms.
- Migrate to probably MariaDB (MySQL compatible written by former MySQL developers) or PostgreSQL for the database, and they offer better optimization in our use-case.
- Redesign the UI and use probably specific frameworks to create a single page PWA to speed up page-load and overall smooth experience, an alternate design can be deployed side-by-side for people who disabled or don't have Javascript and CSS support

The issue does not name specific files, tests, or entry points. Start by locating the current LSP implementation and reviewing the related issues #173, #249, #255, and #246, then inventory the authentication, database, file storage, HTML, and anti-spam paths. Done is not defined; the issue needs a bounded redesign plan before implementation can begin.

Written by the indexing model from the issue text.