collectivenectar / soundslip Goto Github PK

View Code? Open in Web Editor NEW

1.0 1.0 0.0 19.71 MB

A Webapp for sharing small audio files

Home Page: https://soundslip-frontend.herokuapp.com

License: GNU General Public License v3.0

CSS 22.23% HTML 1.07% JavaScript 76.66% Procfile 0.03%

soundslip's Introduction

soundslip

A Webapp for sharing small audio files

It's currently DEPLOYED and live at:

Soundslip - live version

mobile and desktop demo:

If you would like to contribute or offer suggestions for improvement you are welcome to contact me or open an issue!

Soundslip is a sharing app for audio files

I love sites like freesound.org and picking up sample packs and instruments for my own music production, so I decided to make a sound sharing app, starting with a basic server, then eventually shooting for an IPFS pinned version.

#NOTE: With an eye towards a more serverless application, this app and the maintenance for it is being shifted to another repository with the same project purpose. All code is being commented just for quick explanations, and otherwise the majority of development on this idea will be taking place at NextJS-Soundslip. I will likely be using some code from this frontend solution to save time solving the same problems all over again.

MVP features:

Each user has the option to upload audio files as 'public' or 'private' - to share or keep access restricted.
Search for public audio files by file Title as well as any previously created Username.
Add sample 'tags' that identify the file as a certain type of sample - "loop", "synth", "drums", "voice", "solo", "other"

Considered additional features:

larger file sizes (full songs or wav/aiff/flac) with GridFS, more MIME types
group audio files as packs or albums - i.e. add a custom 'album' tag to filter results with.
Decentralized file hosting, i.e. pinned on IPFS
Cryptocurrency integration for file access paygates / NFT authentication and DID auth

Concerns:

As this is an app for sharing music, there would long-term have to be some liability regarding creative ownership and copyright compliance. My solution would be to shoot for CC0 licensing for anything public, and if the service is relied on that heavily I can always integrate a copyright checking service, or just find a way to fully decentralize the entire service if possible.

Some sample screenshots:

A video demo showing how it works:

Soundslip - Application Demo

Make it yourself with:

Client

VITE REACT REACT-DOM REACT-ROUTER-DOM CLERK.DEV

Server

MULTER MULTER-S3-V2 EXPRESS MONGODB MONGOOSE AWS-SDK(V2) CORS

AWS Notes:

To use with AWS, acquire an AWS IAM user with access to AWS.S3 bucket.

If your file host service provides presigned URLs, I've tried to make it simple to swap out.

Otherwise, if you don't want to use presigned URLs or AWS you may need to change how the audio player handles either the files or urls, and how they are routed.

That is all handled in:

https://github.com/collectivenectar/soundslip/blob/main/client/src/App.jsx https://github.com/collectivenectar/soundslip/blob/main/server/middleware/multer.js https://github.com/collectivenectar/soundslip/blob/main/server/controllers/awsController.js

To deploy just the vite client on heroku, I have used:

Procfile web: npm run heroku-push

Buildpack heroku/nodejs

package.json "scripts": { "heroku-push": "vite --host --port $PORT" },

And in the heroku CLI to build the client the first time I changed some settings:

NPM_CONFIG_PRODUCTION=false

NPM_CONFIG_LOGLEVEL=error

YARN_PRODUCTION=false

NODE_VERBOSE=false

NODE_ENV=production

NODE_MODULES_CACHE=true

To deploy just the express server on heroku, I used:

Buildpack heroku/nodejs

Even without a procfile heroku deploys the server build without issue, no changes to the package.json

soundslip's People

Contributors

Stargazers

Watchers

soundslip's Issues

IPFS Hosting

Would love to offer IPFS hosting for audio files.

key features -

Choice of centralized vs decentralized sample hosting.
Upload audio file to IPFS for free - with limits - OR provide your own IPFS content hash to link the audio file to the mongodb details.

Challenges:

Auditing file MIME type when the user provides a file hash
Asynchronous calls to IPFS for upload/download could be a UX issue if it takes too long compared to AWS. Needs a good quality
IPFS gateway, or some other solution.

Other:

Consider a client side worker script for encryption of the audio files themselves. This could open up the option of
having users provide IPFS hashes to encrypted files, and this way they can gate access to files simply by providing
either a decryption key, or having users verify ownership of an NFT in their possession before decrypting the file.

Ideally worker script can export keys as a simple file so users can take it with them and it never touches the internet.

v2.0 redesign

Starting v2.0 off by cannibalizing everything I can use from v1.0 in the UI department. This should be mostly no problem since I'm migrating to Next.js, but I am also doing a complete redesign, so I may still unpack and rearrange quite a lot of the architecture in order to accomplish that long term.

Main things I want to accomplish are:

Using imagery uploaded to the wiki and project, redesign the site using those themes and elements. (linked later)
Keep in mind the other components that will eventually be added, and try to think how I can make the styling more global.
Integrate more data visualization and audio visualization - but make it friendly to the smaller devices, too.

This Issue will track all the other design related issues for my convenience:

Better Comments - Documentation and Refactoring

Seeing as the nextJS version of this app is a priority, I'm now going to improve docs and comments on it before migrating useful code over to the nextJS project.

Make sure to:

Explain only what's necessary don't expand
Be more clear in areas where you were challenged
Explain enough to help others use it

Search Feature

Needs a search feature, currently just shows all public audio files.

Implement a search including at least search by:

title
username

if possible also add description

Download feature

Currently download is unavailable due to security issues in the browser api for triggering a download of a presigned URL.

When requesting a download, a URL is received, but getting the client to download the file is not working.

Landing Page / hero

An introduction page would be nice for when the app first loads so users can see what they're getting into before having to sign up for the app.

V2 - Refactor and Redesign

This is the main tracking issue for all v2.0 related issues. It's a lot for one person so it's likely to take some time, but this is where I wanted to go with it anyways, I was just getting ready to take the idea from the stack I know to the stack I don't.

v2.0 Might have a combination of all of these features:

Migrated to Next.js
I want to do some heavier frontend stuff, and I need to be able to work in more custom loading to keep UX 100%
Have the backend support calls to chia RPCs for audio NFT features.
Chia is the RPC I want to learn, and the NFTs they offer are the most secure in the biz, so I want to build on what I think will last.
Also support something like neon.tech, serverless postgres? Maybe
I have experience now with neon.tech and think it will work well with Next.js, plus I want users to have analytics if they make any money.
Added a web worker / client-side worker - for audio encryption and decryption, processing, and for future audio rendering
Likely need to generate 'demo' or 'preview' audio, then also encrypt user files before uploading, decrypt, etc. Needs a lot of looking over for security concerns as this is kind of what a seller hangs on.
Opened up user auth options - User authentication uses metamask, or some other web3 auth, and then some privacy friendly ones. Open up web3 ID so users can see what their product could be like.
Decentralized the storage feature - So maybe an infura gateway, or something similar, but anything else!
Let users provide NFT links, icloud links, google drive links, whatever they want to use to store it. But also provide an integrated solution that can encrypt their files and the keys never leave the device.
Full audio sample publishing and player capabilities:
a) Sample Packs, Playlists/Albums, lists, etc
b) Batch upload, labeling, and download relabeling(non-destructive only).
c) Metadata Tags and virtual remixes ( without touching the audio file, just add a link to a file that reproduces a desirable effect on the audio, via plugin settings, etc )
d) DRM handling UX - Provide licensing choices, and enforce the selection that sample producers make when they upload by
restricting access to files until the user agrees to those terms. Revoke access to users that abuse it.
e) Export to as many options as possible - maybe find if plugins in DAWs are possible, but if not just make organizing their downloads really, really easy. An internal file managing system that supports soundslip metadata would be ideal, but costly.
Redesigned the user interface from the ground up to use more global classes, possibly using component-based styling
a) Reusable components: Lists/accordions, audio player, analytic displays, audio visualization, user profiles, sample profiles, NFT profiles, DID profiles, chia wallet integrations / widgets.
b) Style: using a more subtle UI background this time, and fonts and such will focus on readability. Shifting to a rounded corner UI theme, including a day/night mode, altogether a lighter feeling UI with a little more shadow and texture. There will be more contrast this time since there will also be more data visualization.

Whew! Ok, it's a big list, and some of it could get cut as I settle more and more into the most important problems for this idea.

I will reference below issues to track and keep this one pinned.

Issues:
#14 Styling - SASS and react-bootstrap redesign from the ground up

-Jon