-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CHATHISTORY: consider adding a target to retrieve highlights #438
Comments
Don't think this is particularly workable, or at least no where near as trivial as suggested. Highlights aren't just nick mentions, there's no command to tell a server what highlight patterns the user cares about, and clients all have different functionality when it comes to which patterns work etc. |
It feels like at some point we should look at some way to search chat history and get matching messages from the server. Could clients build this sort of functionality on top of such a feature? For prior work on communicating mentions and that kinda thing, see this bit from palaver's push notification spec. |
I don't think this is a show-stopper. We can leave highlights implementation-specific, and it would cover 99% of cases. Servers may have other channels to exactly define what a "highlight" is, like palaver has. Clients that really want to do some custom filtering can just fallback to the current status quo: retrieve all history and be slow.
Maybe. I guess if there's a substring search operation, clients could always locally filter the messages they get to narrow it down to highlights. Although search can get out of hand pretty quickly. See e.g. IMAP for a pretty complicated search query format. |
I mean maybe standardising a way to tell the server and manage what highlight words you care about would be a good start, and would benefit any future push notification spec that's been mooted quite often. |
Maybe it's a good idea, but I'm personally not interested in that, and I don't think it's a requirement for specifications that allow querying highlights. In other words, I don't want to implement a standard way to manage highlight words in my bouncer, but still want to allow CHATHISTORY clients to not be slow when connecting. |
Just a rough proposal: as a stopgap until we figure out a more general solution for highlights, you could try doing this as a vendor extension, using a "nickname" that is invalid as an actual IRC nickname (similar to what ZNC does). For example, the highlights target could be |
I would love to see full-text search in IRC but technologically speaking, it's harder than mention tracking. We already have the tools in Oragono to do mention tracking efficiently, we just don't have the spec to control it. |
Yes, I was definitely planning on having a vendored extension for this feature. |
Currently, when connecting clients need to query history for all channels, from the last read msgid. This is necessary to show visual feedback (colors, notifications) in case the user has been highlighted while being disconnected.
This results in potentially lots of resources lost (ie. time lost for the user), especially if the user has joined many high-traffic, low-highlight channels. For instance, using gamja + soju and after being away for a week, it can take dozens of seconds to catch up.
All of this could be avoided if there were a special target (e.g.
*highlight
) to query all highlights since the previous connection. The server would be in charge of filtering the highlights and only send what the client is interested in. This could be cheap if the server has a "bool is_highlight" field in its message database.The text was updated successfully, but these errors were encountered: