RFC: exchange of supported features between provider and consumer
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.
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.
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.
- Internal protocol version which should not be changed by user, like p2p, nat.
- Proposal related version, like payments etc, for this we already have ID on proposal.
@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.
How can you tell that provider doesn't support p2p?
Consumer should be able to connect in both ways
You are right, and that's why we should have this information in the proposal.
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.
Added issue for Contact field https://github.com/mysteriumnetwork/node/issues/2011
@tadaskay please close if it not valid anymore