node icon indicating copy to clipboard operation
node copied to clipboard

RFC: exchange of supported features between provider and consumer

Open tadaskay opened this issue 5 years ago • 9 comments

tadaskay avatar Apr 03 '20 12:04 tadaskay

Let's have a discussion of how to proceed with this. Since 0.30 release is nearing we need to be able to have proper backwards compatibility logic support.

Currently proposed options on where to check for compatibility:

  • compatibility check during dialog setup
  • compatibility check while parsing proposals

How to check for compatibility:

  • compatibility level
  • feature sets
  • node version

Give your perspective, pros and cons.

zolia avatar Apr 06 '20 11:04 zolia

Having this information on a proposal level would allow clients to filter incompatible providers beforehand (instead of allowing to proceed and doing errors/retries/fallbacks).

As for compatibility, compatibility level and node version both require interpretation while feature sets are more explicit, so I would vote for the explicitly listed feature sets, e.g. supports: [ "p2p-dialog", "payments_v99" ], etc.

tadaskay avatar Apr 06 '20 11:04 tadaskay

I would go with some protocol "version" which is not related to node version, but is similar as in TLS. I see there are two different cases.

  1. Internal protocol version which should not be changed by user, like p2p, nat.
  2. Proposal related version, like payments etc, for this we already have ID on proposal.

anjmao avatar Apr 06 '20 11:04 anjmao

@tadaskay We don't need filtering. Consumer should be able to connect in both ways. For example in our p2p case if provider doesn't support new p2p, he still want to see this propsal, but jus connect in old way.

anjmao avatar Apr 06 '20 11:04 anjmao

How can you tell that provider doesn't support p2p?

tadaskay avatar Apr 06 '20 11:04 tadaskay

Consumer should be able to connect in both ways

You are right, and that's why we should have this information in the proposal.

tadaskay avatar Apr 06 '20 11:04 tadaskay

In proposal there is Contact field.

type Contact struct {
	Type       string            `json:"type"`
	Definition ContactDefinition `json:"definition"`
}

It's used for dialog so we can actually extend it and add p2p contact definition. It should solve current issue with connect delay pretty easy.

New field with supports flag can be added too if there is use case for it and I imagine it can be used as you mentioned by filtering proposals which contains only features I want.

anjmao avatar Apr 06 '20 11:04 anjmao

Added issue for Contact field https://github.com/mysteriumnetwork/node/issues/2011

anjmao avatar Apr 06 '20 11:04 anjmao

@tadaskay please close if it not valid anymore

creotiv avatar Aug 26 '21 09:08 creotiv