Quassel IRC

h1. GSoC 2016

h2. Core

h3. Log search

There needs to be a core-side thingy to search logs so that clients dont have to write all the db code from scratch

h3. Highlights

* #1122 Reworking of the code for notifications, highlights and ignores (implement on the back end)

* #1121 Track highlights (Away log) server-side

* #989 Add ignore highlight option in a channel's context menu

* #734 Retrieve unread highlights on attach | Non-linear backlog

h4. Highlight rules

(store highlights server side)

QuasselNotify

 * By default, is on "core port + 1"

 * Only available if core has SSL Certificate

 * (This could also alternatively be on the same port as the core, but with protocol 0x03, in case quassel ever implements it natively; In the case of a native implementation, the GetRule/AddRule/DelRule would be issued through the normal Quassel protocol)

 * Messages are described by protobuf

 * Messages are distributed using MQTT

The following spec further discusses types of messages that can be delivered between clients. They will be sent with QoS 1 (at least once delivery).

Each rule belongs to a topic, and a client can decide to subscribe to multiple topics.

For example, one could create a rule for all "help" "please" messages in freenode#quassel, and declare this to be part of the group "work", while rules in other channels, say, #disney, could be part of the group "fun".

During work hours, the client could decide to only subscribe to the topic "work", while during other hours, it would only subscribe to the topic "fun".

Types

 * MessageID: int

 * UUID?

 * Topic: String

 * BufferInfo: { int: id | int: networkid | int: type | int: groupid | String: name  }

 * Message: { MessageID: id |  int: time | int: type | int: flags | BufferInfo : buffer| String: sendermask | String: content }

 * SmartRegex: { String: regex | boolean: inv }

 * HighlightRule: { UUID : id | Topic : topic | SmartRegex : message | SmartRegex : sender | SmartRegex : channel | boolean : inverted }

Client -> Server

 * RequestRules{ }

 * AddRule{ HighlightRule  : rule }

 * DelRule{ UUID : id }

 * RemoveNotification{ UUID : id } (if notification is swiped away)

Server -> Client

 * Notification{ Message : message }

 * ListRules{ Array[HighlightRule]: rules}

 * RemoveNotification{ MessageID : id } (if last read progresses, for example, or it’s read on other clients)

(obviously, mqtt handles pub/sub)

Specification of what "a message is a highlight" for a topic:

All of the following apply:

 # The message maches one or more highlight rules with inverted == false

 # The message matches zero highlight rules with inverted == true

Pseudocode:

<pre>

boolean Topic::matches(Message m) {

    for (HighlightRule rule: invertedRules) {

        if (rule.matches(m)) return false;

    }

    for (HighlightRule rule: normalRules) {

        if (rule.matches(m)) return true;

    }

    return false;

}

</pre>

Specification of "a message matches a highlight rule":

All of the following apply:

 # The rule’s message regex matches the messages message content

 # The rule’s sender regex matches the messages nick!ident@host

 # The rule’s channel regex matches the messages network#channel

Pseudocode:

<pre>

boolean HighlightRule::matches(Message m) {

    return message.matches(m.content) && sender.matches(m.sender) && channel.matches(m.buffer.network + "#" + m.buffer.name);

}

</pre>

Specification of "a SmartRegex matches on a String":

 * If inv is false, then the smartregex matches exactly when its wrapped regex would match

 * If inv is true, then the smartregex matches exactly when its wrapped regex would not match

Pseudocode:

<pre>

boolean SmartRegex::matches(String s) {

    return inv ^ regex.matches(s));

}

</pre>

h3. Backlog management

* #734 Retrieve unread highlights on attach | Non-linear backlog

   * #1330 server-side log search in core

   * «If the core would have such an API, it would be amazing... Especially for stuff like quasseldroid and so... Message filtering would be nice in general. "Give me all unread messages containing my nickname". Would be amazingly useful for notifications.»

* #1252 separate log and backlog tables

* #1083 Archive search

* #1327 The search box should search the complete log

* #716 Alternate Backlog Retrieval System - Timelines

* #1204 Have an option to keep a buffer log, but not keep it in the channels tree

* #1316 Quassel freezes when I switch to a buffer with large backlog

h3. Scripting

Scripting at the core side.

Currently implemented without hooks as a one-off command. [https://github.com/quassel/quassel/tree/master/data/scripts existing scripts], ? code where they are processed ?.

Needs to support scripting at the core side with hooks, "when someone joins do X", etc.

* [[Possiable Scripting Object]]

* #265 Plug-In/Script support

* "Task machinery":https://github.com/seezer/quassel/commit/8e4c1d8c20b04bd1b2e7a98ab3ad2899e5735724 (from seezer, needs feedback before using this to build event driven scripting thing)

h2. Clients

Improve any of the [[Mobile]] clients

h3. Web client

Improve Quassel-web for a "cloud" experience?

* https://github.com/sandsmark/quassel-web - sandsmark

* https://github.com/magne4000/quassel-webserver - magne4000