config option to set username string
alexlehm opened this issue · comments
I am using a bouncer based on soju which expects the network server name to be included in the username string like username/irc.server.net to correctly map the channel names to the different networks joined, if that is not set they are #channel/servername instead
I have not found an option to set a username string however, i can only set nickname
This is a common request, but it makes some incorrect assumptions.
ident is not provided by the client process, it's the OS on the device telling you about the client process.
The original purpose of ident is to allow a server to distinguish different users on a single host that are making connections to that server. Most implementations return the name corresponding to the UID of the process that has the socket open. On an Android device, each app runs with a separate UID, so the natural value for ident would be the name of the app that's running. If you want the name of the device (or the name of the owner of the device) then there are several alternative services for that, including performing a "chaos" DNS query on port 53.
On a Linux or Unix system, the ident that listens for requests and answers them service is provided by the identd system daemon. And yes that includes Android, which is Linux under the hood. Whilst in theory you could install an app that provides that service, it would
- need to run as root, because it's listening to a privileged TCP port; and
- (if you don't want it to provide the same answer for all ports) need to provide a registration service that other apps can use to tell it what it should report when asked.
Basically no ordinary app is going to be granted those privileges by stock Android; you should be asking Google to provide identd and an API for apps to register their preferred response on any socket they open.
I may be using the term ident string wrong, the client I use on Windows calls the config option ident, this is not actually the ident protocol since my network connection has CGNAT and does not support incoming connections.
It might be better to call it username string, the one that is sent with the USER command
In IRC terminology, the primary identity is the "nickname" or "nick". That's almost certainly what Soju calls "username". (Some networks allow users to connect without any authentication; some allow users to authenticate using different a "primary" nick while using a different one as the session identifier; some do both.)
Proxies/bouncers are generally constructed to be transparent between the client and server, but some proxies support connecting to multiple servers from a single client session, and this is why the network is included in the "username" or "nickname" field.
(Personally I don't use that; I use a separate client connection for each server connection; this produces more "normal" behaviour in the IRC client.)
the nickname in this case is my plain username (alexlehm), the "connection" name is something else.
it is something like
telnet host 6668
Trying nnn...
Connected to host.
Escape character is '^]'.
PASS ***
NICK alexlehm
USER alexlehm/irc.server.net alexlehm * :Alex
:irc.server.net 001 alexlehm :Welcome to suika, alexlehm
:host 002 alexlehm :Your host is irc.server.net
the NICK can be changed, the USER stays the same
There are two sets of user/pass in play: the set which the client uses to authenticate to the Soju proxy, and then the set which Soju uses to authenticate to the actual server.
If Soju requires some odd sequence of commands to be sent, probably the simplest way to handle that is to put them in the "Auto-run commands" section of the server configuration in Revolution-IRC.
You might like to try ZNC rather than Soju; it can be configured through its web interface, so it's rather more obvious where the server-side username & password go.
that doesn't work either, probably the USER command appears twice and the 2nd is rejected
I used ZNC before but the community I joined suggested soju as a better alternative, might not be the best choice after all
after checking some more possible configurations, I think it would be necessary to support setting a 2nd parameter in addition to the nickname field to set the username field