For KeyStore and withTrustedKeerKey.

Some projects might want to know the internal signaling state.

As a good server there is e.g. https://github.com/andyet/signalmaster.

Is it possible to use your own servers here?

It has been dropped from the spec.

See saltyrtc/saltyrtc-meta#7

Chrome doesn't support larger messages than 16KiB. https://webrtc.org/web-apis/chrome/

Babel will have solved some of the issues with older browsers.

It might be interesting to provide Angular glue code (i.e. services) for this library (in a separate library).

https://github.com/saltyrtc/saltyrtc-meta/blob/master/Protocol.md#close-message

It should call a sendClose method on the signaling class.

...so that when logging a send-error message, we actually know which message was lost.

The WebRTC task spec should now be stable and is ready to be implemented.

saltyrtc/saltyrtc-meta#33

Having to set the public key as well is confusing as it can be retrieved from the private key.

See client-auth message

Apparently it currently stays open.

Steps to reproduce:

• Open demo application
• Connect both peers
• Disconnect app
• Reconnect app
• Web receives this ws message

Typescript should be able to generate .d.ts files with the public API.

Some functionality like this.

• Signaling.encryptHandshakeDataForServer(...)
• Signaling.encryptHandshakeDataForPeer(...)

...could be moved into the Peer class. Then polymorphism could replace if-else statements.

As discussed in saltyrtc/saltyrtc-meta#34

interface Event {
    type: string,
    data: any,
}

type EventHandler = (ev: Event) => boolean | void;

// Register an event handler
on(event: string | string[], handler: EventHandler): void;

// Run an event handler only once
once(event: string | string[], handler: EventHandler): void;

// Cancel an event handler
off(event: string | string[], handler?: EventHandler): void;

• Base events are connected, connection-error, connection-closed and data
• The data event can be specialized, e.g. data:offer will only match events where offer matches the dataType
• If a handler returns false, the corresponding listener will be removed
• An event can be registered or deregistered for multiple events by passing in an array
• If the handler is omitted in the off(event) call, all handlers will be removed
• If an event handler is already registered, it is not registered a second time

Examples:

// Classic event handler
salty.on('connected', (event) => console.log('SaltyRTC is connected'));

// One-time event handler
salty.once('data', (event) => console.log('The first message arrived.'));

// Data event handler that can remove itself
salty.on('data', (event) => {
  if (event.data.dataType === 'panic') {
    console.error('everybody panic');
    return false;
  }
});

// Specialized event handler(s)
salty.on(['data:offer', 'data:answer'], (event) => {
  console.log('A', event.type, 'event is being handled');
  let dataMessage = event.data;
  console.info('Message', dataMessage.dataType, 'with value', dataMessage.data);
});

// Deregistration
function acceptPranswer(event) {
  console.log('pranswer arrived');
}
salty.on('data:pranswer', acceptPranswer);
salty.once('data:answer', (event) => {
  console.log('final answer arrived');
  // Don't accept pranswers anymore
  salty.off('data:pranswer', acceptPranswer);
});

I guess the readme is simply outdated? It lacks setting a task. Or is there a default task?

We could support keeping the ws connection open after a send-error message to wait for a reconnect.

See 9d5abca

The terminology used is not consistent.

What are minimal required browsers?

Go through spec and make sure that everything is implemented correctly.

Right now all classes are exposed as AngularJS services. That's not relevant here and can be removed.

This also means that the logging system needs to be replaced.

The 'drop-responder' message has been changed. An initiator MAY now add a reason field to a 'drop-responder' message the server SHALL close the connection to the corresponding responder with. That field contains a close code described here

When to use the reason field has been described here.

The 'close' message has been added.

All WebRTC-related messages have been removed from the spec and will be moved into a separate task soon. I'll use a new branch for that.

See changes from saltyrtc/saltyrtc-meta#47

We should be able to test the code without any existing webclient.

@lgrahl, do you know what the easiest way would be? Can we test client/server on a single machine?

Integration with Travis would also be welcome.

They fail on Travis.

Create subclasses for Initiator and Responder.

https://github.com/saltyrtc/saltyrtc-meta/blob/master/Protocol.md#client-to-client-messages

Compared to client-to-server messages, protocol errors for client-to-client message MUST be handled differently. In case that any check fails, the procedure below MUST be followed unless otherwise stated:

• If the other client is not authenticated yet, an initiator SHALL drop the corresponding responder by sending a 'drop-responder' message with the responder's address in the id field to the server and a close code of 3001 (Protocol Error) in the reason field. A responder SHALL close the connection to the server with a close code of 3001.
• If the other client is authenticated and the error cause is not a 'send-error' message from the server, the client SHALL send a 'close' message to the other client containing the close code 3001 (Protocol Error). In any case, both clients SHALL terminate the connection to the server (normal close code).

Should we compile-in a copy of the msgpack and nacl libraries?

Pro:

• A single file distribution, simple installation
• Depending on how the packaging is done, saltyrtc will always use a known version of the required libraries, avoiding incompatibilities with other versions of the same library

Con:

• Larger file size
• Separate dependencies required to use
• Conflicts could be possible if the application using saltyrtc also brings along its own msgpack and/or nacl library

@lgrahl what do you think?

Alternatively we could also provide two distributions, a fat and a light one.

• Make sure that peer address != own address
• Validate combined sequence number
• Validate cookie

https://github.com/saltyrtc/saltyrtc-meta/blob/protocol-cleanup/Protocol.md#receiving-a-saltyrtc-signalling-message

On forced connection reset (e.g. when a protocol error occurs), should the task connection also be closed if it's already open?

Right now it's possible that the connection-closed event is thrown twice when closing the connection directly (once in resetConnection and once in onClose).

Maybe there's a way to detect whether the closing was done by us or by the server?

All TODOs left should have an issue number in the comment.

See Close Code Enumeration

The sender byte should always be validated.

Once the handshake is done, messages with a different sender byte should be dropped.

@lgrahl it's correct that they should be silently dropped, right?

The same issue as saltyrtc/saltyrtc-client-java#42 probably applies here too.

It might be possible to create a cleaner solution thanks to the single threaded nature of JS.

There is a new field called subprotocols, see here for details.

Further information can be found here
Discussion in saltyrtc/saltyrtc-meta#19 and saltyrtc/saltyrtc-meta#40

Some messages in the handshake can be sent in parallel, instead of waiting for the other peer.

• Publish prose docs
• Publish API docs
• Update README