Add wss protocol to server.js and suggestions in README

[micrology]

Added code to server.js to implement wss:// protocol as well as ws:// Added hints in README.md about setting up a websocket service

_{Huly®: YJS-789}

[anilgulecha]

@micrology , This is something I was looking for but then settled with a fronting service (cloudflare) which could terminate ssl and forward. Can you shed light on how you'd host this with Let's encrypt perhaps?

We also built a dockerfile on y-websocket - perhaps there's some interest in that too? Can create a PR for that

[micrology]

@anilgulecha, I tried to give some hints about how to do it with an apache web server and let's encrypt at the end of the README (see the files for this branch). Do contact me if you'd like more detailed information about what I did.

[ellisonbg]

This capability is important, but it may make more sense to embrace a containerized+proxy approach as the primary recommendation. Would be interesting to see an example of this running behind traefik (https://github.com/traefik/traefik).

[micrology]

Happy to include a containerized approach as an option, but it would be overkill for my simple needs. With the few lines I’ve suggested adding to server.js, all I then need to do to my Apache httpd.conf configuration file is add two lines:

SSLProxyEngine on ProxyPass /wss wss://example.com:1234

and the job is done…

Nigel

PS the changes to util.js seem to be doing the trick – no disconnect/connect showing yet!

Professor Nigel Gilbert, CBE, ScD, FREng, FAcSS, Professor of Sociology, University of Surrey, Guildford GU2 7XH, UK. +44 (0)1483 689173

[ellisonbg]

A few observations about these types of things from the perspective of Jupyter (another large open source community).

First, project maintainers are always wrestling with increasing scope. It is fairly easy for the scope of a becoming-popular open source project to outgrow the current maintainer base. As a result of this, maintainers needs to be careful about decisions that increase the scope.

Second, at the same time, a growing projects will want to enable a broader ecosystem and community of practice to grow around the project. Building extensible software enables that. So in this case, I think the core question is this: can a user/operator of Yjs accomplish this without the change in master? Given the current best practices of TLS/SSL, I think the answer is yes. Can it be done using this simple approach - not as easily, but still possible using something like https://github.com/http-party/node-http-proxy for non-containerized deployments. Still, I think it is an important to look at this package to make sure it is as extensible as possible.

Third, it can be helpful to have a place in the documentation for third party projects that extend the core project, to help others to find it.

[dmonad]

Thanks for sharing your insights @ellisonbg.

I haven't done a good job explaining the y-websocket server. I see it as a good starting point for new projects. But eventually, every serious project needs to fork the y-websocket server because there is no common solution to solve authentication and user-management. I see the backend implementation (/bin/server.js) more as a starting point for your own project.

This is another reason why I want to keep it simple.

It would be great to have more opinionated backends that work with y-websocket. Maybe I should advertise that users can publish compatible modules.