Lutymane

@etareduction do you think it's worth having two different tables for shared and published? I'd suggest to have a single shaders table and include a flag `published` instead, so it'd...

@etareduction My idea for the keys was to allow people to store only the key itself (as they'd do with password, we can even use password type field, so it's...

@etareduction > enter his key each time he publishes Not unless we just save it into local storage and provide the user with this option. Whether he wants to save...

Tbh, we could just make an input field in settings to place the key there, so it'd be used for publishing. Also it should be encrypted before writing to local...

@etareduction > browser extension can read local storage Indeed. But this vector of attack is pointless (who needs to develop a specific extension to steal a key for signing shaders?...

Although I found this cool approach with storing unexportable keys in IDB: https://github.com/fission-codes/keystore-idb But it basically locks you to a specific machine with a specific key, so you can't use...

@etareduction > Github OAuth Hmm, actually, I agree using GH OAuth would be probably the best 😄 I forgot about spamming, so having a valid GH account would make it...

@etareduction Got an idea, how about using the same ID for shader revisions? So if a user publishes same shader multiple times, instead of assigning a unique ID every time,...

@etareduction I never tried GraphQL, so let's stick to it, so I could finally learn it 😄 Regarding revisions, I think it should just be limited to a single author....

Also regarding the backend code, I can't decide what to choose, turn this into monorepo on a single branch, or make an orphan branch for the backend