TeamDrive Name Server (TDNS)

The TeamDrive Name Server (TDNS) allows users from different registration servers to work together by mapping users to their respective registration servers. This allows invitations to be sent to the correct registration server which is necessary because invitations must be send to the Registration Server with which the user registered their devices.

Usernames, unlike email addresses, are unique within the TDNS network. If you enable TDNS, any username registered on an existing Registration Server can not be registered/used on your Registration Server.

TDNS access will modify the registration, login, search and invitation calls in the Registration Server (and also the API calls) and check the TDNS, determining which username exists on which Registration Server in the TDNS network.

Every Provider requires a record on the TDNS. A record will have a ServerID and a checksum. All requests will contain the ServerID and checksum to verify that the request is coming from a valid Registration Server.

You have to enable outgoing access on the HTTP-Port 80 to to enable the communication from your Registration Server to the global TDNS.

Data security on the TDNS

On the TDNS we don’t store usernames or emails in plain text. All data will be hashed and salted in your Registration Server, so that we have only strings like:


This method ensures that no plain usernames and emails will leave your Registration Server. Access to the TDNS is only possible for a Registration Server. The client does not directly access the TDNS.

Communication workflow from Client to Registration Server to TDNS and the way back

Inviting users which are registered on different Registration Server will result in a couple of requests. Please keep the following facts in mind:

  • A client can only poll his own Registration Server for new invitations. Clients registered on other Registration Server must send the invitation to the Registration Server holding the invited client record
  • Only the client’s own Registration Server can check whether the access credentials of the client are still valid

User is searching for

A) Client -> Search request -> Registration Server 1 -> Hash lookup for the email -> TDNS (List of 3 Registration Servers) -> Registration Server 1 -> Answer to client with the Registration Server list -> Client

B) Request 1 -> Get username for email -> Registration Server 2 -> returning username to client

C) Request 2 -> Get username for email -> Registration Server 3 -> returning username to client

D) Request 3 -> Get username for email -> Registration Server 4 -> returning username to client

Client will show 3 different usernames with the same email in the invitation dialogue. The user will choose the user from Registration Server 2 on the list

E) Client -> Invitation request -> Registration Server 2

Description of the request steps:

A) The user entered an email address in his client and clicks on add. A search request will be send to Registration Server 1. Registration Server 1 is converting the characters below ASCII 127 in the email to lowercase and generates the hash. A lookup will be send to the TNDS. The TDNS will answer with:

  • No Registration Server: Email is unknown -> Store forward invitation using the email
  • one Registration Server: Email is only registered on one Registration Server -> If the name of the Registration Server is identical, the Registration Server will directly return the username.
  • more than one Registration Server: Email is registered on more than one Registration Server; this case will be described in the next request descriptions

B) – D) The client get a list of Registration Server names. The client must now send a search request to each of the Registration Server. The client will send an additional flag, so that no new TDNS lookup will be done. otherwise another list of Registration Servers would be returned. The answers from the different Registration Server will be put together and displayed in one result in the invitation dialogue.

E) After the user has picked the correct user from the list, the invitation will be send to Registration Server 2, where the target user is registered.

It is only possible to connect to other Registration Servers using a special remote authentication. Normally only the own Registration Server can check the authentication. When connecting to a foreign Registration Server, the own Registration Server will create a remote authentication sequence which can be checked by another Registration Server which doesn’t know the user.

For you, as a provider of a Registration Server, it’s important that you can control which other Registration Server in the TDNS network you trust and which other server you allow your clients to contact. This is done using a black and white-list in the admin console (see Administrative Guide).