SpellCast

Spellcast is a free WebRTC Twitter alternative!

(Serverless, P2P, encrypted)

Spellcast: Cast your words freely! The serverless, P2P encrypted Twitter alternative that puts your privacy first. Connect directly, communicate securely—no servers, just people.

Make sure that the peers you want to send your message to are ONLINE. Because only then will they receive your message (P2P).

Spellcast is a prototype, not everything works quickly or reliably!

How to use Spellcast?

Exchange your PeerID with a Friend and go to the Connect Tab and paste it under "Connect to a peer by ID: ". You can also scan the QR code, but you have to insert it manually.

A connection should be made. When your friends state is "Online", you can Post messages on your Feed and everyone connected to you can read your messages!

Want to Help?

Get the code and report bugs. Correct the code, add features and make pull requests!

https://github.com/SiENcE/spellcast

What is WebRTC?

WebRTC (Web Real-Time Communication) is an peer-to-peer connections between two browsers. It enables the creation of connections without the need for a server. (Do not get confused; a server is required initially, but once the connection is established, it will not require a server for peer-to-peer communication.)

WebRTC is encrypted by default when used for browser-to-browser communication over the internet. WebRTC uses several security mechanisms:

1. All WebRTC media streams (audio, video, data) are encrypted using DTLS (Datagram Transport Layer Security) and SRTP (Secure Real-time Transport Protocol).

2. DTLS is used for key exchange during the initial connection setup.

3. After the connection is established, media is encrypted with SRTP, which provides confidentiality, message authentication, and replay protection.

4. The data channels in WebRTC use SCTP (Stream Control Transmission Protocol) over DTLS for encryption.

This encryption happens automatically without requiring any special configuration from developers or users. Even when WebRTC connections go through TURN servers for NAT traversal, the content remains encrypted end-to-end between peers.

There are some limitations to WebRTC. Since WebRTC uses UDP, which is not an ideal protocol for exchanging data, it can be problematic. UDP sends data very quickly but does not check bit by bit (no data validation). Therefore, using WebRTC with UDP may result in data loss, making it unsuitable for sending sensitive data, as that data could be corrupted.

Why use WebRTC?

However, if we are exchanging video or audio data, where losing a few frames is not a big deal, WebRTC is ideal for fast real-time communication.

How WebRTC work?

Step 1:

• Initially, a server called a “signaling server” is needed to establish the connection between two peers. Once the connection between two peers is established, the server is no longer needed.
• First, Client-1 will send some data about itself to the signaling server, which then transfers that data to Client-2. Then, Client-2 also sends some data about itself to Client-1 through the signaling server. Now, both clients know each other.
• The duty of the signaling server is to establish the connection between peers by exchanging details about them.
• The first step of a WebRTC connection is the creation of offers. An offer is like an object containing information about Client-1. It includes something called SDP (Session Description Protocol), which contains the media configuration of Client-1.
• This offer is then sent to the server from Client-1 and directed to Client-2. Client-2 stores the offer, including the SDP, of Client-1. Then, Client-2 creates the answer for that offer. The answer contains the SDP of Client-2 and is directed to Client-1 over the signaling server.
• Now, with that exchange, Client-1 and Client-2 know each other but do not yet know “how to communicate with each other.”

Step 2: Figure out how to connect to each other. For that, they have to transfer their network information to each other.

• As soon as Client-1 makes the offer, something called “ICE Candidates” (ICE: Interactive Connectivity Establishment) are generated by the WebRTC API.

Where do these ICE candidates come from?

• ICE candidates are generated from servers known as “STUN (Session Traversal Utilities for NAT) and TURN Servers”. To obtain ICE candidates from these servers, Client-1 needs to provide URLs of the STUN and TURN servers to the WebRTC API. Once Client-1 makes the offer, the WebRTC API retrieves the ICE Candidates from the STUN & TURN servers.
• Then, Client-1 sends these ICE candidates to Client-2 through the Signaling Server. Similarly, when Client-2 makes the answer to that offer, it sends the ICE Candidates of Client-2 to Client-1 via the Signaling Server.
• With this exchange, both Client-1 and Client-2 have the network information of each other, enabling them to communicate directly.