I want to build a music sharing/streaming web app with IPFS and Next.js. My idea for this app is if one user wants to play a song, it will get the song from IPFS, and of course, play it in a player I will build, and store that song in the browsers IPFS node (for as long as the user doesn’t exit the app’s tab), and if a second user that is close to the first user wants to play the same song, he will get the song from the first user’s browser IPFS node that is running. My question is, does IPFS do that by default if I do this from the browser? And if not, how can I manage to do that? Or is it possible to do it from the browser? Or would it be wiser to make this a desktop app, let’s say with Electron.js.
Honestly I’m not 100% sure where the data goes using js-ipfs in browser, I’ve been meaning to check exactly what’s happening on an ipfs.add. In theory it should store using IndexedDB and re-serve as needed, but again I’m not 100% sure what all happens.
If you want to make a desktop app I don’t recommend Electron because it’s large and clunky, instead I recommend Tauri. I’ve begun some work to try to ease the transition from website to desktop here: GitHub - TheDiscordian/native-ipfs-building-blox: Create native IPFS powered desktop applications by using HTML/CSS/JS..
2 Likes
Browsers generally don’t make for reliable providers of content to the IPFS network due to several reasons:
- Resource constraints imposed by browsers
- The fact that they are not long-running and can come and go
- Connectivity constrainst
I suggest reading this blog post State of IPFS in JS | IPFS Blog & News for more background and details on the specifics.
With a desktop app built using Electron or Tauri (as @Discordian suggested) you have more flexibility because you are running in a less constrained environment (Node.js or a rust binary with Tauri) with more connectivity options.
1 Like