0.0.10

Angular 21 support and the new API for managing listen connection filters:

// new getter/setter
peer.connectionFilters; // get current filters
peer.connectionFilters = [
  /* filters */
]; // set new filters

// listen changes
peer.listen(); // will use existing filters and start listening
peer.listen(newFilters); // will replace filters and start listening

Features

• add API to change listen connection filters (91e266c)

Fixes

• clean up .listen() API types (d363169)
• don't crash when trying to listen/connect in SSR environment (1aca6cc)

0.0.9

Features

• provide default value for enableLogging() (3043f82)

Fixes

• allow reconnecting with the same peer id (20cbc51)

0.0.8

Introduces the new .listen() API and adds support for Angular 20.

New listening API

Listening happens in the background until you stop it explicitly. This allows you to start listening for handshake from multiple peers at once, using a variety of ways to accept or decline incoming connections.

// start listening for specific incoming connections
const stop = peer.listen(/* filter using ids, objects, or a custom function */);

// stop listening
stop();

Features

• Introduce the new .listen() API (dc1907c)
• Introduce the Peer.peerConnections API and harmonize connection messages (668c8d2)
• Expose 'handshake' message to the user in serviceMessages (55b83a2)

Fixes

• MessagePeerService should disconnect and stop listening in ngOnDestroy(9feba99)

BREAKING CHANGES

• new .listen() API returns a function that stops listening

// BEFORE
const disconnect = await peer.listen('foo'); // start listening for 'two'
disconnect(); // disconnect, no way you can stop listening

// AFTER
const stop = peer.listen('foo'); // start listening
stop(); // stop listening
peer.disconnect('foo'); // disconnect from peer 'two'

• new .listen() API changes the way of listening for multiple connections

// BEFORE
peer.listen('foo'); // start listening for 'foo'
peer.listen('bar'); // start listening for 'bar' <- this will not work as expected before

// AFTER
// In new version the example above would not work
// it would stop listening for 'foo' and start listening for 'bar'.
// Ideally you should call `.listen()` only once. ex:
peer.listen(['foo', 'bar']); // start listening for connections from both 'foo' and 'bar'
// or
peer.listen(); // allow any connection unitl stopped listening
// or
peer.listen((message, source, origin) => {
  // accept or decline connection based on the handshake message, source and origin
  return ['foo', 'bar'].includes(message.from);
});

0.0.7

Features

• Export VersionedMessage type (ac60200)

0.0.6

Relaxes Message type to make version optional. This allows to send messages without versioning by default.

Introduces the ability to configure how messages are validated with messageCheckStragegy option:

const peer = new MessagePeer({
  id: 'one',
  messsageCheckStrategy: 'version',
});

Check strategy can be one of default | type | version. By default, only the message structure is checked, with type it is checked that the message type is known to the peer upn reception, with version it is checked that the message type is known to the peer and the version is compatible with the peer.

With default check strategy, the knownMessages becomes optional.

Features

• Make version optional in the Message interface (d7d671b)
• Allow changing how messages are checked upon reception (1175331)

Fixes

• Handle calling .connect() twice correctly (2fca710)
• Handle calling .listen() twice correctly (c76367f)
• Don't queue service messages like disconnect at peer level (3ba12a8)

BREAKING CHANGES

• You might want to use Required<Message> instead of Message if you want to ensure version is mandatory for your message handling.
• By default, message version and type checks are optional. Previous behaviour can be restored by setting messageCheckStrategy to version:

const peer = new MessagePeer({
  id: 'one',
  messageCheckStrategy: 'version',
  knownMessages: [],
});

0.0.5

New .messages, .serviceMessages and .errors API that make it easier to dissociate peer creation with and places where messages might be consumed. It uses Obsevable and rxjs compatible implementation for streams of messages.

Features

• Introduce new APIs for message consumption (1216d49)

Fixes

• Throw an error if provided origin is invalid in .connect() or .listen() calls (db062bf)

BREAKING CHANGES

• No longer possible to get messages via onMessage, onServiceMessage and onErrorat construction time, one should use.messages, .serviceMessages and .errors subscribable streams:

// BEFORE
const peer = new MessagePeer({
  id: 'one',
  onMessage: (m) => {},
  onServiceMessage: (m) => {},
  onError: (e) => {},
});

// AFTER
const peer = new MessagePeer({ id: 'one' });

peer.messages.subscribe((m) => {});
peer.serviceMessages.subscribe((m) => {});
peer.errors.subscribe((e) => {});

0.0.4

Features

• Exception during message validation upon reception now reported back to original sender via ErrorMessage (db468df)

Fixes

• Messages .send() before connection is established are now cached and sent after connection is established (8e6b7cf)
• Fixed throwing errors when receiving a postMessage from 3rd party libraries (bb41141)
• ConnectMessage now is sent before any queued user messages, not after (d02ef3d)

0.0.3

Features

• Publish CommonJS, ESM and minified bundle (c3a84f9)
• Add enableLogging() method to configure debugging logging that is off by default(b81ad27)

BREAKING CHANGES

• Service messages like ConnectMessage, DisconnectMessage have their own callback now:

// Before
let peer = new MessagePeer<M>({
  onMessage: (m: M) => {}, // both user and service messages
});

// After
let peer = new MessagePeer<M>({
  onMessage: (m: M) => {}, // only user messages
  onServiceMessage: (m: ServiceMessage) => {}, // only service messages
});