### Changed
- Examples: JS examples uses local ESM folder to replicate behaviour of
js-waku publish package.
### Fixed
- `TypeError` issue related to constructors using js-waku in a JS
project
([#323](https://github.com/status-im/js-waku/issues/323)).
### Added
- If the `callback` function passed to`WakuStore.queryHistory` returns
`true`, then no further pages are retrieved from the store.
- Use webpack to build UMD bundle of the library, see
[README](./README.md) for usage.
### Changed
- **Breaking**: Renamed `WakuStore.QueryOptions`'s `direction` to
`pageDirection` (and its type) as it only affects the page ordering,
not the ordering of messages with the page.
### Fixed
- Docs: Ensure that `WakuStore`'s `QueryOptions` documentation is
available [online](https://status-im.github.io/js-waku/docs/).
### Added
- Examples: New Ethereum Private Message Using Wallet Encryption
[Web App](./examples/eth-pm-wallet-encryption/README.md)
example that demonstrates the usage of `eth_encrypt` API (available on
Metamask) and EIP-712 for typed structured data signing.
- New `bootstrap` option for `Waku.create` to easily connect to Waku
nodes upon start up.
- Support for `startTime` and `endTime` in Store queries to filter by
time window as per [21/WAKU2-FTSTORE](https://rfc.vac.dev/spec/21/).
### Changed
- Renamed `discover.getStatusFleetNodes` to
`discovery.getBootstrapNodes`;
Changed the API to allow retrieval of bootstrap nodes from other
sources.
- Examples: Renamed `eth-dm` to `eth-pm`; "Direct Message" can lead to
confusion with "Direct Connection" that
refers to low latency network connections.
- Examples (eth-pm): Use sign typed data EIP-712 instead of personal
sign.
- Upgraded dependencies to remove warning at installation.
- **Breaking**: Moved `DefaultPubSubTopic` to `waku.ts` and fixed the
casing.
- **Breaking**: Rename all `pubsubTopic` occurrences to `pubSubTopic`,
across all interfaces.
### Removed
- Examples (cli-chat): The focus of this library is Web environment;
Several examples now cover usage of Waku Relay and Waku Store making cli-chat example obsolete;
web-chat POC should be preferred to use the [TOY-CHAT](https://rfc.vac.dev/spec/22/) protocol.
- `ChatMessage` has been moved from js-waku to web-chat example;
it is a type used for the [TOY-CHAT](https://rfc.vac.dev/spec/22/) protocol;
js-waku users should not build on top if this toy protocol and instead design message data structures appropriate to their use case.
- Unused dependencies & scripts.
It is a type used for the [TOY-CHAT](https://rfc.vac.dev/spec/22/)
protocol;
js-waku users should not build on top if this toy protocol and instead
design message data structures appropriate to their use case.
The focus of this library is on Web environment; Several examples now
cover usage of Waku Relay and Waku Store; web-chat POC should be
preferred to use the [TOY-CHAT](https://rfc.vac.dev/spec/22/) protocol.
### Added
- Relay and ReactJS guides and examples
([#56](https://github.com/status-im/js-waku/issues/56)).
### Changed
- **Breaking**: The `WakuMessage` APIs have been changed to move
`contentTopic` out of the optional parameters.
### Removed
- Examples (web-chat): Remove broken `/fleet` command.
- **Breaking**: Removed `DefaultContentTopic` as developers must choose
a content topic for their app; recommendations for content topic can
be found at https://rfc.vac.dev/spec/23/.
### Fixed
- `WakuMessage.payloadAsUtf8` returning garbage on utf-8 non-ascii
characters.
- `ChatMessage.payloadAsUtf8` returning garbage on utf-8 non-ascii
characters.
As developers must choose a content topic for their app.
The`WakuMessage` APIs have been changed to move `contentTopic` out of
the optional parameters. Recommendations for content topic can be found
at https://rfc.vac.dev/spec/23/.
It does not work as it can lead to infinite loops due to the handling of
the Waku instance. It should disconnect and reconnect to peers instead
of starting a new waku instance.
..on `Waku` with a default to 5min to send ping messages over relay
to ensure the relay stream stays open.
This is a workaround until
[js-libp2p#744](https://github.com/libp2p/js-libp2p/issues/744) is done
as there are issues when TCP(?) timeouts and the stream gets closed.
### Added
- Examples (web-chat): New `/fleet` command to switch connection between
Status prod and test fleets.
- Export `generatePrivateKey` and `getPublicKey` directly from the root.
- Usage of the encryption and signature APIs to the readme.
### Changed
- **Breaking**: Renamed `WakuRelay.(add|delete)PrivateDecryptionKey` to
`WakuRelay.(add|delete)DecryptionKey` to make it clearer that it
accepts both symmetric keys and asymmetric private keys.
### Fix
- Align `WakuMessage` readme example with actual code behaviour.
### Added
- `WakuRelay.deleteObserver` to allow removal of observers, useful when
a React component add observers when mounting and needs to delete it
when unmounting.
- Keep alive feature that pings host regularly, reducing the chance of
connections being dropped due to idle.
Can be disabled or default frequency (10s) can be changed when calling
`Waku.create`.
- New `lib/utils` module for easy, dependency-less hex/bytes
conversions.
- New `peers` and `randomPeer` methods on `WakuStore` and
`WakuLightPush` to have a better idea of available peers;
Note that it does not check whether Waku node is currently connected
to said peers.
- Enable passing decryption private keys to `WakuStore.queryHistory`.
- Test: Introduce testing in browser environment (Chrome) using Karma.
- Add support for Waku Message version 1: Asymmetric encryption,
symmetric encryption, and signature of the data.
### Changed
- **Breaking**: Auto select peer if none provided for store and light
push protocols.
- Upgrade to `libp2p@0.31.7` and `libp2p-gossipsub@0.10.0` to avoid
`TextEncoder` errors in ReactJS tests.
- Disable keep alive by default as latest nim-waku release does not
support ping protocol.
- **Breaking**: Optional parameters for `WakuMessage.fromBytes` and
`WakuMessage.fromUtf8String` are now passed in a single `Options`
object.
- **Breaking**: `WakuMessage` static functions are now async to allow
for encryption and decryption.
- **Breaking**: `WakuMessage` constructor is now private, `from*` and
`decode*` function should be used.
- `WakuMessage` version 1 is partially supported, enabling asymmetrical
encryption and signature of messages;
this can be done by passing keys to `WakuMessage.from*` and
`WakuMessage.decode*` methods.
- Examples (eth-dm): Use Waku Message version 1 encryption scheme
instead of `eth-crypto`.
- Examples (eth-dm): Use Protobuf for direct messages instead of JSON
([#214](https://github.com/status-im/js-waku/issues/214)).
### Fixed
- Disable `keepAlive` if set to `0`.
### Changed
- **Breaking**: Websocket protocol is not automatically added anymore
if the user specifies a protocol in `libp2p.modules` when using
`Waku.create`.
- **Breaking**: Options passed to `Waku.create` used to be passed to
`Libp2p.create`; Now, only the `libp2p` property is passed to
`Libp2p.create`, allowing for a cleaner interface.
- Examples (cli chat): Use tcp protocol instead of websocket.
### Added
- Enable access to `WakuMessage.timestamp`.
- Examples (web chat): Use `WakuMessage.timestamp` as unique key for
list items.
- Doc: Link to new [topic guidelines](https://rfc.vac.dev/spec/23/) in
README.
- Doc: Link to [Waku v2 Toy Chat specs](https://rfc.vac.dev/spec/22/) in
README.
- Examples (web chat): Persist nick.
- Support for custom PubSub Topics to `Waku`, `WakuRelay`, `WakuStore`
and `WakuLightPush`;
Passing a PubSub Topic is optional and still defaults to
`/waku/2/default-waku/proto`;
JS-Waku currently supports one, and only, PubSub topic per instance.
Due to #201, Websocket protocol is not added by default if the caller
specifies a protocol for libp2p.
In the case cli-chat. We were using both tcp and ws.
As the web-chat already demonstrates usage of websocket protocol, we
cli-chat to tcp only.
Note that we currently only support one, and only one, pubsub topic for
a given instance across the codebase. The PubSub topic needs to be set
when instantiating the Waku* classes.
At this stage, we believe that most DApp will use, and only use, the
default PubSub topic. Some application want to use an alternative topic
but not use the default one so this behaviour should be fine. See #174
for details.
F
Franck Royer