DNS format

[Mirko-von-Leipzig]

A miden network currently consists of several public and some private components. At the moment most of these are referenced using hardcoded IP addresses. It would be better to assign each component a name, making it easy to remember and document.

This is only required while things are centralized.

Components

# Publicly visible
faucet          # testnet.miden.io | devnet.miden.io
rpc             # hardcoded IP address, currently just a single instance but should scale horizontally
tx prover proxy # IP, load-balancer

# Internal only
block-producer     # Shared instance to rpc i.e. localhost
store              # Shared instance to rpc i.e. locahost
tx prover(s)

Formatting

We'd like some kind of formatting schema to trivially name a component via DNS. Taking google for example, one has mail.google.com, maps.google.com i.e. {service}.google.com.

Since we also want to distinguish network, we might have {service}.{network}.miden.io or {service}.miden-{network}.io.

[Mirko-von-Leipzig]

@djpolygon you probably have better insight here; do you have a DNS scheme suggestion?

[Mirko-von-Leipzig]

@djpolygon and a different question. Does this also work for internal/localhost connections? As in, initially several components would share the same instance but as the requirements grow, these would move to separate instances.

Could we already assign DNS names to these components and use them in code? Or does one have to use localhost/127.0.0.1 in code?

[djpolygon]

Yes, you can use CNAME's for endpoints that map locally, it will make an outbound request and come back through, but this is better if you expext to grow.

In your code you would just use the endpoint as any other, and allow DNS to do the work for you on getting to the endpoint.

[bobbinth]

Since we also want to distinguish network, we might have {service}.{network}.miden.io or {service}.miden-{network}.io.

I'd probably go with {service}.{network}.miden.io format - e.g., something like this:

faucet.testnet.miden.io
rpc.testnet.miden.io
explorer.testnet.miden.io     # could also be an alias for just testnet.miden.io

Maybe another option is to use {network}.miden.io/{service}. For example:

testnet.miden.io/faucet
testnet.miden.io/rpc
testnet.miden.io/explorer    # could also be an alias for just testnet.miden.io

[Mirko-von-Leipzig]

We also have some network agnostic pages e.g. documentation and tutorials where I suppose we just elide the {service} part.

Your second option would result in nested paths, which I think are legal, just unusual e.g.

testnet.miden.io/faucet/get_tokens

[djpolygon]

@Mirko-von-Leipzig @bobbinth something to consider is that your CNAME endpoints such as the latter in your suggestion @bobbinth :

testnet.miden.io/faucet
testnet.miden.io/rpc
testnet.miden.io/explorer

Will work, unless you decide to decouple let's say rpc, then you would need a completely different CNAME in order to map to the host if you went with this approach. A work around for this is using a proxy pass solution, but that is just another layer of complexity.

You can also use the first approach mentioned by @bobbinth in his message. This gives you the flexibility to change where the CNAME's are pointed to with clarity to anyone seeing the endpoint.

I would suggest using the approach of {service}.{network}.miden.io/ or you could do {network}.{service}.miden.io/ but I would lean on the first approach of service declaration followed by network for better readability. Whichever path you wish to take, consistency is key.

[bobbinth]

Yeah, all of these components could theoretically be run on different machines - so, going with {service}.{network}.miden.io probably is best.

[Mirko-von-Leipzig]

Closing this as concluded :)

We've got {service}.{network}.miden.io up and running for the upcoming v0.7 miden release.