IRC bouncer
Nevar pievienot vairāk kā 25 tēmas Tēmai ir jāsākas ar burtu vai ciparu, tā var saturēt domu zīmes ('-') un var būt līdz 35 simboliem gara.
Causal Agent db3433432b
Refactor filterUserhostInNames
pirms 1 stundas
rc.d Set up /var/run/calico and /usr/local/etc/pounce pirms 1 nedēļas
.gitignore Revert "Test getopt_config" pirms 1 dienas
Darwin.mk Assume LibreSSL from brew on Darwin pirms 1 nedēļas
LICENSE Change license to GPLv3 pirms 1 nedēļas
Linux.mk Use -l:filename in Linux.mk pirms 6 dienas
Makefile Revert "Test getopt_config" pirms 1 dienas
README.7 Add capsicum note to README pirms 2 dienas
bounce.c Rename listen to local pirms 3 dienas
bounce.h Filter userhost-in-names pirms 2 dienas
calico.1 Document calico service configuration pirms 6 dienas
client.c Refactor filterUserhostInNames pirms 1 stundas
compat.h Fix compat.h for #defined strlcpy pirms 6 dienas
config.c Revert "Test getopt_config" pirms 1 dienas
dispatch.c Declare more missing functions and deal with lack of SO_NOSIGPIPE pirms 1 nedēļas
local.c Rename listen to local pirms 3 dienas
pounce.1 Add userhost-in-names to manual pirms 2 dienas
ring.c Change license to GPLv3 pirms 1 nedēļas
server.c Change license to GPLv3 pirms 1 nedēļas
state.c Filter invite-notify pirms 2 dienas

README.7

README(7)          FreeBSD Miscellaneous Information Manual          README(7)

NAME
     pounce – IRC pouncer :3

DESCRIPTION
     pounce is a multi-client, TLS-only IRC bouncer.  It takes a simple
     approach, using a multiple-consumer ring buffer and the IRCv3.2
     server-time extension to communicate with clients.

     pounce requires LibreSSL (-ltls) and targets FreeBSD.  It can also be
     built on Darwin or GNU/Linux by copying the appropriate file to config.mk
     and modifying as needed.  On FreeBSD, processes are sandboxed with
     capsicum(4).  On other systems, who knows what might happen?

RATIONALE
     As a former znc(1) user, I was dissatisfied with the multi-client
     experience it offered.  I wanted to connect from both my laptop and my
     phone and have full chat history on both.  With znc(1), my options were
     either having both clients spammed with redundant history every time they
     connect, or having one client consume the buffer and the other get no
     history at all.

     With a multiple-consumer ring buffer, each client has its own place in
     the history and can be brought up to date independently.  Additionally,
     by expecting clients to implement the server-time extension, all events
     can be accurately replayed, rather than being limited to messages.

FILES
     bounce.h    declarations and common functions
     bounce.c    configuration and event loop
     local.c     local server binding
     server.c    remote server connection
     client.c    remote client connections
     state.c     state shared between clients
     ring.c      buffer between server and clients
     config.c    getopt_long(3)-integrated configuration parsing
     dispatch.c  SNI socket dispatch
     compat.h    compatibility with lesser operating systems
     rc.d/       FreeBSD rc(8) scripts

SEE ALSO
     calico(1), pounce(1)

Causal Agency                  November 10, 2019                 Causal Agency