A slimmed-down version of the CL5 protocol extension, designed to offer a basic implementation of the WebRTC standard for Scratch 3.
For every connection you want to make, you must initialize a new RTCPeerConnection object. Use this block to get started.
You can check a list of all existing objects using this reporter. I suggest using a JSON extension to simplify this for you.
You can use this reporter to list all active and connected objects instead:
👍 WebRTC does not specify any transport for signaling, so this provides you plently of room for freedom.
This could be accompished via:
- ☁️ Cloud variables (make sure to use encryption, as EVERYONE will be able to see your data)
- 🌐 REST APIs
- 💬 WebSockets
- 🕊️ An army of carrier pigeons... or doves?
Just as long as you got some way to send a message from point A to B, you're set.
🐌🧊 This extension does NOT implement Trickle ICE - Negotiating connections will be slow.
If you want a fully-automated solution with Trickle ICE, consider using CL5 instead.
Let's say that we have two people that want to connect: Alice and Bob.
Both Alice and Bob will create connection objects for the both of them. Alice will create a "Bob" connection object, and Bob will create a "Alice" connection object.
Alice will use this block to create a offer for Bob:
From here, Alice will somehow provide Bob with a Base64-encoded RTCSessionDescription using this reporter's output:
Note: This data is ENCODED; not ENCRYPTED. Make sure to encrypt the offer if you choose to send it over an insecure transport (such as cloud variables). otherwise, very bad things can happen!
Now, on Bob's device, Bob will take Alice's Base64-encoded offer and generate an answer:
Bob will somehow send a Base64-encoded answer to Alice using the value provided by this reporter:
Note: Again, this data is ENCODED; not ENCRYPTED. PLEASE make sure to encrypt it!!!
On Alice's end, she will take Bob's answer and handle it:
At this point, Alice and Bob's browsers need to negotiate the most optimal connection to use. WebRTC utilizes ICE (Interactive Connectivity Establishment protocol) to make this happen.
Both Alice and Bob will need to wait until all ICE candidates are gathered, which can be accomplished using this block:
Once either Bob or Alice has finished gathering ICE candidates, they can send the value of this reporter to each other:
Note: Likewise, this data is ENCODED; not ENCRYPTED. I really, REALLY hope you're encrypting it!
On opposing ends, Alice or Bob can accept their respective ICE candidates using this handler:
After this point, Alice and Bob's browsers will silently establish a connection, and they can now send data!
To send data, simply use this block:
On the other end, use this reporter to read the received data:
All connections will have the default RTCDataChannel, which is configured for ordered and reliable messaging. This sacrifices speed for accuracy.
You can create as many channels as you wish (though there may be a browser limitation to this). You can also create unordered channels to prioritize speed, however, messages might not be seen by the recipient if this mode is chosen.
Once you are done using a channel, you can simply close it (You cannot close the default data channel using this block. You must close the entire connection to do so).
If you need to check if a channel exists, you can use this boolean block:
When you are done, you can close the connection by using this block:
All data channels will be silently closed, and the peer connection object will be destroyed.