Setting up directory server in Asia

[ann0see]

We had an internal discussion that a directory in Asia - likely Thailand would be beneficial for geo redundancy reasons.

This should replace Any Genre 3.

Thoughts:

• The directory should be maintained by someone in Asia who is an active member of the community.
• We should agree on some shared requirements to ensure that this directory is trustworthy

[pljones]

Just to add that part of the goal is to extend the appeal of Jamulus on "the far side" from the heavily used European hub.

I think maybe the Jamulus client could be made to default (on first run) to the Directory with the lowest ping. This would encourage Servers to register with a regional Directory and clients to would see these local Servers.

Such a change would open the application to future addition of other regional Directories.

[dcorson-ticino-com]

At the same time it may be good to give the directories regional names instead of the present genre names.
... I know ... not compatible with old versions.

[pljones]

What people see on the screen, of course, is just translation string, so has no effect on how the software works.

Changing the DNS names is easy enough -- add the new ones, issue a new release with the new ones. There's not much need to remove the old ones.

We've moved from having no central coordination (back in the llcon days) to adding a single, manually maintained, "central server", adding the automatic registration, having two such "central servers" (briefly with a split between the two, I think?), adding the selection of "central server" to the connect box, then to adding more and renaming them eventually from "central servers" to Directories, with the split between "Any Genre X" and the genre-specific ones. All without breaking any servers that were registering with the original automatic system.

One reason for the number of Directories is that the protocol can't adequately support more than roughly 150 Servers per Directory. At the time all this got rapidly rolled out, trying to say we had any "regional" split was misleading, as "London" and "Frankfurt" doesn't really cover much of the globe 😄 .

---

Oh yes -- that UDP fragmentation discussion mentions another point - the second Directory was originally North America.

[ann0see]

@dtinth I think you volunteered in the past. Does this still stand?

[dtinth]

@ann0see Yes, it still stands.

[ann0see]

Thanks!

[mcfnord]

@dtinth, you tried explaining to me once that sometimes Thai users need a server's IP:PORT because (I think) the Directory is too far away, causing failure of some kind in the Directory's server listing for clients in Thailand.

If that's right, then do you think a Thai Directory would cause the same failure for clients in Western Europe?

(If so, that strengthens the regional Directories concept by a lot.)

[dtinth]

@mcfnord I believe the failure to load the directory is not due to the distance, but because some routers/ISPs are configured to ignore fragmented UDP packets. See prior discussion: https://github.com/orgs/jamulussoftware/discussions/1058#discussioncomment-7949643

[ann0see]

But it might be the case that there are more hops -> more likely to have fragmentation.

[ann0see]

Proposed guidelines of hosting an official directory:

Any official directory (owner) included in the official Jamulus application:

• MUST provide a way to contact the hoster. This might be an entry in the Welcome message of the directory, a contact address on jamulus.io or similar

• MUST take responsibility of protecting the network from security threats or illegal actions. This might include blocking registration of servers but can only occur with public announcement.

• MUST remain neutral under any circumstances and not favor or degrade experience for any user or server provider.

• MUST take responsibility of timely security updates or any other protections of the server hosting the directory.

• MUST update the directory within at most 14 days of an official release. Any deviations MUST be communicated officially.

• MUST NOT perform any undisclosed modifications to the source code

• MUST respect the privacy of every user connecting to the network. This means, an operator MUST NOT make excessive use of logging or data collection of users' data, MUST NOT sell or give away data to third parties for marketing purposes. Data protection MUST be in accordance with the Jamulus Privacy policy. Any deviation MUST be communicated to the user.

• SHOULD provide IPv6 support

• SHOULD use a low latency connection

• SHOULD update the application within 3 days of release

• SHOULD provide remote access to at least one other directory owner.

• SHOULD NOT share any data to third parties

[pljones]

MUST provide a way to contact the hoster. This might be an entry in the Welcome message of the directory, a contact address on jamulus.io or similar

We should insist on up to date contact details for a TXT record in the jamulus.io DNS entries. We don't do this currently but I think it's probably something we should do.

MUST NOT perform any undisclosed modifications to the source code

For Directories, I'd say only official tagged releases should be used, with no changes. Currently AG1-3 are the official latest release and the other Public Directories are latest tagged release.

I'd also note that the use of server list persistence is recommended for rapid recovery in case of failure or extended outage. (I've managed to switch which machines my Directories run on without Server Registration loss -- pretty much with zero down time.)

[ann0see]

@corrados I'd like to get your opinion on the guidelines. Same for @dtinth

[corrados]

Maybe add that a directory server manager should be aware that it is a long-term commitment. I run Jamulus servers for about 20 years now.

[pljones]

Slightly off topic... @corrados - do you remember when the original Central Server was implemented, i.e. the normal server just with the manually compiled server list injected? Was it there from day one? (I ask because I spout Jamulus history and this is the one bit I'm really not sure about.)

[corrados]

No, it was added later on. Approx. 2010 https://sourceforge.net/p/llcon/discussion/server/thread/7c17cd0c/?limit=25#a70e there were the first investigations done. It finally arrived in the "llcon" software with this version: https://github.com/jamulussoftware/jamulus/blob/main/ChangeLog#320-2011-07-23.

Edit: A predecessor idea was to simply post the IP address in a forum: https://sourceforge.net/p/llcon/discussion/server/thread/287b0677 but no one has given any address.