chore(interfaces): add methods for gar to ArIO contract interface

[atticusofsparta]

No description provided.

[arielmelendez]

Consider Joins a gateway to the ar.io network via its associated wallet.

[arielmelendez]

Nit that this example might be a little confusing as impossible could be projecting that the example is one that should NOT be followed.

[arielmelendez]

Nit: joinNetworkParams is more helpful.

[arielmelendez]

Nit: order the parameters in a way that logically groups them. e.g. connection settings together, staking settings together, etc.

[arielmelendez]

This type isn't doing much to help make it easy to use this correctly and hard to use incorrectly. For example, how should users think about how label and note are different? How should they think about properties? etc. There's a few things you could do:

• create sub-groupings of these parameters, e.g. connection, staking, operatorInfo, etc.
• add comments next to each of these properties explaining their relevance
• make some of the names less ambiguous (e.g. differentiate between label and note somehow)

[atticusofsparta]

@dtfiedler wdyt:

export type GatewayStakingSettings = {
  allowDelegatedStaking: boolean;
  delegateRewardShareRatio: number;
  minDelegatedStake: number;
  autoStake: boolean;
};

export type GatewayMetadata = {
  label: string;
  note: string;
  properties: string;
};

export type GatewayConnectionSettings = {
  fqdn: string;
  port: number;
  protocol: AllowedProtocols;
};

[dtfiedler]

better

[arielmelendez]

I understand the convenience of all the optionality in this type's fields - a user can simply supply the pieces of info they want to update and one or many/all can be changed in ONE L1 transaction. Yay. However, it creates many possible permutations of ways that one can use this type/function and many ways that things can possibly go wrong. It could be helpful for the user to let them know whether or not partial application of their updates takes place or not if something errors (e.g. is it all or nothing) as well as some basic reasons why things might go wrong, e.g. allowable ranges, lengths, character sets, etc. for certain values.

[atticusofsparta]

Im not understanding the change you have in mind, are you thinking like JSDOC for usage examples?

[dtfiedler]

it's hard with the current contract configuration - but i would do at a minimum something that enforces providing at least one value

// Original type definition refined with proper field-specific types
type UpdateGatewaySettingsParamsBase = {
  allowDelegatedStaking?: boolean;
  delegateRewardShareRatio?: number;
  fqdn?: string;
  label?: string;
  minDelegatedStake?: number;
  note?: string;
  port?: number;
  properties?: string;
  protocol?: AllowedProtocols;
  autoStake?: boolean;
};

// Utility type to require at least one of the fields
type AtLeastOne<T, U = {[K in keyof T]-?: T[K]} > = 
  Partial<U> & U[keyof U];

// Define the type used for function parameters
type UpdateGatewaySettingsParams = AtLeastOne<UpdateGatewaySettingsParamsBase>;

[atticusofsparta]

the above type didnt work but I accomplished it with a slight variation:
export type AtLeastOne<T, U = { [K in keyof T]-?: T[K] }> = Partial<U> & { [K in keyof U]: Required<Pick<U, K>> }[keyof U];

[dtfiedler]

🎉 This PR is included in version 1.0.0-alpha.20 🎉

The release is available on:

• npm package (@alpha dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[dtfiedler]

🎉 This PR is included in version 1.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀