This adds a -B CLI flag and a 'nobatch' configuration option,
which prevents IRC events which have the IRCv3 'batch' tag from
being stored in litterbox's database. If 'nobatch'/-B is given,
litterbox will also request the 'batch' capability from the
server.
---
litterbox.1 | 4 ++++
litterbox.c | 8 +++++++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/litterbox.1 b/litterbox.1
index b66d609..bee6e65 100644
--- a/litterbox.1
+++ b/litterbox.1
@@ -21,6 +21,7 @@
.Op Fl p Ar port
.Op Fl u Ar user
.Op Fl w Ar pass
+.Op Fl B
.Op Ar config ...
.
.Nm
@@ -180,6 +181,9 @@ The default limit is 10.
Migrate the database to the latest format
and exit.
.
+.It Fl B
+Do not log batch IRC events.
+.
.It Fl n Ar nick , Cm nick = Ar nick
Set the nickname to
.Ar nick .
diff --git a/litterbox.c b/litterbox.c
index 5a88132..7a09bef 100644
--- a/litterbox.c
+++ b/litterbox.c
@@ -69,6 +69,7 @@ enum { ParamCap = 254 };
struct Message {
size_t pos;
char *time;
+ bool batch;
char *nick;
char *user;
char *host;
@@ -88,6 +89,7 @@ static struct Message parse(char *line) {
if (!strcmp(key, "causal.agency/pos")) {
msg.pos = strtoull(tag, NULL, 10);
}
+ msg.batch = !strcmp(key, "batch");
}
}
if (line[0] == ':') {
@@ -757,6 +759,7 @@ int main(int argc, char *argv[]) {
const char *nick = "litterbox";
const char *user = NULL;
const char *pass = NULL;
+ bool nobatch = false;
struct option options[] = {
{ .val = '!', .name = "insecure", no_argument },
@@ -772,6 +775,7 @@ int main(int argc, char *argv[]) {
{ .val = 'k', .name = "priv", required_argument },
{ .val = 'l', .name = "limit", required_argument },
{ .val = 'm', .name = "migrate", no_argument },
+ { .val = 'B', .name = "nobatch", no_argument },
{ .val = 'n', .name = "nick", required_argument },
{ .val = 'p', .name = "port", required_argument },
{ .val = 'q', .name = "private-query", no_argument },
@@ -801,6 +805,7 @@ int main(int argc, char *argv[]) {
break; case 'k': priv = optarg;
break; case 'l': searchLimit = strtol(optarg, NULL, 0);
break; case 'm': migrate = true;
+ break; case 'B': nobatch = true;
break; case 'n': nick = optarg;
break; case 'p': port = optarg;
break; case 'q': searchQuery = Private;
@@ -899,6 +904,7 @@ int main(int argc, char *argv[]) {
if (pass) format("PASS :%s\r\n", pass);
if (cert) format("CAP REQ :sasl\r\n");
+ if (nobatch) format("CAP REQ :batch\r\n");
format("CAP REQ :server-time\r\n");
format("CAP REQ :causal.agency/passive\r\n");
if (consumerPos) {
@@ -927,7 +933,7 @@ int main(int argc, char *argv[]) {
if (!crlf) break;
crlf[0] = '\0';
struct Message msg = parse(line);
- handle(&msg);
+ if (!nobatch || (nobatch && !msg.batch)) handle(&msg);
line = crlf + 2;
}
len -= line - buf;
--
2.25.1
> On Nov 13, 2020, at 12:11, Kiëd Llaentenn <kiedtl@tilde.team> wrote:
>
> This adds a -B CLI flag and a 'nobatch' configuration option,
> which prevents IRC events which have the IRCv3 'batch' tag from
> being stored in litterbox's database. If 'nobatch'/-B is given,
> litterbox will also request the 'batch' capability from the
> server.
The intention here is to filter messages in chathistory batches to
avoid duplicates from rejoining a channel with +H set, but filtering
all batch messages would also drop netsplit/netjoin QUITs and JOINs,
which seems undesirable.
Unfortunately tracking batch types would require quite a bit more
work… I’ll lay out how I would approach it in case you’re interested
in implementing that, otherwise I think I will get around to it at
some point. Batches could be tracked in a temporary SQLite table
similar to the joins table used to track the users in channels. A
handler for the BATCH command would insert and delete rows in the
table, and the PRIVMSG/NOTICE handler could check if the batch is
the chathistory type.
I guess the actual best thing to do would be to attempt deduplication
on batch messages, but I’m not sure how that would be done properly
in a transaction with SQLite...
On Tue Nov 17, 2020 at 3:09 AM UTC, June Bug wrote:
>
> The intention here is to filter messages in chathistory batches to
> avoid duplicates from rejoining a channel with +H set, but filtering
> all batch messages would also drop netsplit/netjoin QUITs and JOINs,
> which seems undesirable.
Oh. I hadn't thought about that.
Actually, in my specific case, I would actually want that. But I can see
why it's most likely an unwanted feature for everyone else.
> Unfortunately tracking batch types would require quite a bit more
> work… I’ll lay out how I would approach it in case you’re interested
> in implementing that, otherwise I think I will get around to it at
> some point.
Um, no. I'm afraid I don't have enough time (or motivation) to
implement that (not right now, anyway).
> I guess the actual best thing to do would be to attempt deduplication
> on batch messages, but I’m not sure how that would be done properly
> in a transaction with SQLite...
I looked into doing that, and I have had a fair amount of success by
using unscoop's -D flag. I don't think it was intended for that, but
hey, it works.
---
kiedtl
"This, too, shall pass."