Closed dagurval closed 4 years ago
Hmm. Well the alternative is if the server is not configured correctly, return some bogus data as a best guess.. and warn the user on the console/log that his server needs more configuration..
Like the local port, local IP. (I had to do this for Fulcrum -- and it's an ugly hack but since I had to have something there.. I had no choice).
Yeah.. I guess making it optional is the right way to go about it... this way server.features
becomes a generic feature query and not a peering-specific thing.
As it stands if you take that hosts
key out -- the server.features
returned will fail for peering with all extant servers so... not sure how useful that is in practice now.. but at least we update the protocol to evolve going forward, I guess...
I'd suggest adding text that if a server omits the hosts
, peering is likely to fail due to restrictions that some implementations impose... just to drive the point home...
Thanks for the feedback @cculianu
I bumped this change into version 1.4.2 and added a note about ElectrumX
This looks good to me 👍
Rationale: It can be difficult for the server to auto-discover its host and ports. For example if SSL is provided through reverse proxy.
Having this feature as MUST will thus force manual configuration, which increases the difficulty for operators to setup and maintain a server.