# Specifying Protocols Without Global Announce or Relay
**URL:** https://forum.syncthing.net/t/specifying-protocols-without-global-announce-or-relay/18565
**Category:** Development
**Created:** [June 10, 2022, 5:01pm UTC](https://forum.syncthing.net/t/specifying-protocols-without-global-announce-or-relay/18565 "2022-06-10T17:01:43Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@RobotSail](https://forum.syncthing.net/u/RobotSail)
#### Post date: [June 10, 2022, 5:01pm UTC](https://forum.syncthing.net/t/specifying-protocols-without-global-announce-or-relay/18565/1 "2022-06-10T17:01:43Z")
Hi all,
I’m currently working on integrating Syncthing as a data mover within a Kubernetes Operator for data replication. In this environment, Syncthing is not using global announce or relay servers for data transfer, so the current mechanism of connection is to provide each node with the device ID and data address of the other(s).
I was wondering about two things:
1.) Since we are generally operating across a TCP connection, is it necessary to provide a `tcp://` or `udp://` prefix for the other node to connect to, or is Syncthing capable of determining the protocol from the base address alone.
2.) More broadly, would Syncthing ever be interested in supporting [multiaddrs](https://multiformats.io/multiaddr/) as a format for specifying connections? I’ve found it to be very useful when working with IPv4 and IPv6 connections and needing to obtain or alter information about the port.
Thanks!
---
### Author:  [@calmh](https://forum.syncthing.net/u/calmh)
#### Post date: [June 10, 2022, 8:32pm UTC](https://forum.syncthing.net/t/specifying-protocols-without-global-announce-or-relay/18565/2 "2022-06-10T20:32:05Z")
Syncthing needs the scheme when you specify an address. Multiaddrs look nice, but we in principle already do something similar, since you can specify `tcp://` or `tcp4://`, `tcp6://` etc depending on how specific you want to be. You could think of those as `/ip4/$host/tcp/$port` or `/ip6/$host/tcp/$port` in multiaddr terms, as I understand it, except we don’t differentiate between `dns4` and `ip4` etc. In your case I guess just tack on `tcp://` in the front of whatever `host:port` you get from Kubernetes and you’re good to go.