[Feature Request][RPC][CLI]: Make providing GRPC and RPC endpoints possible in separate URLs

[Bidon15]

Implementation ideas

Introduction

ATM, we are providing core.ip with an assumption that this address has opened ports for both rpc and grpc. In production environment, this is not a norm to do. Moreover, this makes public infra providers serve another endpoint for such purposes, thus creating redundancy and opening more vectors for bad UX in understanding what does what in our docs https://docs.celestia.org/nodes/mainnet#da-rpc-endpoints

H/t @kjessec @jcstein @marcmacmac for good discussions around this topic

What makes this endeavour done:

• [ ] Node binary accepts 2 new flags, like --core.grpc.endpoint=grpc.whatever.io and --core.rpc.endpoint=rpc.whatever.io
• [ ] Make secured connection possible

Usually, for secured connections, 80 for rpc and 443 for grpc are used. Configuring it as a concatenation to aforementioned with a : sign at the end of the string is a good enough imho and assuming default ports

[liamsi]

What makes this endeavour done: Node binary accepts 2 new flags, like --core.grpc.endpoint=grpc.whatever.io and --core.rpc.endpoint=rpc.whatever.io

@Bidon15 btw the right solution to this problem is not adding more flags to the CLI but instead make it such that node can use the app's gRPC endpoints exclusively instead of using both: https://github.com/celestiaorg/celestia-app/issues/3421

+1 on this though:

Make secured connection possible

[ramin]

@Bidon15 do you think we can close this issue now that v0.14.0 allows state access of gRPC only (non bridge). We also have https://github.com/celestiaorg/celestia-node/issues/3377 for tracking the tls stuff that was also part of this, feel free to close if you agree

[renaynay]

Closing as RPC no exist anymore.