bdd0c7bc06
TL;DR: supports for casemapping, now logs are saved in casemapped/canonical/tolower form (eg. in the #channel directory instead of #Channel... or something) == What is casemapping? == see <https://modern.ircdocs.horse/#casemapping-parameter> == Casemapping and multi-upstream == Since each upstream does not necessarily use the same casemapping, and since casemappings cannot coexist [0], 1. soju must also update the database accordingly to upstreams' casemapping, otherwise it will end up inconsistent, 2. soju must "normalize" entity names and expose only one casemapping that is a subset of all supported casemappings (here, ascii). [0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same user (upstreams that advertise rfc1459 for example), while on others (upstreams that advertise ascii) they don't. Once upstream's casemapping is known (default to rfc1459), entity names in map keys are made into casemapped form, for upstreamConn, upstreamChannel and network. downstreamConn advertises "CASEMAPPING=ascii", and always casemap map keys with ascii. Some functions require the caller to casemap their argument (to avoid needless calls to casemapping functions). == Message forwarding and casemapping == downstream message handling (joins and parts basically): When relaying entity names from downstreams to upstreams, soju uses the upstream casemapping, in order to not get in the way of the user. This does not brings any issue, as long as soju replies with the ascii casemapping in mind (solves point 1.). marshalEntity/marshalUserPrefix: When relaying entity names from upstreams with non-ascii casemappings, soju *partially* casemap them: it only change the case of characters which are not ascii letters. ASCII case is thus kept intact, while special symbols like []{} are the same every time soju sends them to downstreams (solves point 2.). == Casemapping changes == Casemapping changes are not fully supported by this patch and will result in loss of history. This is a limitation of the protocol and should be solved by the RENAME spec. |
||
|---|---|---|
| cmd | ||
| config | ||
| contrib | ||
| doc | ||
| .build.yml | ||
| .editorconfig | ||
| .gitignore | ||
| bridge.go | ||
| conn.go | ||
| db.go | ||
| downstream.go | ||
| go.mod | ||
| go.sum | ||
| ident.go | ||
| irc.go | ||
| LICENSE | ||
| Makefile | ||
| msgstore.go | ||
| msgstore_fs.go | ||
| msgstore_memory.go | ||
| README.md | ||
| server.go | ||
| service.go | ||
| upstream.go | ||
| user.go | ||
soju
A user-friendly IRC bouncer.
- Multi-user
- Support multiple clients for a single user, with proper backlog synchronization
- Support connecting to multiple upstream servers via a single IRC connection to the bouncer
Usage
See the man page at doc/soju.1.scd for more information.
Server side
To create an admin user and start soju, run these commands:
go run ./cmd/sojuctl create-user <soju username> -admin
go run ./cmd/soju -listen irc+insecure://127.0.0.1:6667
If you're migrating from ZNC, a tool is available to import users, networks and channels from a ZNC config file:
go run ./contrib/znc-import.go <znc config file>
Client side
soju can operate in two different modes: multi upstream and single upstream.
Single upstream mode
In this mode, 1 upstream connection to a irc server = 1 connection to your soju bouncer.
The easiest and fastest way to use this is to specify the address of the server
in your username in your client configuration. For example to connect to
Freenode, your username will be: <soju username>/chat.freenode.net. Also set
your soju password in the password field of your client configuration.
This will autoconfigure soju by adding a network with the address
chat.freenode.net and then autoconnect to it. You will now be able to join
any channel like you would normally do.
Multi upstream mode
In this mode, a single connection to your soju bouncer can handle multiple
upstream connections. You will need to manually configure each upstream
connection using the the special BouncerServ user.
Connect to your soju server by specifying your soju username in the username field in your client and your password in the password field.
You should now be able to send private messages to the BouncerServ. You can
send it commands to configure soju. Create new networks:
/msg BouncerServ network create -addr chat.freenode.net -name freenode
/msg BouncerServ network create -addr irc.rizon.net -name rizon
You will now be able to join channels on these networks by specifying their name:
/join #soju/freenode
/join #somechannel/rizon
Notes
soju will automatically save and restore the channels you were connected to.
Contributing
Send patches on the mailing list or on GitHub, report bugs on the issue tracker. Discuss in #soju on Freenode.
License
AGPLv3, see LICENSE.
Copyright (C) 2020 The soju Contributors