Skip to content

A barebones WebRTC implementation in Scratch 3 Extension blocks.

License

Notifications You must be signed in to change notification settings

cloudlink-omega/scratch3-webrtc

Β 
Β 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 

History

17 Commits
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

WebRTC barebones for Scratch

Barebones WebRTC for Scratch 3

A slimmed-down version of the CL5 protocol extension, designed to offer a basic implementation of the WebRTC standard for Scratch 3.

Usage

Creating connection objects

For every connection you want to make, you must initialize a new RTCPeerConnection object. Use this block to get started.

create peer connection block

You can check a list of all existing objects using this reporter. I suggest using a JSON extension to simplify this for you.

all peer connection objects reporter

You can use this reporter to list all active and connected objects instead:

all connected peers reporter

Disclaimers

⚠️ Since this is a barebones implementation of WebRTC, there is no automated signaling for you. You are solely responsible for negotiating connections.

πŸ‘ WebRTC does not specify any transport for signaling, so this provides you plently of room for freedom.

This could be accompished via:

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.

Signaling flow

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.

create peer connection block

Alice will use this block to create a offer for Bob:

make offer block

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!

offer reporter

Now, on Bob's device, Bob will take Alice's Base64-encoded offer and generate an answer:

make answer block

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!!!

answer reporter

On Alice's end, she will take Bob's answer and handle it:

handle answer block

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:

gather ice candidates 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!

ice candidates reporter

On opposing ends, Alice or Bob can accept their respective ICE candidates using this handler:

handle ice block

After this point, Alice and Bob's browsers will silently establish a connection, and they can now send data!

Sending data

To send data, simply use this block:

send data block

On the other end, use this reporter to read the received data:

received data reporter

Channels

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.

create channel block

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).

close channel block

If you need to check if a channel exists, you can use this boolean block:

does channel exist boolean

Closing connections

When you are done, you can close the connection by using this block:

close connection block

All data channels will be silently closed, and the peer connection object will be destroyed.

About

A barebones WebRTC implementation in Scratch 3 Extension blocks.

Topics

Resources

License

Stars

Watchers

Forks

Languages

  • JavaScript 100.0%