Hey out there,
currently I’m experementing with kontalk. I run my own server (not docker based) and modified the app for my needs… also I’m new to XMPP / tigase.
My free time is very rare, but I would like to try to support this project.
If I would deploy a public server, do I need a connection to your database?
If supporting development, is it enough to just do pull requests via github?
Hello and welcome!
I would love to know what modifications and improvements you made to the system. In a way you can also contribute just by sharing that.
No. You just have to communicate to us your GPG server key ID and we’ll provide you instructions on how to configure your server to link with us.
Users will need to be able to register with your server so you’ll need a SMS account on e.g. Nexmo. If you can’t afford it (or simply don’t want to), don’t worry, we’ll set you up in some other way - I can talk to our SMS sponsor, JMP.Chat, and see what they can do.
In general, yes. I’d advise you to read our contribution guidelines for submitting patches: following those will surely speed up the review process.
If you’re not sure about what to contribute or you would simply like to see what you can start with (so you can get some experience with the app code), you may start by looking at issues labeled with help wanted or good first issue.
I’m guessing you’re talking about contributing to the Android client so I gave you pointers for that, but if you’re interested in developing other parts (other clients, server stuff, etc.) there is a lot to be done!
Thanks for your interest in contributing! If you need support just fire away.
mainly modifications, not improvements in general 
E. g. changed the location sharing URLs to deliver not 2 but 6 digits. (pull request will follow this weekend)
For now I’m playing around and have a deeper look where I could support.
This is topic I thouht about for the last days. 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.
What would happen if my server would go down for minutes, hours, days? Can users login through your server?
I understood: server serves login to users with a mysql backend and connects the clients to the KPN. No sync of the backends.
Did this already. Seems to be not that complicated for developers
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.
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.
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.
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.
No sync, that’s right. Here are the things they are shared among servers (and not all are implemented yet):
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).
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.
HttpUploadCompontent listens on plain 8828 and my reverse proxy is offloading SSL.
Perhaps I will make a subdomain for upload, so kontalk is connecting to domain.tld and files are handled via upload.domain.tld. This would require 2 certificates, but deployment is easier.
I have some experience with docker. So this would be no problem. Just wanted to get a deeper look at the components. I’m running Ubuntu 18.04 LTS and your docker containers are debian. I was missing some tools inside…
Isn’t this part of tigase server already? tigase admin guide
simple spoken: many servers, one backend
IMHO this is way too late. when it’s down, no migration is possible…?!
To sum it up: I will have a deeper look where I can support this project and will report back
Well, one the purposes of containers is that they contain the minimal required to run things. You’re not supposed to get inside them unless debugging. If you care to describe what you were trying to explore and do I can think of something to write in the Dockerfiles or in the Docker environment. Our Docker infrastructure is still somewhat basic.
Not really. Tigase has clustering capabilities within the same service name (that is, the hostname after the @ sign in JIDs). What we are trying to achieve here is a system for redirecting users during the registration phase in order to balance the number of users served by any given server.
Indeed 
but the migration is intended for clients. A client could request a migration at any time, without having to contact the original server. Showing the signed key to the new server will suffice (since it’s trusted by the new server). Then activate some mechanism to clear the account from the old server if and when it comes back online.
Great! Feel free to ask anything in the meantime.