Settling the "custom port/IP/hostname" issue once and for all

[SafwatHalaby]

_Note to Devs:_ This is not yet another “please implement custom IP/port/hostname” issue, please do not close without consideration. I have read the relevant part in the faqs, and I have read the countless closed issues regarding the subject. -which are listed below-

The purpose of this issue is to:

• Consolidate all the closed issues into a single, thorough post. (Which could be linked to from the FAQ in the future)
• Hopefully end the endless stream of repetitive requests by providing a definitive, detailed answer.
• Attempt to convince the developers that SRV records are not always the right solution, and that an alternative is needed. I am more than open to be proven wrong.

For those who have no idea what I'm talking about, please read the preface / background.

Preface / Background

Ever since the inception of Conversations, the same feature request had been popping again and again: Some people have their own custom servers, often without a proper DNS address, and often on a non-standard port. They want to be able to connect to them. Other clients such as Xabber provide those users the ability to specify a custom IP address / port to connect to. However, Conversations does not provide this in the UI. Those people cannot connect to their servers unless they setup SRV records.

This request popped up numerous times:
#978 #960 #942 #917 #911 #861 #935 #689 #583 #541 #482 #106

The current solution

The current solution is setting up SRV records.
Also, there's a non official patch by @kevindelaney which allows this, it can be found here: #1003

There are also some exotic, alternative hacky solutions such as modifying Android's /etc/hosts.

The proposed solution

The main solution that was proposed in all the closed issues is identical: Add a "custom host/port" field in the UI, just like Xabber. The developers were not too keen about this idea, implying that this is not necessary, and that a proper setup should include SRV records and would not really require this.

Disadvantages of SRV's

In this section, I list the shortcomings of SRV records and argue that they are not always the right solution, and that in fact we do need a "custom host/port" option in Conversations, I am more than open to be proven wrong. Also, if I missed a disadvantage, please tell me about it and it will be added.

• Not everyone has purchased a domain name. This is especially true for small private servers.
• For those who haven't purchased and domain name, setting up SRV records requires some custom DNS server witchcraft, which is much more complex than just typing a custom host/port in Conversations and is not always feasible.
• On many home XMPP servers, this solution alone is not viable due to NAT loopback issues. e.g. I can connect to myHomeXmppServer.example.com from the outside world (WAN), but not from my own house (LAN), because the DNS resolution returns my external IP.
• People who setup external ports that map to different internal ports cannot use the server from the LAN side. (Unless conversation provides them a custom host/port option)

Disadvantages of a "custom host/port"

This section has arguments against adding a "custom host/port" field into the Conversations UI. If I missed a disadvantage, please tell me about it, and it will be added.

• Most use cases break Jabber's federation.
• If not correctly designed, UX could suffer from menu clutter and might confuse non tech-savvy users. this is resolvable via proper UI design.

[iNPUTmice]

I might have written this on other occasions as well but I agree with you that a single thread that combines all the arguments into one might be necessary.
So here are my points:

• To allow for s2s communication you will need either a proper DNS setup anyway or have your domain name be the same as the server address. Because others servers won't offer you a way to customize your server / port settings either.
• If I'm understanding you right you want to have different server settings for WAN and LAN. So is your plan basically to change the account settings every time you switch between 3G and wifi? No one will go through that trouble.

If have a general feeling that these settings will benefit mostly people who'd like to toy around and run an XMPP server on their $20 wifi home router. While there is nothing wrong with that those people are not the target audience of Conversations.

Imho someone who is unable or unwilling to set up SRV records (and maybe purchase a $5 domain for that) is way better off with using a publicly available server run by professionals.

[SafwatHalaby]

To allow for s2s communication you will need either a proper DNS setup anyway or have your domain name be the same as the server address. Because others servers won't offer you a way to customize your server / port settings either.

True. My arguments are not that relevant to public, federated, "standard" servers. Many servers are not like that though.

If have a general feeling that these settings will benefit mostly people who'd like to toy around and run an XMPP server on their $20 wifi home router. While there is nothing wrong with that those people are not the target audience of Conversations.

Your feeling is correct. This feature is generally for the DIY and RPi guys. While wanting to invest solely in your target audience is understandable in general, I think that in this highly specific case, it is very strategic for you to "compromise" a bit. The reason is that the feature is such a low investment, but it would make Conversations an attractive option for a huge chunk of people. Also, it is not invasive at all for those who don't need it. Low pay, high gain.

The underlying story is that the two serious open source Android XMPP clients are Xabber and Conversations, Tinkerers almost always prefer open source, and for those who are not satisfied with Xabber, the only existing alternative is Conversations. This is a pretty small feature which opens a closed door for many of them. Supporting my claim is the steady influx of people requesting the same feature over and over again.

If I'm understanding you right you want to have different server settings for WAN and LAN. So is your plan basically to change the account settings every time you switch between 3G and wifi? No one will go through that trouble.

That is precisely what I used to do with Xabber. Xabber provides a convenient toggle between custom IP mode and normal DNS mode, so switching was only a button away.

[jkufner]

@iNPUTmice: People who like to toy around are most likely to help with bug fixing and development. You don't want to send them away.

[jkufner]

As I read SRV disadvantages, it sounds like you just don't set them correctly. So here is how.

But anyway, I used 3rd party DNS for some time and it was pain in the ass. I highly recommend you to get yourself a proper DNS record. The DNS is the only service you really need to buy and it helps a lot.

Scenario 1: Custom bind running on router

Assuming usual Debian Linux installation with some firewall configured and local instance of bind. Basic idea is to provide LAN users something else than to Internet users. Easiest way is to set public wildcard DNS record to public IP address (static or not) and use internal DNS server with custom DNS zone.

So from the Internet, asking for A record of home.example.com will return 1.2.3.4. And asking for SRV record will fail, therefore, A record will be used (assuming you cannot set SRV record properly).

From LAN, the same request will be responded by local bind instance with non-wildcard records. This is simple setup of bind or any other DNS server, just make sure it is firewalled from outside, so it cannot confuse Internet users.

Scenario 2: More advanced configuration

The same idea a in Scenario 1, but running standalone server in LAN. In this case you can configure views in bind configuration like this:

acl lan {
        127.0.0.1;
        192.168.0.0/16;
};
acl internet {
        !lan;
        any;
};

view "local_net_view" {
        match-clients   { lan; };
        allow-recursion { lan; };
        zone "home.example.com" IN {
                type master;
                file "/etc/bind/db/home.example.com-local";
        };
        // ...
}

view "internet_view" {
        match-clients   { internet; };
        zone "home.example.com" IN {
                type master;
                file "/etc/bind/db/home.example.com-public";
        };
        // ...
}

Nothing complex here, just setup all /etc/bind/db/home.example.com-* zone files, each for given IP range, and you are done. Your DNS server will provide correct answers depending on origin IP of the request.

Scenario 3: Devel/test server

Just use your A record in JID or point few more A records to it. No SRV required as long as you use standard ports.

[SafwatHalaby]

@jkufner , Thanks. The solutions you proposed is what I called "dns witchcraft" in my original post, I have zero experience with setting up my own DNS servers and many others are like me. While your solutions might work (I can't really tell or test them), that's like shooting a fly with a cannon, while it could work, it is unneeded complexity. Why not have the custom host thing instead?

Regarding scenario 2: Could you briefly explain the communication flow behind it?

1. My computer requests the server IP from my router (via DNS).
2. My router somehow routes this request to an internal DNS server (Does that mean I need to also configure my router differently?), the DNS sends a reply back
3. Now I have the internal IP of the server
   Is that it?

1B. When connecting from the WAN, is the internal DNS server involved at all?

[SamWhited]

Initial thoughts

I can not imagine a situation where you'd have to run your own DNS just to setup SRV records. If you're using one of the many popular XMPP providers out there, they already have them (if they don't, they're doing it wrong and you shouldn't be using them). If you're running your own server with your own domain, then you're knowledgeable enough to setup your own SRV records (and if your DNS provider doesn't allow SRV records, they're also doing something wrong and you shouldn't be using them; there are plenty of free DNS providers out there who support SRV records).

The other arguments I've seen for why this feature is "necessary" don't make sense to me either. If you're in an internal corporate environment where everything is host-name based, you should just be using that host name directly (so you don't need SRV records). Why even bother using a different host name for your JID? "you@internalcompanyserverhostname" should work just fine (and if not, complain to your server administrator... either get them to fix the XMPP server, or use DNS in a sane fashion). </rant>

Breakdown of OP's points

Not everyone has purchased a domain name. This is especially true for small private servers.

Then enter the IP address directly or use a host name. I'm not seeing how this relates to the problem? If an IP is attempting to be resolved as a domain (it might now that I'm thinking about it), this is a separate issue which is easy enough to fix.

For those who haven't purchased and domain name, setting up SRV records requires some custom DNS server witchcraft, which is much more complex than just typing a custom host/port in Conversations and is not always feasible.

Why is this not always feasible? If you're using DNS (even with a fake internal hostname or something), and you can set an A record or a CNAME record for your XMPP server, you can set an SRV record. If your software doesn't support setting SRV records, time for an upgrade, you have bigger problems (yes, I'm fully aware that some people can't upgrade for whatever legacy support / policy reasons... I don't care about those people. The majority of users aren't those people. Sorry to be blunt.)

On many home XMPP servers, this solution alone is not viable due to NAT loopback issues. e.g. I can connect to myHomeXmppServer.example.com from the outside world (WAN), but not from my own house (LAN), because the DNS resolution returns my external IP.

And you can't connect to your own external IP internally? You should probably fix that. Or not run your own server on a NATed home connection (not the best advice, I know, but again: you probably have other issues if you're doing this and there aren't enough people doing this sort of thing to justify adding UI elements / features IMO... VPS's are cheap in most countries).

People who setup external ports that map to different internal ports cannot use the server from the LAN side. (Unless conversation provides them a custom host/port option)

So return a different SRV record on the LAN side? If this is another situation where there is no DNS: See my previous points (IP:port should work; if not, that at least we can probably fix).

People who like to toy around are most likely to help with bug fixing and development. You don't want to send them away.

They're also the ones who should know how to do things properly. Why add an entire new UI / feature just for "toying around"? If these people can setup an XMPP server, they can setup a DNS server. If they can work on the code, they can temporarily tweak the DNS lookup stuff while they're testing.

The WAN/LAN setup is really a different issue. It seems unnecessary to me for the amount of use it's likely to get (very little).

[jkufner]

@wiseoldman95 Well, that DNS witchcraft is part of setting up your
Jabber server ;) Take a look into XEPs defining the XMPP protocol and
you will see a lot of references to DNS ...

Yes, Scenario 2 is a bit crazy. It involves using your server on your
LAN as public primary DNS server for your domain. I was running this
setup for some time, so I described it.

The comminication flow is this:

1. DHCP server on LAN will tells the client to use LAN DNS server
   located somewhere on LAN. Router is not involved here, unless it
   is running DHCP server (which often does but does not have to).
2. The client lookups DNS records from LAN DNS server specified in
   step 1.
3. The client receives response containing LAN IP address of the
   Jabber server (A records and SRV records).
4. The client connects to Jabber server using LAN IP address.

When connecting from WAN (Internet), communication flow is like this:

1. Client asks the same DNS server for DNS records for Jabber server.
   The communication is forwarded by LAN router to the server.
2. DNS server responds with public DNS record, since request come
   from WAN.
3. Client connects to Jabber server, router is forwarging the
   communication in the same way as to DNS server.

The WAN situation is a bit simpler if Jabber server and DNS server is
running on the router. Then it is only about using correct network
interface.

But as I said... it is a bit crazy use-case :)

[jkufner]

@SamWhited: I completely agree with you on this.

[SafwatHalaby]

Edit: I somehow accidentally skipped reading Sam's post which starts with "Initial thoughts" before writing this post, I will re-post a different one taking Sam's post into account.

I don't understand this at all. You are claiming it is not needed; either you're missing some use cases or I'm misunderstanding something. Because I don't see how it can be done without a custom host in some cases. Allow me to use my personal case as an example:

1. I have a raspberry Pi behind a home NAT router, the Raspberry Pi is my private XMPP server, it is unfederated.
2. I have a static IP, but I don't have a DNS.
3. My friends connect to the server from the WAN side via xabber by typing friendname@myRandomHostName , and by setting the custom ip to my wan-ip
4. I connect to the server from the LAN side only, by typing me@myRandomHostName, and by setting the custom ip to my static LAN IP.

How is a similar setup achievable with Conversations? (Without the custom host/ip/port option) (And without purchasing a DNS) (And preferably without something as demonic as jkufner's Method 2)

[jkufner]

wiseoldman95 wrote, on 5.2.2015 19:43:

I don't understand this at all. You are claiming it is not needed;
either you're missing some use cases or I'm misunderstanding something.
Because I don't see how it can be done without a custom host in some
cases. Allow me to use my personal case as an example:

1. I have a raspberry Pi behind a home NAT router, the Raspberry Pi is
   my private XMPP server, it is unfederated.

Then use Raspberry's hostname as JID domain. It does not have to be
reachable from outside.

1. I have a static IP, but I don't have a DNS.

Get a DNS record. Static IP is not much use without it anyway.

1. My friends connect to the server from the WAN side via xabber by
   typing friendname@myRandomHostName , and by setting the custom ip to
   my wan-ip

Get a DNS record and use it instead of myRandomHostName.

1. I connect to the server from the LAN side only, by typing
   me@myRandomHostName, and by setting the custom ip to my static LAN IP.

Get a DNS record and use it instead of myRandomHostName and make sure
routing from LAN to outter IP address works (or use local DNS server).

As a bonus, you can have working e-mail using the same address as is
your JID. And it will start working as part of the federated network.

You can use some DNS record provided by your internet provider, or you
can get yourself a domain. I got mine recently and I'm wondering why I
did not get my domain years ago. It helps with many other problems. And
it costs like one beer per month.

I know it sounds a bit ugly, but really, DNS is required by XMPP.

[SafwatHalaby]

Why is this not always feasible? If you're using DNS (even with a fake internal hostname or something)

I don't see how that would work WAN side without purchasing DNS.

So basically all the points (With the exception of port mapping) boil down to: Fix NAT loopback issues and/or purchase a DNS. Is that correct?

[SamWhited]

@wiseoldman95 Ah, sorry, forgot you wanted it accessible from LAN and WAN.

As long as you're using a standard port it shouldn't matter either way though (just set yourname@yourhostname and be done)). If you're not using a standard port, ask yourself if there's really a reason to be using something else?

[zxiu-bonofa]

We have a similar demand for a reason:
our company have already many exist users in the system. They are registered with their own email. We already successful register the jabber-id in ejabber Server with their own email (also the username in our system). There is no problem by communication test with some client as Adium, for the server host/port can be set separatly. We will not let our user to register/remember another id(jabber) for the messenger function, but try to let them merge into it seamless. So we need to set the server's host (in client's background). Btw, the server's host could change by developing and after publishing. There is no reason that let user to change their domain part of jabber-id by switching the server.

[andersruneson]

Can you set up SRV-records like this?
https://github.com/siacs/Conversations#where-can-i-set-up-a-custom-hostname--port

On 11 February 2015 at 10:21, zxiu notifications@github.com wrote:

We have a similar demand for a reason:
our company have already many exist users in the system. They are
registered with their own email. We already successful register the
jabber-id in ejabber Server with their own email (also the username in our
system). There is no problem by communication test with some client as
Adium, for the server host/port can be set separatly. We will not let our
user to register/remember another id(jabber) for the messenger function,
but try to let them merge into it seamless. So we need to set the server's
host (in client's background). Btw, the server's host could change by
developing and after publishing. There is no reason that let user to change
their domain part of jabber-id by switching the server.

—
Reply to this email directly or view it on GitHub
#962 (comment).

[jkufner]

SRV records does not work per-user. If users use their own e-mail addrss
as JID, then XMPP network have no way to figure out which server given
user uses. That is how Jabber works. There is no roaming or anything
like that.

[zxiu-bonofa]

-> Can you set up SRV-records like this? https://github.com/siacs/Conversations#where-can-i-set-up-a-custom-hostname--port

I think the difficulty : the user have different email as username, which are not the server under our control.... we can't do anything to the google's server for a user1@gmail.com..

-> "SRV records does not work per-user. If users use their own e-mail addrss as JID, then XMPP network have no way to figure out which server given user uses. That is how Jabber works. There is no roaming or anything like that."
I am not so familiar with how xmpp works. What i tested is the customized jabber-id(different domain part as the server's host) on our test server works problemlos with desktop client Adium (by setting the server's host). So do with the Xabberd.

[andersruneson]

I assumed the company have one mail domain. But in this case the users used
their private mail address as JID?? Ok, really strange.

On 11 February 2015 at 11:10, zxiu notifications@github.com wrote:

Can you set up SRV-records like this?
https://github.com/siacs/Conversations#where-can-i-set-up-a-custom-hostname--port

I think the difficulty : the user have different email as username, which
are not the server under our control.... we can't do anything to the
google's server for a user1@gmail.com..

—
Reply to this email directly or view it on GitHub
#962 (comment).

[zxiu-bonofa]

Yes, for the messenger function is not a separat function to our system but a embed demand. We have already lots of user register/login them self with their own email. We definitly don't want our user remember another jabber-id@ourcompany.com

[andersruneson]

I don't really understand (maybe your english) why you can't use
username@companyserver.com or company-emailadress (probably
firstname.lastname@companyserver.com) as JID.

On 11 February 2015 at 11:17, zxiu notifications@github.com wrote:

Yes, for the messenger function is not a separat function to our system
but a embed demand. We have already lots of user register/login them self
with their own email. We are definitly want our user to remember another
jabber-id@ourcompany.com

—
Reply to this email directly or view it on GitHub
#962 (comment).

[iNPUTmice]

@zxiu this is a valid but special request that is not something that is suitable for mainline Conversations since this would also break federation. I would advise you to create your custom version of Conversations as described here: http://conversations.im/#development - You are probably planning on doing this anyway because I guess you don't want your customers to buy the official version from the PlayStore.

[zxiu-bonofa]

Because the user register them self like tom@gmail.com, tom@outlook.com, jerry@gmx.de
The boss will not agree that our user must login the messenger with a new jabber-id as:
tom@mycompany.com. It is very user unfriendly. Btw, user could have same local part but different domain for their email, as tom@gmail /outlook/. We dont want to let user have to remember their new messenger id is tom6@mycompany.com. They should just login as the username registered in our system.

[iNPUTmice]

@zxiu but you also don't want your users to enter the server address manually. This is way I'm advising to hardcode your server values in a special version of Conversations requiring the user to enter only their email / password instead of email / password / server name.
If you need assistance in doing so I'm available for hire.

[zxiu-bonofa]

-> " iNPUTmice " I tried but failed :D . What i did is to modify the class Account->getServer()
I let that function return only a Jid.fromString("testserver.mycompany.com"). It doesn't work with a SSL Exception...For i am not a professional in xmpp/ssl..

[jkufner]

Then their JIDs should be tom%gmail.com@yourserver.com,
tom%outlook.com@yourserver.com, and jerry%gmx.de@yourserver.com.

But if you already have lots of them, you are out of luck.

[zxiu-bonofa]

Btw, the trustmanager dialog shows, and i choosed always. After that the authrization fails.
java.security.cert.CertificateException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
.....
.....

javax.net.ssl.SSLPeerUnverifiedException: No peer certificate

when the test jabber-id domain is with the same domain of test-server it works without any problem.

[andersruneson]

The "users" are not employees? But customers of your company?

On 11 February 2015 at 11:30, Josef Kufner notifications@github.com wrote:

Then their JIDs should be tom%gmail.com@yourserver.com,
tom%outlook.com@yourserver.com, and jerry%gmx.de@yourserver.com.

But if you already have lots of them, you are out of luck.

—
Reply to this email directly or view it on GitHub
#962 (comment).

[zxiu-bonofa]

->"The "users" are not employees? But customers of your company?"
That is right. The xmpp's user should be the customers of my company which register themself with their own email.

[SafwatHalaby]

May I ask the devs why are they so reluctant to implement this, considering the fact that it has no real disadvantages and that implementation is a piece of cake?

[kevindelaney]

I threw this together really quickly and it seems to work for my basic needs. Hoping the dev team will merge it in and polish it up a bit.

#1003

[iNPUTmice]

Hi @kevindelaney
Thanks for the PR. I'm not going to merge this for reasons already discussed by @SamWhited, @jkufner and myself. However I'm going to leave the PR open for other people to see and use. If someone likes to toy around and run an XMPP server on their soho router they can now decide between going through the trouble of building and patching Conversations or setting up DNS properly.

I'm closing this issue because I feel that everything that needed to be said was said already. But this issue will be linked from our website: conversations.im/#dns. This way people will also be able to find your PR.

[SafwatHalaby]

Unless I've missed something, you never mentioned why you do not plan to implement it, you only mentioned why the alternative is better (which is arguable in some cases).
If you answer the why not, I'd consider this issue complete. (Or, alternatively, point me to where that was already answered).

[SamWhited]

This has been discussed MANY times, here and on the MUC. It's getting tiresome.

[SafwatHalaby]

Honestly, even after re-reading this post again entirely, I can only find stuff that explain why SRV is better, and not why custom host/IP will not be implemented.
The only genuine answer to why not is this part written by @iNPUTmice.

If have a general feeling that these settings will benefit mostly people who'd like to toy around and run an XMPP server on their $20 wifi home router. While there is nothing wrong with that those people are not the target audience of Conversations.

[ghost]

Then that should have been the end of the discussion. Also, Xabber is shit, you should probably be using ChatSecure.

[SafwatHalaby]

Yes, I am not claiming it's a bad argument. In normal circumstances the discussion should have ended there, but this issue was intended to include everything, and it did. So all is good :)

I'm just asking whether there are any additional arguments to why not, if there aren't, it's fine too.

(Though in my personal opinion, that particular argument is a bit weak because adding that feature does not really compromise the experience for non tech savvy users, and opens the door for some tech savvy users, and is easy to implement)

[SafwatHalaby]

Edit: slightly edited the whole post

This is probably the last post I will make here, I think that in additional to the others, it sums up everything I have to say.

@SamWhited

If these people can setup an XMPP server, they can setup a DNS server.

Purchasing a DNS costs money, although the cost may seem negligible to you, it is not negligible to some, it also introduces reliance on a third party (the DNS), sometimes this is not wanted - LANs, private networks, paranoid guys ... etc. read 3rd paragraph counting from the bottom for a good example.

Setting up a custom DNS server requires some serious tampering with Android in order to get it to work. This is not feasible if you have 10 friends wanting to connect to your custom server, unless you have the time and energy to root and then tamper with 10 phones. On LAN-only servers where you don't need the WAN, one may alternatively tamper with the router as @jkufner suggested and leave Android alone, but depending on the exact situation, this could be really dirty work. Also, one doesn't always have access to the router settings (e.g. dorms).

I'd like to point out that none of the methods you guys proposed cover the use case I talked about, perhaps I was vague, here is a more precise descrption:
-An XMPP server is running on a home server, e.g. Raspberry Pi
-The owner has a static IP but has NOT purchased a Domain
-The owner wants his friends to connect to his XMPP without tampering with/rooting their phones, the connections should be allowed WAN/LAN side (I am completely ignoring NAT Loopback issues and assuming they do not exist, but that is not always the case).

The solutions I can see:
-Purchase a DNS
-Get your friends to use the name@ip scheme
-Implement the custom host/ip thing

The first one costs money. It works perfectly if the server is always on WAN. It does not work if you're on the LAN side of the server and you have NAT loopback issues. Also, it imposes an unneeded dependency on the WAN side: If two LAN people want to communicate, then WAN must be connected. This is a disaster in places where the Internet connection is shaky.

The second one is actually very good for some use cases, assuming you can get your server software to to accept it. I am not sure it covers all use cases though. Also, it could cause roster problems if the server's static IP is ever changed.

The third one always works.

I believe I provided at least one example where SRV are of no use.

[andersruneson]

10 friends can afford a DNS.
On 2 Mar 2015 20:25, "wiseoldman95" notifications@github.com wrote:

This is probably the last post I will make here, I think that in
additional to the others, it sums up everything I have to say.

@SamWhited https://github.com/SamWhited

If these people can setup an XMPP server, they can setup a DNS server.

Purchasing a DNS costs money, although the cost may seem negligible to
you, it is not negligible to some, it also introduces reliance on a third
party (the DNS), sometimes this is not wanted (private networks, paranoid
guys).

Setting up a custom DNS server requires some serious tampering with
Android in order to get it to work. This is not feasible if you have 10
friends wanting to connect to your custom server, unless you have the time
and energy to root and then tamper with 10 phones. On LAN-only servers
where you don't need the WAN, one may alternatively tamper with the router
as @jkufner https://github.com/jkufner suggested and leave Android
alone, but that depends on the router model and, depending on the exact
situation, could be really dirty work.

I'd like to point out that none of the methods you guys proposed cover the
use case I talked about, perhaps I was vague, here is a more precise
descrption:
-An XMPP server is running on a Raspberry Pi
-The owner has a static IP but has NOT purchased a Domain
-The owner wants his friends to connect to his XMPP without tampering
with/rooting their phones, the connections should be allowed WAN/LAN side (I
am completely ignoring NAT Loopback issues and assuming they do not exist,
but that is not always the case).

The solutions I can see:
-Purchase a DNS, not feasible for everyone.
-Get your friends to use the name@ip scheme
-Implement the custom host/ip thing

The first one costs money. It works perfectly if the server is always on
WAN. It does not work if you're on the LAN side of the server and you have
NAT loopback issues. Also, it imposes an unneeded dependency on the WAN
side: If two LAN people want to communicate, then WAN must be connected.
This is a disaster in places where WAN is not always available.

The second one is actually very good for some use cases, assuming you can
get your server software to to accept it. I am not sure it covers all use
cases though. Also, it could cause rooster problems if the server's static
IP is ever changed.

The third one always works.

—
Reply to this email directly or view it on GitHub
#962 (comment).

[jkufner]

The primary reason for not including this feature is because it breaks
Jabber's federation. When servers are not properly configured, they
cannot connect to each other and it degrades experience of all Jabber
users. Just imagine you could not send e-mails from one server to
another. This is the same case.

wiseoldman95 wrote, on 2.3.2015 20:25:

Purchasing a DNS costs money, although the cost may seem negligible to
you, it is not negligible to some, it also introduces reliance on a
third party (the DNS), sometimes this is not wanted (private networks,
paranoid guys).

You don't have to rely on 3rd party servers on private network. You can,
and you should, have private caching DNS server installed on your
network and this server can provide you with your DNS records. These DNS
records can be copy of publicly available ones, or it can be a more
specific local version (hosts on private IP addresses).

Btw, ClouDNS gives you three dynamic DNS
zones for free. You can configure everything, including SRV records. And
"dynamic" means you can use it even if you have public dynamic IP
address at your home (it should not change too often, tho).

[SafwatHalaby]

The primary reason for not including this feature is because it breaks Jabber's federation. When servers are not properly configured, they cannot connect to each other and it degrades experience of all Jabber users. Just imagine you could not send e-mails from one server to another. This is the same case.

That's a pretty good why not point. I added it to the Disadvantages of a "custom host/port" section. Any other why nots?

[oliver]

Just want to add my vote for adding support for custom hosts and ports. I want to experiment with MAM/XEP-0313 in some local testing setup (no federation, no public access at all, just LAN access), and Conversations is one of the very very few clients that support this feature at all.

I understand that XMPP requires DNS, and this is probably a good design decision for real-world XMPP setups; but for tinkering with XMPP this is pretty painful. I cannot set up a custom DNS record, because my home router does not support this; and replacing this router (which is deeply integrated in my home network) with some custom system is quite high a price to pay just for tinkering with a chat server.

Other XMPP client developers have apparently recognized that the requirement for DNS can be cumbersome, and support using their client also without setting up specific DNS records.

It boils down not so much to a technical issue but to the developer's choice of audience. And I respect your choice of a specific target audience for Conversations, and accept that I'm not part of this audience; but I want to have it recorded that in my opinion this choice is detrimental for the general development of XMPP.

[strb]

@oliver You don't need to replace your router. If the home network you built is complicated enough for a router to be "deeply integrated", I'm sure you'll be able to figure out how to set up bind or add some /etc/hosts entries or something. It's really not that hard. Numerous workarounds have been suggested and discussed in this issue (in one case even down to specific bind config snippets). Take your pick. You already said yourself that you recognize that Conversations is not a "tinker around with XMPP client".

I'm locking this issue because there is nothing more to say, and frankly, I'm tired of this discussion. If you have any further questions or comments, please bring it up in our MUC.