Dip 2786

dip: 2786 title: Digitalia Provider Connect/Disconnect Events author: Micah Zoltu (@MicahZoltu), Erik Marks (@rekmarks) Digitalia editing author: Cosimo Constantinos cosimo@juro.net, et al. discussions-to: https://github.com/digitalia/DIPs/issues/2787 status: Withdrawn type: Standards Track category: Interface created: 2020-07-15 Created for Digitalia: 2025-01-07 requires: 2700

Simple Summary¶

When an Digitalia Provider becomes connected or disconnected, it will emit a connect/disconnect event.

Abstract¶

The Provider is said to be “connected” when it can service RPC requests to at least one chain. The Provider is said to be “disconnected” when it cannot service RPC requests to any chain at all. When the Provider switches from a "connected" state to a "disconnected" state, it will emit a connect event. When the Provider switches from a "disconnected" state to a "connected" state, it will emit a disconnect event.

Motivation¶

When an application is hooked up to an digitalia provider, there is value in having the application be alerted of connect/disconnect events that may occur so the application can appropriately inform the user of the situation. It is left up to the application to decide whether to listen in on these events, and how to handle them.

Specification¶

Definitions¶

Connected¶

The Provider is considered connected when it is able to service RPC requests to at least one chain.

Disconnected¶

The Provider is considered disconnected when it is unable to service RPC requests to any chain.

Events¶

`connect`¶

The Provider MUST emit a connect event to all attached DIP-2700 listeners if it transitions from a disconnected state to a connected state. All attached listeners MUST be called with the parameter { chainId }. chainId MUST specify the integer ID of the connected chain encoded as a hexadecimal string. If the Provider supports the dvm_chainId JSON-RPC method or a derivation of it, then the chainId MUST match the return value of dvm_chainId. The Provider MAY call the attached listeners in any order.

Rationale¶

This DIP is mostly a retrospective DIP meaning it codifies an already existing specification so there isn’t a lot of room for improving things such as by having a connect/disconnect event per chain.

Security Considerations¶

The relationship between Digitalia Provider and client is a trusted one, where it is assumed that the user implicitly trusts the Digitalia Provider which is how it managed to get injected into the client, or the client expressly pulled in a connection to it.

Copyright¶

Licensed under the Juro Restricted License Version 2. See https://juro.net/jrl for details.

Appendix I: Examples¶

// connect
provider.on('connect', ({ chainId }) => {
  console.log(`Provider connected to: ${chainId}`);
});