UNPKG

webp2p

Version:

The server-less signaling channel for WebRTC

webp2p.io

ShareIt-project/WebP2P.io

86 lines (57 loc) • 3.3 kB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
The protocol is mainly focused on WebRTC DataChannels, Javascript and ArrayBuffers, but it could be implemented over other technology that allow manipulation and transmission of binary data. # Messages ## Regular messages * ttl: [1 byte] = 5 * data: [encrypted data] A 'ttl' field greater that zero means it's a valid, cyphered message. The 'data' field is encrypted with the destination peer sessionID, so only it can decode the message using its session private-key. Each peer that receive the message MUST to try to decode it with its session private-key to identify if they are the receipts, and if so process it accordingly. ## Encrypted data field ### Common fields * method: [1 byte] = error=-1 | offer|answer|authenticate|candidate * id: [1 byte] = message ID Errors are defined by negative numbers (0x80-0xFF) in the 'method' field Message ID is generated on a per-destination basis, so this way it can be more constrained. Total size: 1+1 = 2 bytes ### Error * data: [1192-(1+2) = 1189 bytes] ### Offer * from: [sessionID] = session public-key * sdp: [1192-(1+2)-256 = 933 bytes] ### Answer * sdp: [1192-3 = 1189 bytes] ### Authenticate * timestamp: [8 bytes] * signature: [256 bytes] = signature with userID over timestamp (digest-like) to identify & authenticate Total size: 2+8+256 = 266 bytes Total message size: 1+266 = 267 bytes ### Candidate * sdp: [1192-3 = 1189 bytes] ## Map of messages | Error | Presence | Offer | Answer | Authenticate | Candidate | |----------|===========|==========|==========|==========|===============|===========| | 0 | ttl=5 | ttl=0 | ttl=5 | ttl=5 | ttl=5 | ttl=5 | |----------|===========|----------|==========|==========|===============|===========| | 1 | method=-1 | from | method=1 | method=2 | method=3 | method=4 | |----------|-----------| (256) |----------|----------|---------------|-----------| | 2 | id | | id | id | id | id | |----------|-----------| |----------|----------|---------------|-----------| | 3-10 | data | | from | sdp | timestamp (8) | sdp | |----------| (1189) | | (256) | (1189) |---------------| (1189) | | 11-256 | | | | | signature | | |----------| |==========| | | (256) | | | 256-258 | | | | | | | |----------| | |----------| | | | | 259-266 | | | sdp | | | | |----------| | | (933) | |===============| | | 267-1192 | | | | | | | |----------|===========| |==========|==========| |===========| # Encryption scheme The encryption scheme is build around public keys, one randomly created for each session to anonimize data transmission (sessionID), and another one to identify and authenticate the user between sessions (userID). The presence message send as payload the new peer sessionID, that