Closed jwaldmann closed 2 years ago
Seems like you aren't seeing each other. Flok tries to use WebRTC first, then WebSockets, to sync changes. Maybe neither are working on your setup. This happened quite often when I was using only WebRTC, but I've seen WebSockets fixed those cases.
Right now Flok is using an external signaling server, maybe it went down or you can't access it from your network (it's wss://demos.yjs.dev right now). See https://github.com/munshkr/flok/blob/d7ba42ba32946061b0715f27685da8174d717f9c/packages/web/lib/SessionClient.ts#L92 Flok should set up its own signaling server actually, but haven't landed that yet. You can try to change it to another one and see if that fixes the problem on your end. Any signaling server should do.
REPL works because that uses a custom Websocket server, not Yjs backends.
Interesting! Yes, quite possibly my firewall blocks things.
Would that explain that it works between two clients from the same IP?
Can I avoid WebRTC/the signalling server altogether? Then it should work with websockets, regardless of IP?
I am a bit cautious about data privacy - for myself, and for my students. I am teaching at a state university, so I want to set a good example - and I have to, at least in my reading of the law. Although, maybe, that ship has long sailed, with all the rogue vidoeconferencing ...
Can I avoid WebRTC/the signalling server altogether?
Let me check how it is setup, actually there might be something wrong there. In theory, the WebRTC falls back to WebSockets if it fails, so it should've worked...
I am a bit cautious about data privacy - for myself, and for my students. I am teaching at a state university, so I want to set a good example - and I have to, at least in my reading of the law. Although, maybe, that ship has long sailed, with all the rogue vidoeconferencing ...
That's perfectly reasonable, and you are setting a good example! We should make the effort to keep it that way :) One of my main goals from the start was to have an accessible but also a self-hosted application, and be mindful of the security issues involved, as much as possible (still trying to reach/keep it...)
Good! - I don't know these technologies too well - how could I learn about the communication that is supposed to happen (between flok clients, flok server, possibly external server) when using the various methods?
For reference - we use BBB for lectures but I have to admit that I am not completely sure of its inner workings (e.g., TURN - "to bypass firewalls" - sounds scary). I hoped that flok is simpler - it sends only text. Well, at least in the configuration that I use. I am aware that it can do more.
Unfortunately, I also had to read a bit about TURN and STUN servers, they are really needed for WebRTC to work :( I had to set up a TURN and STUN server on flok.clic.cf myself, and even then, there were some users that still had issues seeing each other. I found out later that it covers most cases but is not infallible. So, I went back to Websockets as a fallback.
You can check the Yjs README, it explains a bit about the algorithm it uses (CRDT), and how to combine different backends. I might have made a mistake somewhere, or maybe an Yjs bug too.
I think the relevant code in Flok is in the lib/SessionClient.ts
if you want to try something (maybe as you said, disabling the WebRTC provider and using only WebSockets might work).
[EDIT] my uMatrix had blocked yjs.dev. Aha! now I am getting some communication. Sorry for the noise.
I am confused now. Is it like this:
And then what I observe here is that communication between web clients only works if they are in two tabs within one browser - because there's some fallback somewhere that does avoid the external WS server altogether - in just that case?
About uMatrix: Nice! Good to know, I should prioritize changing that yjs server (it was meant to be temporary). flok-web should fire up its own websockets server for that...
And then what I observe here is that communication between web clients only works if they are in two tabs within one browser - because there's some fallback somewhere that does avoid the external WS server altogether - in just that case?
Yes :) WebRTC handles that automatically. It first tries to resolve it on LAN, then goes outside.
Maybe this helps (I should probably re-read everything and check it is working all right): https://bloggeek.me/webrtc-turn/
I am running a session with repl (-n tidal -- safe-tidal-cli) connected. The session has one web client. When another client joins (with a different IP address), it sees an empty buffer, but commands do get sent to the repl. Behaviour is not completely reproducible (client from the same IP address does see the buffer?)
Similar when closing the last web client, and then re-joining. Buffer visibility depends on address?
If it matters: I am running flok-web behind nginx reverse proxy.