Time to modernise SoulSeek?

[in...@guidobouman.com]

Hi there,

My name is Guido Bouman, one of the the authors of SoulSeek.js, made during a hackathon a couple of years ago. SoulSeek.js is a WebRTC implementation of peer-to-peer streaming music files. I'm planning on creating a modern web based version of SoulSeek to run in any browser. That could turn into a desktop app through something like electron or a desktop PWA. This would allow the platform to evolve, and by open sourcing it, would allow users to contribute and fix bugs quite a bit easier than with the current SoulSeekQt client.

Network

Part of the plan is eventually supporting different forms of SoulSeek servers.

An option would be a local SoulSeek discovery protocol. But that wouldn't bring you into contact with anyone on the other side of the world. You could make the client lists peer to peer as well. Then you would only need the destination of a friend that knows some other people on the network, who also know other people on the network. But that will give a high chance of sharding of the network. Torrents work with trackers, which are essentially handshake servers but some more ownership, and knowledge about which user has which files. That we don't need for SoulSeek, so you could make the handshake servers a lot less heavy.

There's always a handshake server needed to let clients discover each other. But you could setup the SoulSeek protocol to work with any handshake server instead of a single centralised one. Or actually, it would "just" mean running multiple servers and the clients would need to account for multiple possible servers and user accounts on each server.

What are you thoughts? And where can I find the protocol documentation?

[VV]

I dislike webapps, as a rule. And I think the security concerns with such an implementation could be very detrimental to the platform. How about an electron app? Or just working on the existing clients?

[Guido Bouman]

Why would you dislike them as a rule?

If the SoulSeek servers themselves are secure, a client is just a consumer of that system. Wether the client is secure or not does not matter. Yes, it should not leak it's data over the line (and prevent man-in-the-middle attacks). But a desktop application (C++, Qt or Java) has exactly the same concerns. I'm also suggesting an Electron app in my first post. But that does not change a thing about the technical implementation of the web app. With it's security concerns included.

I don't think the existing clients are open source. And using web technoligies makes contributing a lot easier.