Relay nomclementure confusion

Summary

The descriptions of the physical hardware used by those that are using the Relay TS011 facilities is diverging and runs the risk of confusing everyone making a mess of support or anyone trying to obtain hardware.

Trying to reach a concensus that clearly describes the roles and clarifies the CLI commands has the potential to reduce support issues.

Steps to Reproduce

TTS refers to serving for the device that relays a message from an out of range device that is called served. This has pronunciation, spelling, autocorrect and I'd suggest is too phonetically similar to make for a clear conversation, particularly being heard by a non-native English language listener.

Semtech haven't surfaced the docs for a serving device but refers to the served device at compile as MODEM_APP=RELAY_TX ALLOW_RELAY_TX=yes

KroonosRelay from @stevencellist has settled after discussion with me, on Relay for the serving device and NodeR for the served device.

Additionally, the TTS CLI docs says things like ttn-lw-cli relays create [application-id] [device-id] [flags] which is OK but less than ideal as device-id references the serving device (Relay). To setup a served device the syntax is ttn-lw-cli relays create [application-id] [device-id] --mode.served.serving-device-id string where device-id is the served device and the 'string' references the serving device - which is somewhat obvious given the text of the flag. I'd anticipate a lot of finger trouble typing that lot and getting the device ids the right way round etc.

Current Result

I've managed to solicit many errror messages in the last few days from the CLI that were either a blizzard of incomprehensible output or a succinct oneliner (Redis error). Then I have to figure out serving vs served.

Expected Result

If other words were used for serving and served or aliases could be set or duplication of the flags with an alternative naming scheme it would help make already complex functionality clearer to configure.

Relevant Logs

Examples - SnowJoke is a Mac mini M1 running Sonoma talking to the relay.eu2 discovery instance:

nick@SnowJoke Reference % ttn-lw-cli relays update ttc2024demo noder-loradio32-1 --mode.serving.limits.join-requests.reload-rate 60 
error:pkg/redis:store (store error)
    correlation_id=5be5eda4ad9a412992b06ddac1b7825b
nick@SnowJoke Reference % ttn-lw-cli relays get ttc2024demo noder-loradio32-1 
error:pkg/networkserver:relay_not_found (relay not found)
    correlation_id=d6a85a89b2e346bb9585143b26966bc8
nick@SnowJoke Reference % ttn-lw-cli relays get ttc2024demo the-relay         
error:pkg/networkserver:relay_not_found (relay not found)
    correlation_id=313c8f0c04ea47978abe9e7f85d78ed6

URL

No response

Deployment

The Things Stack Cloud

The Things Stack Version

3.32.1

Client Name and Version

The Things Network Command-line Interface: ttn-lw-cli
Version:             3.32.0
Build date:          2024-09-05T14:50:21Z
Git commit:          32b3f88e3
Go version:          go1.21.13
OS/Arch:             darwin/arm64

Other Information

If this strikes a chord, hopefully we can discuss a naming convention that provides clarity to savvy end-users who don't tend to read the specs (99% of them!)

Proposed Fix

Relay and NodeR came about after a lot of to & fro during development and has made testing so much simpler when talking about the different elements of a deployment.

Contributing

[X] I can help by doing more research.
[X] I can help by implementing a fix after the proposal above is approved.
[X] I can help by testing the fix before it's released.

Validation

[ ] The fix is tested in a staging environment.
[ ] The fix is documented in The Things Stack Documentation

Code of Conduct

[X] I agree to follow TTN's Community Code of Conduct.

TheThingsNetwork / lorawan-stack