How to support? development, server, manuals?

[daniele_athome]

@Hobby-Student

For my own server I currently use the dummy with daily changing code and working with invites… Not perfect, but fits my needs for now.

For private uses that’s completely fine. But being part of the KPN also means unique user ids. That is, a phone number cannot be registered to multiple servers at any given time. At the moment, this check is carried out at user registration time, but if you want to join the KPN with a server already having some registered users, we have to implement some automated checks.

@Hobby-Student

What would happen if my server would go down for minutes, hours, days? Can users login through your server?

You can’t use the login credentials for other servers, no. Kontalk is based on a XMPP federation mechanism, with a few additions (see below), but it’s still a XMPP federation. A user registered to a server will be tied to that server.

We’re planning to develop a semi-automatic account migration procedure that could be used when a server goes down for a noticeable amount of time (or it shuts down forever), but it is not quite ready yet. By the way, this could be the perfect time to speed up development of that part for us.

@Hobby-Student

I understood: server serves login to users with a mysql backend and connects the clients to the KPN. No sync of the backends.

No sync, that’s right. Here are the things they are shared among servers (and not all are implemented yet):

• user lookup (currently working; clients request a phone number, server replies with the server address where there user is registered, after having requested that to all the other servers)
• automated “load balancing” of registered users (not implemented yet; the app currently decides which server to use on a random basis. We would like that servers can reply with “I have too many users, please go to server XXXX”; an automated communication mechanism among servers will be required)
• account migration (not implemented yet; migrate an account from a trusted server to another, with all required changes)
• network-wide broadcasts (work in progress, should be ready to be tested in a couple of weeks; admin messages can be sent to all users in the whole network)

@Hobby-Student

To be fair. I don’t have that much experience in developing android apps, but the source teached me many things till now. Setting up the tigase-server with HttpUploadComponent was more or less easy.

I strongly recommend you to switch to the Docker installation (I’ll assist in the migration of course), because it’ll be much easier to handle upgrades and maintenance in general. I was relieved of many manual tasks when I switched to Docker. And if you think something in our Docker environment should be added or improved, any comments would be welcome (e.g. at the moment Let’s Encrypt integration is handled externally with private scripts (see below); it should be integrated into the public code repository for the benefit of all people).

@Hobby-Student

If I could offload the SSL part to my haproxy… But it seems, that port 5222 needs to deliver the certificate itself to the clients. Complicates the use of let’s encrypt a bit.

Yes, the certificate is handled and managed by Tigase. We also use Let’s Encrypt with a custom post-renewal hook that automatically copies the certificate file to our Docker environment directory and restarts the container.

You can do whatever you like with HTTP upload part though, since HttpUploadComponent exposes a plain HTTP interface. Although it is capable of natively doing SSL, I’d recommend using a reverse proxy with a proper URL.