If I use my desktop on my home wifi, and my mobile phone using data, the two sliders do not sync.

Tom Larkworthy

Reading the docs 

"If two peers are connected to the same signaling server and accessing the same collaboration room, they can now find each other and establish a connection between them."

So maybe my phone is not accessing the same set of signalling servers for some reason. Bit weird, I feel like it should work out of the box.

Tried that myself as well, but didn't run into that issue. Have been seeing slider updates by unknown peers also, so will try and see where this issue is coming from.

(In this case, unknown peers updating the shared state seems like it's working to some extent)

As per Fabian's logging suggestion, you can now see that phone/other connections fail to establish under certain circumstances; could use some help investigating this!

I've added a peer view; while cellular connections are able to join the room, updates are not propagated it seems. Needs more investigating, it is possible Websocket connections over cellular networks may require additional settings (ice, port forwarding, else?)

'Webrtc works ~90% of the time' according to @https://discuss.yjs.dev/t/signalling-server-on-different-network/133/2.

An additional y-websocket provider could be used as fallback in these conditions. Possibly a usecase for webcode.run?

Encrypted websocket (WSS) is pretty robust as it looks like https traffic to firewalls so its difficult to block. webRTC is more likely the issue as thats a completely different category of traffic which a firewall or cell network might not support. 

On my phone I see my desktop peer, but it seems communication is not working between them, so its the WEBRTC bit. Will need another bit to work in more cases

I am running chrome://webrtc-internals/ in another tab in the background on both devices to see what is happening.

Most notably, iceconnectionstatechange (legacy): failed when a (Chrome) cellular android connection is established, pointing to the need of a TURN server. Yet, changing the iceServer settings to a TURN server (e.g. https://www.metered.ca/tools/openrelay/) does not solve the issue.

I've found a suitable iceServer / TURN configuration now. If it still is not working for you, try redirecting the `provider` to use one signalling server only (e.g. `wss://signaling.yjs.dev)` .

Nice one! I am envisioning a webcode.run wrapper as an 'always on' peer that keeps track of a notebooks when users log off. Rather that using a yJs database provider (e.g. y-indexeddb), this might be able to distribute smallish state/datasets on the fly while not storing anything on the user end.

Webcode instances are horizontally scaled and ephemeral (like lambda), I use firebase or redis for storage. 
Actually there is already a redis provider, maybe we can get it to work with browser redis inside a webcode env

https://github.com/yjs/y-redis + https://observablehq.com/@tomlarkworthy/redis inside webcode.run. Here is a notebook using the redis driver https://observablehq.com/@tomlarkworthy/redis-backend-1