Federation works only for relays listening on the default port

[sameh-farouk]

• from Rmb-peer side, port will be ignored when it update the relay info

https://github.com/threefoldtech/rmb-rs/blob/933b64ba21d0ddc3d3dfb3861e381285814569c9/src/bins/rmb-peer.rs#L159-L165

• Even if Rmb-peer provided the port, this is not supported from TFchain side as there is a validation that won't accept : char.

• This won't be noticed for peers use same relay, as peers will connect to the relay with the full URL. so provided port is respected.

https://github.com/threefoldtech/rmb-rs/blob/933b64ba21d0ddc3d3dfb3861e381285814569c9/src/peer/socket.rs#L97

• But it cause problems when you try to communicate with twins that are connected to different relays, because relays will not be able to find each other unless listening on port 443 (or 80 in a non-typical case ).

https://github.com/threefoldtech/rmb-rs/blob/933b64ba21d0ddc3d3dfb3861e381285814569c9/src/relay/federation/router.rs#L23-L27

[muhamadazmy]

This is by design. Twin can only define his home relay by a full qualified name. Relays then can only relay messages to public relays that has SSL enabled.

In the code you shared above seems like we also can forward over http during tests if you run cargo test

[sameh-farouk]

Thank you for your reply. I admit that I was a bit confused about few things. But this means that we can make things clearer for everyone. Here are some points that I think we should address:

1- I misunderstood the idea that the relays open two ports, one of which can be customized by the relay flag listen for communication with peers over websocket, and the other of which is https 443 for secure transfers of encrypted traffic between relays.

This information should be documented more clearly.

2- A source of confusion is using the same information for two purposes. The relay option requires the relay address (IP or domain, no validation 🤷‍♂️) and uses it to:

• connect with the relay via websocket.
• update the chain state and communicate with the relay.

I think it would be clearer to separate concerns and have a specific option to set the relay domain (only domain, not a full address) used to update the chain and relays communication (with added validation to ensure that user provided a domain). This would be less magic to user.

3- This is a question: why we do not support wss/tls for peer <-> relay communications but enforce tls communications between relays over https?

Could you please let me know what you think about them? If you agree that these are valid points that deserve attention, I can reopen the issue or create a new one to address them accordingly.

[muhamadazmy]

Your comment confuses me, i don't get what u mean.

• Relay does not open 2 ports, it's only one port for HTTP which is the same port for the websocket connection since websocket is just an extension to the http protocol.
• I totally don't understand your number 2 above. what same information for two purposes? the relay information is basically the name of the relay you are connected to. and is your home relay which means if other relays need to deliver you a message they need to send it to that relay.
• The peer allows ws mainly only for testing when you are running a local relay. there is no need to enforce a wss from the peer per se.
• using wss and https are encouraged and enforced in some places in case of clients that does not implement end to end encryption.
• your number 3 is wrong, because wss tls is supported for peer <-> relay communication it's just enforced to use again for debugging. We can may be not allow ws for a release build but allow it for a debug build.

[sameh-farouk]

@muhamadazmy Thank you so much for helping me out with this issue. I finally realized that I need a reverse proxy for TLS termination (your note), which was the key to solving my problem. I was confused because I thought the RMB would handle this, but I was wrong. Now I understand that the relay listens internally to an unsecure port like 8080 (the one used unless overridden by the listen flag), while the peers send the encrypted traffic to the reverse proxy, hence the two ports in the story.

This issue was mainly due to the lack of documentation. I know there are other issues open for improving the documentation, and I hope they will be resolved soon. Thank you for your time and patience.