2 ms·

jupyter-collaboration is built on Y Documents (y.js, pycrdt, jupyter_ydoc,) https://github.com/jupyterlab/jupyter-collaboration https://github.com/jupyterlab/ju

jupyter-collaboration is built on Y Documents (y.js, pycrdt, jupyter_ydoc,) https://github.com/jupyterlab/jupyter-collaboration https://github.com/jupyterlab/jupyter-collaboration There is a y.js WebRTC adapter, but jupyter-collaboration doesn't have WebRTC data or audio or video support AFAIU. y-webrtc: https://github.com/yjs/y-webrtc https://github.com/yjs/y-webrtc Is there an example of how to do CRDT with PulseBeam WebRTC? With client and serverside data validation? > JWT Is there OIDC support on the roadmap? E.g. Google supports OIDC: https://developers.google.com/identity/openid-connect/openid-connect https://developers.google.com/identity/openid-connect/openid... W3C DIDs, VC Verifiable Credentials, and Blockcerts are designed for decentralization. STUN, TURN, and ICE are NAT traversal workarounds FWIU; though NAT traversal isn't necessary if the client knowingly or unknowingly has an interface with a public IPV6 address due to IPV6 prefix delegation?

lherman 2y ago
We don't have an example of CRDT with PulseBeam yet. But, CRDT itself is just a data structure, so you can use PulseBeam to communicate the sync ops (full or delta) with a data channel. Then, you can either use y.js or other CRDT libraries to manage the merging. Yes, the plan is to use JWT for both the client and server side. OIDC is not on the roadmap yet. But, I've been tinkering on the side related to this. I think something like an OIDC mapper to PulseBeam JWT can work here. I'm not envisioning integrating into a decentralization ecosystem at this point. The scope is to provide a reliable service for 1:1 and small groups for other developers to build on top with centralization. So, something like Analytics, global segmented signaling (allow close peers to connect with edge servers, but allow them to connect to remote servers as well), authentication, and more network topology support. That's correct, if the client is reachable by a public IPv6 (meaning the other peer has to also have a way to talk to an IPv6), then STUN and TURN are not needed. ICE is still needed but only used lightly for checking and selecting the candidate pair connections.
- westurner 2y ago
  [dead]

lherman 2y ago

We don't have an example of CRDT with PulseBeam yet. But, CRDT itself is just a data structure, so you can use PulseBeam to communicate the sync ops (full or delta) with a data channel. Then, you can either use y.js or other CRDT libraries to manage the merging. Yes, the plan is to use JWT for both the client and server side. OIDC is not on the roadmap yet. But, I've been tinkering on the side related to this. I think something like an OIDC mapper to PulseBeam JWT can work here. I'm not envisioning integrating into a decentralization ecosystem at this point. The scope is to provide a reliable service for 1:1 and small groups for other developers to build on top with centralization. So, something like Analytics, global segmented signaling (allow close peers to connect with edge servers, but allow them to connect to remote servers as well), authentication, and more network topology support. That's correct, if the client is reachable by a public IPv6 (meaning the other peer has to also have a way to talk to an IPv6), then STUN and TURN are not needed. ICE is still needed but only used lightly for checking and selecting the candidate pair connections.

westurner 2y ago
[dead]