First rst attempt
This commit is contained in:
+37
-32
@@ -1,65 +1,63 @@
|
||||
INSTALL
|
||||
=======
|
||||
|
||||
tl;dr
|
||||
=====
|
||||
-----
|
||||
|
||||
cmake . && make && ./biboumi
|
||||
|
||||
If that didn’t work, read on.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
------------
|
||||
|
||||
Build and runtime dependencies:
|
||||
|
||||
Tools:
|
||||
~~~~~~
|
||||
|
||||
- A C++14 compiler (clang >= 3.4 or gcc >= 4.9 for example)
|
||||
- CMake
|
||||
- ronn (optional) to build the man page
|
||||
|
||||
Libraries:
|
||||
~~~~~~~~~~
|
||||
|
||||
- expat
|
||||
expat_
|
||||
Used to parse XML from the XMPP server.
|
||||
http://expat.sourceforge.net/
|
||||
|
||||
- libiconv
|
||||
libiconv_
|
||||
Encoding from anything into UTF-8
|
||||
http://www.gnu.org/software/libiconv/
|
||||
|
||||
- libuuid
|
||||
libuuid_
|
||||
Generate unique IDs
|
||||
http://sourceforge.net/projects/libuuid/
|
||||
|
||||
- libidn (optional, but recommended)
|
||||
libidn_ (optional, but recommended)
|
||||
Provides the stringprep functionality. Without it, JIDs for IRC users are
|
||||
not provided.
|
||||
http://www.gnu.org/software/libidn/
|
||||
|
||||
- c-ares (optional, but recommended)
|
||||
c-ares_ (optional, but recommended)
|
||||
Asynchronously resolve domain names. This offers better reactivity and
|
||||
performances when connecting to a big number of IRC servers at the same
|
||||
time.
|
||||
http://c-ares.haxx.se/
|
||||
|
||||
- libbotan 1.11 (optional)
|
||||
libbotan_ 1.11 (optional)
|
||||
Provides TLS support. Without it, IRC connections are all made in
|
||||
plain-text mode.
|
||||
Other branches than the 1.11 are not supported.
|
||||
http://botan.randombit.net/
|
||||
|
||||
- litesql (optional)
|
||||
litesql_ (optional)
|
||||
Provides a way to store various options in a (sqlite3) database. Each user
|
||||
of the gateway can store their own values (for example their prefered port,
|
||||
or their IRC password).
|
||||
http://git.louiz.org/litesql
|
||||
|
||||
- systemd (optional)
|
||||
systemd_ (optional)
|
||||
Provides the support for a systemd service of Type=notify. This is useful only
|
||||
if you are packaging biboumi in a distribution with Systemd.
|
||||
|
||||
|
||||
Configure
|
||||
=========
|
||||
---------
|
||||
|
||||
Configure the build system using cmake, there are many solutions to do that,
|
||||
the simplest is to just run
|
||||
@@ -90,8 +88,9 @@ The list of available options:
|
||||
|
||||
- POLLER: lets you select the poller used by biboumi, at
|
||||
compile-time. Possible values are:
|
||||
EPOLL: use the Linux-specific epoll(7). This is the default on Linux.
|
||||
POLL: use the standard poll(2). This is the default value on all non-Linux
|
||||
|
||||
- EPOLL: use the Linux-specific epoll(7). This is the default on Linux.
|
||||
- POLL: use the standard poll(2). This is the default value on all non-Linux
|
||||
platforms.
|
||||
|
||||
- WITH_BOTAN and WITHOUT_BOTAN: The first force the usage of the Botan library,
|
||||
@@ -108,7 +107,7 @@ The list of available options:
|
||||
|
||||
Example:
|
||||
|
||||
cmake . -DCMAKE_BUILD_TYPE=release -DCMAKE_INSTALL_PREFIX \
|
||||
cmake . -DCMAKE_BUILD_TYPE=release -DCMAKE_INSTALL_PREFIX=/usr
|
||||
-DWITH_BOTAN=1 -DWITHOUT_SYSTEMD=1
|
||||
|
||||
This command will configure the project to build a release, with TLS enabled
|
||||
@@ -116,24 +115,21 @@ This command will configure the project to build a release, with TLS enabled
|
||||
|
||||
|
||||
Build
|
||||
=====
|
||||
|
||||
- Once you’ve configured everything using cmake, build the project
|
||||
-----
|
||||
Once you’ve configured everything using cmake, build the project
|
||||
|
||||
make
|
||||
|
||||
|
||||
Install
|
||||
=======
|
||||
|
||||
- And then, optionaly, Install the software system-wide
|
||||
-------
|
||||
And then, optionaly, Install the software system-wide
|
||||
|
||||
make install
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
-------
|
||||
You can run the test suite with
|
||||
|
||||
make check
|
||||
@@ -149,8 +145,17 @@ This requires gcov and lcov to be installed.
|
||||
|
||||
|
||||
Run
|
||||
===
|
||||
|
||||
---
|
||||
Run the software using the `biboumi` binary. Read the documentation (the
|
||||
man page biboumi(1) or the `biboumi.1.md` file) for more information on how
|
||||
man page biboumi(1) or the `biboumi.1.rst`_ file) for more information on how
|
||||
to use biboumi.
|
||||
|
||||
.. _expat: http://expat.sourceforge.net/
|
||||
.. _libiconv: http://www.gnu.org/software/libiconv/
|
||||
.. _libuuid: http://sourceforge.net/projects/libuuid/
|
||||
.. _libidn: http://www.gnu.org/software/libidn/
|
||||
.. _libbotan: http://botan.randombit.net/
|
||||
.. _c-ares: http://c-ares.haxx.se/
|
||||
.. _litesql: http://git.louiz.org/litesql
|
||||
.. _systemd: https://www.freedesktop.org/wiki/Software/systemd/
|
||||
.. _biboumi.1.rst: doc/biboumi.1.rst
|
||||
+10
-9
@@ -21,21 +21,21 @@ important goal is to keep the software (and its code) light and simple.
|
||||
|
||||
|
||||
Install
|
||||
=======
|
||||
Refer to the [INSTALL][] file.
|
||||
-------
|
||||
Refer to the INSTALL_ file.
|
||||
|
||||
|
||||
Usage
|
||||
=====
|
||||
|
||||
Read [the documentation](doc/biboumi.1.md).
|
||||
-----
|
||||
Read `the documentation`_.
|
||||
|
||||
Authors
|
||||
=======
|
||||
-------
|
||||
Florent Le Coz (louiz’) <louiz@louiz.org>
|
||||
|
||||
|
||||
Contact/Support
|
||||
===============
|
||||
---------------
|
||||
* XMPP ChatRoom: biboumi@muc.poez.io
|
||||
* Report a bug: https://dev.louiz.org/projects/biboumi/issues/new
|
||||
|
||||
@@ -51,11 +51,12 @@ beforehand.
|
||||
|
||||
|
||||
Licence
|
||||
=======
|
||||
-------
|
||||
Biboumi is Free Software.
|
||||
(learn more: http://www.gnu.org/philosophy/free-sw.html)
|
||||
|
||||
Biboumi is released under the zlib license.
|
||||
Please read the COPYING file for details.
|
||||
|
||||
[INSTALL]: INSTALL
|
||||
.. _INSTALL: INSTALL.rst
|
||||
.. _the documentation: doc/biboumi.1.rst
|
||||
@@ -1,77 +1,92 @@
|
||||
BIBOUMI 1 "2014-06-02"
|
||||
======================
|
||||
=======================
|
||||
Biboumi(1) User Manual
|
||||
=======================
|
||||
|
||||
.. contents:: :depth: 2
|
||||
|
||||
|
||||
NAME
|
||||
----
|
||||
====
|
||||
|
||||
biboumi - XMPP gateway to IRC
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Description
|
||||
===========
|
||||
|
||||
Biboumi is an XMPP gateway that connects to IRC servers and translates
|
||||
between the two protocols. It can be used to access IRC channels using any
|
||||
XMPP client as if these channels were XMPP MUCs.
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
Synopsis
|
||||
========
|
||||
|
||||
`biboumi` [`config_filename`]
|
||||
biboumi [*config_filename*\ ]
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
Options
|
||||
=======
|
||||
|
||||
Available command line options:
|
||||
|
||||
`config_filename`
|
||||
config_filename
|
||||
---------------
|
||||
|
||||
Specify the file to read for configuration. See *CONFIG* section for more
|
||||
details on its content.
|
||||
|
||||
CONFIG
|
||||
------
|
||||
Configuration
|
||||
=============
|
||||
|
||||
The configuration file uses a simple format of the form
|
||||
`"option=value"`. Here is a description of each possible option:
|
||||
``option=value``. Here is a description of each possible option:
|
||||
|
||||
`hostname` (mandatory)
|
||||
The configuration can be re-read at runtime (you can for example change the
|
||||
log level without having to restart biboumi) by sending SIGUSR1 or SIGUSR2
|
||||
(see kill(1)) to the process.
|
||||
|
||||
The hostname served by the XMPP gateway. This domain must be configured in
|
||||
the XMPP server as an external component. See the manual for your XMPP
|
||||
server for more information.
|
||||
For prosody, see http://prosody.im/doc/components#adding_an_external_component
|
||||
hostname
|
||||
--------
|
||||
|
||||
`password` (mandatory)
|
||||
Mandatory. The hostname served by the XMPP gateway. This domain must be
|
||||
configured in the XMPP server as an external component. See the manual
|
||||
for your XMPP server for more information. For prosody, see
|
||||
http://prosody.im/doc/components#adding_an_external_component
|
||||
|
||||
The password used to authenticate the XMPP component to your XMPP server.
|
||||
This password must be configured in the XMPP server, associated with the
|
||||
external component on *hostname*.
|
||||
password
|
||||
--------
|
||||
|
||||
`xmpp_server_ip`
|
||||
Mandatory. The password used to authenticate the XMPP component to your
|
||||
XMPP server. This password must be configured in the XMPP server,
|
||||
associated with the external component on *hostname*.
|
||||
|
||||
The IP address to connect to the XMPP server on. The connection to the XMPP
|
||||
server is unencrypted, so the biboumi instance and the server should normally
|
||||
be on the same host. The default value is 127.0.0.1.
|
||||
xmpp_server_ip
|
||||
--------------
|
||||
|
||||
`port`
|
||||
The IP address to connect to the XMPP server on. The connection to the
|
||||
XMPP server is unencrypted, so the biboumi instance and the server should
|
||||
normally be on the same host. The default value is 127.0.0.1.
|
||||
|
||||
port
|
||||
----
|
||||
|
||||
The TCP port to use to connect to the local XMPP component. The default
|
||||
value is 5347.
|
||||
|
||||
`admin`
|
||||
admin
|
||||
-----
|
||||
|
||||
The bare JID of the gateway administrator. This JID will have more
|
||||
privileges than other standard users (the admin thus needs to check their
|
||||
privileges), for example some administration ad-hoc commands will only be
|
||||
available to that JID.
|
||||
|
||||
`fixed_irc_server`
|
||||
fixed_irc_server
|
||||
----------------
|
||||
|
||||
If this option contains the hostname of an IRC server (for example
|
||||
irc.example.org), then biboumi will enforce the connexion to that IRC
|
||||
server only. This means that a JID like "#chan@biboumi.example.com" must
|
||||
be used instead of "#chan%irc.example.org@biboumi.example.com". In that
|
||||
mode, the virtual channel (see *Connect to an IRC server*) is not
|
||||
mode, the virtual channel (see `Connect to an IRC server`_) is not
|
||||
available and you still need to use the ! separator to send message to an
|
||||
IRC user (for example "foo!@biboumi.example.com" to send a message to
|
||||
foo), although the in-room JID still work as expected
|
||||
@@ -83,18 +98,20 @@ The configuration file uses a simple format of the form
|
||||
users join their own IRC server using an XMPP client, while forbidding
|
||||
access to any other IRC server.
|
||||
|
||||
`realname_customization`
|
||||
realname_customization
|
||||
----------------------
|
||||
|
||||
If this option is set to “false” (default is “true”), the users will not be
|
||||
able to use the ad-hoc commands that lets them configure their realname and
|
||||
username.
|
||||
|
||||
`realname_from_jid`
|
||||
realname_from_jid
|
||||
-----------------
|
||||
|
||||
If this option is set to “true”, the realname and username of each biboumi
|
||||
user will be extracted from their JID. The realname is their bare JID, and
|
||||
the username is the node-part of their JID. Note that if
|
||||
`realname_customization` is “true”, each user will still be able to
|
||||
``realname_customization`` is “true”, each user will still be able to
|
||||
customize their realname and username, this option just decides the default
|
||||
realname and username.
|
||||
|
||||
@@ -102,31 +119,36 @@ The configuration file uses a simple format of the form
|
||||
username of each user will be set to the nick they used to connect to the
|
||||
IRC server.
|
||||
|
||||
`webirc_password`
|
||||
webirc_password
|
||||
---------------
|
||||
|
||||
Configure a password to be communicated to the IRC server, as part of the
|
||||
WEBIRC message (see https://kiwiirc.com/docs/webirc). If this option is
|
||||
set, an additional DNS resolution of the hostname of each XMPP server will
|
||||
be made when connecting to an IRC server.
|
||||
|
||||
`log_file`
|
||||
log_file
|
||||
--------
|
||||
|
||||
A filename into which logs are written. If none is provided, the logs are
|
||||
written on standard output.
|
||||
|
||||
`log_level`
|
||||
log_level
|
||||
---------
|
||||
|
||||
Indicate what type of log messages to write in the logs. Value can be
|
||||
from 0 to 3. 0 is debug, 1 is info, 2 is warning, 3 is error. The
|
||||
default is 0, but a more practical value for production use is 1.
|
||||
|
||||
`ca_file`
|
||||
ca_file
|
||||
-------
|
||||
|
||||
Specifies which file should be use as the list of trusted CA when
|
||||
negociating a TLS session. By default this value is unset and biboumi
|
||||
tries a list of well-known paths.
|
||||
|
||||
`outgoing_bind`
|
||||
outgoing_bind
|
||||
-------------
|
||||
|
||||
An address (IPv4 or IPv6) to bind the outgoing sockets to. If no value is
|
||||
specified, it will use the one assigned by the operating system. You can
|
||||
@@ -134,27 +156,23 @@ The configuration file uses a simple format of the form
|
||||
interface with this address. Note that this is only used for connections
|
||||
to IRC servers.
|
||||
|
||||
The configuration can be re-read at runtime (you can for example change the
|
||||
log level without having to restart biboumi) by sending SIGUSR1 or SIGUSR2
|
||||
(see kill(1)) to the process.
|
||||
|
||||
USAGE
|
||||
-----
|
||||
Usage
|
||||
=====
|
||||
|
||||
Biboumi acts as a server, it should be run as a daemon that lives in the
|
||||
background for as long as it is needed. Note that biboumi does not
|
||||
daemonize itself, this task should be done by your init system (SysVinit,
|
||||
systemd, upstart).
|
||||
|
||||
When started, biboumi connects, without encryption (see *SECURITY*), to the
|
||||
local XMPP server on the port `5347` and authenticates with the provided
|
||||
password. Biboumi then serves the configured `hostname`: this means that
|
||||
When started, biboumi connects, without encryption (see `Security`_), to the
|
||||
local XMPP server on the port ``5347`` and authenticates with the provided
|
||||
password. Biboumi then serves the configured ``hostname``: this means that
|
||||
all XMPP stanza with a `to` JID on that domain will be forwarded to biboumi
|
||||
by the XMPP server, and biboumi will only send messages coming from that
|
||||
hostname.
|
||||
|
||||
When a user joins an IRC channel on an IRC server (see *Join an IRC
|
||||
channel*), biboumi connects to the remote IRC server, sets the user’s nick
|
||||
When a user joins an IRC channel on an IRC server (see `Join an IRC
|
||||
channel`_), biboumi connects to the remote IRC server, sets the user’s nick
|
||||
as requested, and then tries to join the specified channel. If the same
|
||||
user subsequently tries to connect to an other channel on the same server,
|
||||
the same IRC connection is used. If, however, an other user wants to join
|
||||
@@ -168,38 +186,39 @@ communication is acknowledged by all IRC servers. If one or more IRC
|
||||
servers do not respond, biboumi will only exit if it receives the same
|
||||
signal again or if a 2 seconds delay has passed.
|
||||
|
||||
### Addressing
|
||||
Addressing
|
||||
----------
|
||||
|
||||
IRC entities are represented by XMPP JIDs. The domain part of the JID is
|
||||
the domain served by biboumi (the part after the `@`, biboumi.example.com in
|
||||
the examples), and the local part (the part before the `@`) depends on the
|
||||
the domain served by biboumi (the part after the ``@``, biboumi.example.com in
|
||||
the examples), and the local part (the part before the ``@``) depends on the
|
||||
concerned entity.
|
||||
|
||||
IRC channels have a local part formed like this:
|
||||
`channel_name`%`irc_server`.
|
||||
``channel_name`` % ``irc_server``.
|
||||
|
||||
If the IRC channel you want to adress starts with the `'#'` character (or an
|
||||
other character, announced by the IRC server, like `'&'`, `'+'` or `'!'`),
|
||||
If the IRC channel you want to adress starts with the ``'#'`` character (or an
|
||||
other character, announced by the IRC server, like ``'&'``, ``'+'`` or ``'!'``),
|
||||
then you must include it in the JID. Some other gateway implementations, as
|
||||
well as some IRC clients, do not require them to be started by one of these
|
||||
characters, adding an implicit `'#'` in that case. Biboumi does not do that
|
||||
characters, adding an implicit ``'#'`` in that case. Biboumi does not do that
|
||||
because this gets confusing when trying to understand the difference between
|
||||
the channels *#foo*, and *##foo*. Note that biboumi does not use the
|
||||
presence of these special characters to identify an IRC channel, only the
|
||||
presence of the separator `%` is used for that.
|
||||
|
||||
The channel name can also be empty (for example `%irc.example.com`), in that
|
||||
The channel name can also be empty (for example ``%irc.example.com``), in that
|
||||
case this represents the virtual channel provided by biboumi. See *Connect
|
||||
to an IRC server* for more details.
|
||||
|
||||
There is two ways to address an IRC user, using a local part like this:
|
||||
`nickname`!`irc_server`
|
||||
``nickname`` ! ``irc_server``
|
||||
or by using the in-room address of the participant, like this:
|
||||
`channel_name`%`irc_server`@`biboumi.example.com`/`Nickname`
|
||||
``channel_name`` % ``irc_server`` @ ``biboumi.example.com`` / ``Nickname``
|
||||
|
||||
The second JID is available only to be compatible with XMPP clients when the
|
||||
user wants to send a private message to the participant `Nickname` in the
|
||||
room `channel_name%irc_server@biboumi.example.com`.
|
||||
user wants to send a private message to the participant ``Nickname`` in the
|
||||
room ``channel_name%irc_server@biboumi.example.com``.
|
||||
|
||||
On XMPP, the node part of the JID can only be lowercase. On the other hand,
|
||||
IRC nicknames are case-insensitive, this means that the nicknames toto,
|
||||
@@ -209,30 +228,30 @@ talk to the user toto, and this will work.
|
||||
Also note that some IRC nicknames may contain characters that are not
|
||||
allowed in the local part of a JID (for example '@'). If you need to send a
|
||||
message to a nick containing such a character, you have to use a jid like
|
||||
`%irc.example.com@biboumi.example.com/AnnoyingNickn@me`, because the JID
|
||||
`AnnoyingNickn@me!irc.example.com@biboumi.example.com` would not work.
|
||||
``%irc.example.com@biboumi.example.com/AnnoyingNickn@me``, because the JID
|
||||
``AnnoyingNickn@me!irc.example.com@biboumi.example.com`` would not work.
|
||||
|
||||
Examples:
|
||||
|
||||
`#foo%irc.example.com@biboumi.example.com` is the #foo IRC channel, on the
|
||||
* ``#foo%irc.example.com@biboumi.example.com`` is the #foo IRC channel, on the
|
||||
irc.example.com IRC server, and this is served by the biboumi instance on
|
||||
biboumi.example.com
|
||||
|
||||
`toto!irc.example.com@biboumi.example.com` is the IRC user named toto, or
|
||||
* ``toto!irc.example.com@biboumi.example.com`` is the IRC user named toto, or
|
||||
TotO, etc.
|
||||
|
||||
`irc.example.com@biboumi.example.com` is the IRC server irc.example.com.
|
||||
* ``irc.example.com@biboumi.example.com`` is the IRC server irc.example.com.
|
||||
|
||||
`%irc.example.com@biboumi.example.com` is the virtual channel provided by
|
||||
* ``%irc.example.com@biboumi.example.com`` is the virtual channel provided by
|
||||
biboumi, for the IRC server irc.example.com.
|
||||
|
||||
Note: Some JIDs are valid but make no sense in the context of
|
||||
biboumi:
|
||||
|
||||
`!irc.example.com@biboumi.example.com` is the empty-string nick on the
|
||||
* ``!irc.example.com@biboumi.example.com`` is the empty-string nick on the
|
||||
irc.example.com server. It makes no sense to try to send messages to it.
|
||||
|
||||
`#test%@biboumi.example.com`, or any other JID that does not contain an
|
||||
* ``#test%@biboumi.example.com``, or any other JID that does not contain an
|
||||
IRC server is invalid. Any message to that kind of JID will trigger an
|
||||
error, or will be ignored.
|
||||
|
||||
@@ -241,27 +260,30 @@ representing the “hostname” provided by the IRC server. This JID can only
|
||||
be used to set IRC modes (for example to ban a user based on its IP), or to
|
||||
identify user. It cannot be used to contact that user using biboumi.
|
||||
|
||||
### Join an IRC channel
|
||||
Join an IRC channel
|
||||
-------------------
|
||||
|
||||
To join an IRC channel `#foo` on the IRC server `irc.example.com`,
|
||||
join the XMPP MUC `#foo%irc.example.com@hostname`.
|
||||
To join an IRC channel ``#foo`` on the IRC server ``irc.example.com``,
|
||||
join the XMPP MUC ``#foo%irc.example.com@biboumi.example.com``.
|
||||
|
||||
### Connect to an IRC server
|
||||
Connect to an IRC server
|
||||
------------------------
|
||||
|
||||
The connection to the IRC server is automatically made when the user tries
|
||||
to join any channel on that IRC server. The connection is closed whenever
|
||||
the last channel on that server is left by the user. To be able to stay
|
||||
connected to an IRC server without having to be in a real IRC channel,
|
||||
biboumi provides a virtual channel on the jid
|
||||
`%irc.example.com@biboumi.example.com`. For example if you want to join the
|
||||
channel `#foo` on the server `irc.example.com`, but you need to authenticate
|
||||
``%irc.example.com@biboumi.example.com``. For example if you want to join the
|
||||
channel ``#foo`` on the server ``irc.example.com``, but you need to authenticate
|
||||
to a bot of the server before you’re allowed to join it, you can first join
|
||||
the room `%irc.example.com@biboumi.example.com` (this will effectively
|
||||
the room ``%irc.example.com@biboumi.example.com`` (this will effectively
|
||||
connect you to the IRC server without joining any room), then send your
|
||||
authentication message to the user `bot!irc.example.com@biboumi.example.com`
|
||||
and finally join the room `#foo%irc.example.com@biboumi.example.com`.
|
||||
authentication message to the user ``bot!irc.example.com@biboumi.example.com``
|
||||
and finally join the room ``#foo%irc.example.com@biboumi.example.com``.
|
||||
|
||||
### Channel messages
|
||||
Channel messages
|
||||
----------------
|
||||
|
||||
On XMPP, unlike on IRC, the displayed order of the messages is the same for
|
||||
all participants of a MUC. Biboumi can not however provide this feature, as
|
||||
@@ -270,14 +292,16 @@ messages to other users. This means that the order of the messages
|
||||
displayed in your XMPP client may not be the same than the order on other
|
||||
IRC users’.
|
||||
|
||||
### List channels
|
||||
List channels
|
||||
-------------
|
||||
|
||||
You can list the IRC channels on a given IRC server by sending an XMPP disco
|
||||
items request on the IRC server JID. The number of channels on some servers
|
||||
is huge, and biboumi does not (yet) support result set management (XEP 0059)
|
||||
so the result stanza may be very big.
|
||||
|
||||
### Nicknames
|
||||
Nicknames
|
||||
---------
|
||||
|
||||
On IRC, nicknames are server-wide. This means that one user only has one
|
||||
single nickname at one given time on all the channels of a server. This is
|
||||
@@ -295,7 +319,8 @@ nick on the whole server by mistake. If you want to have a different
|
||||
nickname in the channel you’re going to join, you need to do it explicitly
|
||||
with the NICK command before joining the channel.
|
||||
|
||||
### Private messages
|
||||
Private messages
|
||||
----------------
|
||||
|
||||
Private messages are handled differently on IRC and on XMPP. On IRC, you
|
||||
talk directly to one server-user: toto on the channel #foo is the same user
|
||||
@@ -306,43 +331,47 @@ previously sent a message to an in-room participant (something like
|
||||
\#test%irc.example.com@biboumi.example.com/nickname), in which case future
|
||||
messages from that same user will be received from that same “in-room” JID.
|
||||
|
||||
### Notices
|
||||
Notices
|
||||
-------
|
||||
|
||||
Notices are received exactly like private messages. It is not possible to
|
||||
send a notice.
|
||||
|
||||
### Kicks and bans
|
||||
Kicks and bans
|
||||
--------------
|
||||
|
||||
Kicks are transparently translated from one protocol to another. However
|
||||
banning an XMPP participant has no effect. To ban an user you need to set a
|
||||
mode +b on that user nick or host (see *MODES*) and then kick it.
|
||||
mode +b on that user nick or host (see `IRC modes`_) and then kick it.
|
||||
|
||||
### Encoding
|
||||
Encoding
|
||||
--------
|
||||
|
||||
On XMPP, the encoding is always `UTF-8`, whereas on IRC the encoding of
|
||||
On XMPP, the encoding is always ``UTF-8``, whereas on IRC the encoding of
|
||||
each message can be anything.
|
||||
|
||||
This means that biboumi has to convert everything coming from IRC into UTF-8
|
||||
without knowing the encoding of the received messages. To do so, it checks
|
||||
if each message is UTF-8 valid, if not it tries to convert from
|
||||
`iso_8859-1` (because this appears to be the most common case, at least
|
||||
on the channels I visit) to `UTF-8`. If that conversion fails at some
|
||||
point, a placeholder character `'�'` is inserted to indicate this
|
||||
``iso_8859-1`` (because this appears to be the most common case, at least
|
||||
on the channels I visit) to ``UTF-``. If that conversion fails at some
|
||||
point, a placeholder character ``'�'`` is inserted to indicate this
|
||||
decoding error.
|
||||
|
||||
Messages are always sent in UTF-8 over IRC, no conversion is done in that
|
||||
direction.
|
||||
|
||||
### IRC modes
|
||||
IRC modes
|
||||
---------
|
||||
|
||||
One feature that doesn’t exist on XMPP but does on IRC is the `modes`.
|
||||
One feature that doesn’t exist on XMPP but does on IRC is the ``modes``.
|
||||
Although some of these modes have a correspondance in the XMPP world (for
|
||||
example the `+o` mode on a user corresponds to the `moderator` role in
|
||||
example the ``+o`` mode on a user corresponds to the ``moderator`` role in
|
||||
XMPP), it is impossible to map all these modes to an XMPP feature. To
|
||||
circumvent this problem, biboumi provides a raw notification when modes are
|
||||
changed, and lets the user change the modes directly.
|
||||
|
||||
To change modes, simply send a message starting with “`/mode`” followed by
|
||||
To change modes, simply send a message starting with “``/mode``” followed by
|
||||
the modes and the arguments you want to send to the IRC server. For example
|
||||
“/mode +aho louiz”. Note that your XMPP client may interprete messages
|
||||
begining with “/” like a command. To actually send a message starting with
|
||||
@@ -356,54 +385,46 @@ notified of this XMPP event as well. For example if a mode “+o toto” is
|
||||
received, then toto’s role will be changed to moderator. The mapping
|
||||
between IRC modes and XMPP features is as follow:
|
||||
|
||||
`+q`
|
||||
``+q``
|
||||
Sets the participant’s role to ``moderator`` and its affiliation to ``owner``.
|
||||
|
||||
Sets the participant’s role to `moderator` and its affiliation to `owner`.
|
||||
``+a``
|
||||
Sets the participant’s role to ``moderator`` and its affiliation to ``owner``.
|
||||
|
||||
`+a`
|
||||
``+o``
|
||||
Sets the participant’s role to ``moderator`` and its affiliation to ``admin``.
|
||||
|
||||
Sets the participant’s role to `moderator` and its affiliation to `owner`.
|
||||
``+h``
|
||||
Sets the participant’s role to ``moderator`` and its affiliation to ``member``.
|
||||
|
||||
`+o`
|
||||
|
||||
Sets the participant’s role to `moderator` and its affiliation to `admin`.
|
||||
|
||||
`+h`
|
||||
|
||||
Sets the participant’s role to `moderator` and its affiliation to `member`.
|
||||
|
||||
`+v`
|
||||
|
||||
Sets the participant’s role to `participant` and its affiliation to `member`.
|
||||
``+v``
|
||||
Sets the participant’s role to `participant` and its affiliation to ``member``.
|
||||
|
||||
Similarly, when a biboumi user changes some participant's affiliation or role, biboumi translates that in an IRC mode change.
|
||||
|
||||
Affiliation set to `none`
|
||||
|
||||
Affiliation set to ``none``
|
||||
Sets mode to -vhoaq
|
||||
|
||||
Affiliation set to `member`
|
||||
|
||||
Affiliation set to ``member``
|
||||
Sets mode to +v-hoaq
|
||||
|
||||
Role set to `moderator`
|
||||
|
||||
Role set to ``moderator``
|
||||
Sets mode to +h-oaq
|
||||
|
||||
Affiliation set to `admin`
|
||||
|
||||
Affiliation set to ``admin``
|
||||
Sets mode to +o-aq
|
||||
|
||||
Affiliation set to `owner`
|
||||
|
||||
Affiliation set to ``owner``
|
||||
Sets mode to +a-q
|
||||
|
||||
### Ad-hoc commands
|
||||
Ad-hoc commands
|
||||
---------------
|
||||
|
||||
Biboumi supports a few ad-hoc commands, as described in the XEP 0050.
|
||||
Different ad-hoc commands are available for each JID type.
|
||||
|
||||
#### On the gateway itself (e.g on the JID biboumi.example.com):
|
||||
On the gateway itself (e.g on the JID biboumi.example.com):
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- ping: Just respond “pong”
|
||||
|
||||
@@ -424,12 +445,14 @@ Different ad-hoc commands are available for each JID type.
|
||||
with an XMPP message. The administrator can disconnect any user, while
|
||||
the other users can only disconnect themselves.
|
||||
|
||||
#### On a server JID (e.g on the JID chat.freenode.org@biboumi.example.com)
|
||||
On a server JID (e.g on the JID chat.freenode.org@biboumi.example.com)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- Configure: Lets each user configure some options that applies to the
|
||||
concerned IRC server.
|
||||
|
||||
#### On a channel JID (e.g on the JID #test%chat.freenode.org@biboumi.example.com)
|
||||
On a channel JID (e.g on the JID #test%chat.freenode.org@biboumi.example.com)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- Configure: Lets each user configure some options that applies to the
|
||||
concerned IRC channel. Some of these options, if not configured for a
|
||||
@@ -438,7 +461,8 @@ Different ad-hoc commands are available for each JID type.
|
||||
and the server. If an encoding is not specified for a channel, the
|
||||
encoding configured in the server applies.
|
||||
|
||||
### Raw IRC messages
|
||||
Raw IRC messages
|
||||
----------------
|
||||
|
||||
Biboumi tries to support as many IRC features as possible, but doesn’t
|
||||
handle everything yet (or ever). In order to let the user send any
|
||||
@@ -452,8 +476,8 @@ The message will be forwarded as is, without any modification appart from
|
||||
adding "\r\n" at the end (to make it a valid IRC message). You need to have
|
||||
a little bit of understanding of the IRC protocol to use this feature.
|
||||
|
||||
SECURITY
|
||||
--------
|
||||
Security
|
||||
========
|
||||
|
||||
The connection to the XMPP server can only be made on localhost. The
|
||||
XMPP server is not supposed to accept non-local connections from components.
|
||||
@@ -481,13 +505,3 @@ protection against flood or any sort of abuse that your users may cause on
|
||||
the IRC servers. Some XMPP server however offer the possibility to restrict
|
||||
what JID can access a gateway. Use that feature if you wish to grant access
|
||||
to your biboumi instance only to a list of trusted users.
|
||||
|
||||
AUTHORS
|
||||
-------
|
||||
|
||||
This software and man page are both written by Florent Le Coz.
|
||||
|
||||
LICENSE
|
||||
-------
|
||||
|
||||
Biboumi is released under the zlib license.
|
||||
Reference in New Issue
Block a user