Quassel is awesome, and has a really interesting idea in wanting to store logs in an sqlite db for better searching, but ironically in the current client implementation this seems to make it harder to search for stuff.
While searching for things in the immediately loaded buffer is easy (CTRL+F), searching for things said a long time ago can't be searched via the client. You either have to use command line tools to dump the sqlite db into a grepable text file or install the quasselsuche web app (last updated in 2012).
Once better long term search has been implemented in the client, quassel will become the best GUI IRC client hands down, I look forward to seeing the progress made in this area.
If I remember correctly, it has massive SQL-injection holes and isn't maintained anymore. The issues are known (quassels website etc warn people against using quasselsuche).
> While searching for things in the immediately loaded buffer is easy (CTRL+F), searching for things said a long time ago can't be searched via the client. You either have to use command line tools to dump the sqlite db into a grepable text file or install the quasselsuche web app (last updated in 2012).
Why not just open the sqlite file and search in there? Could even ask for the log to be stored in an FTS table for fast FTS queries.
That may work, but then you're in the same workflow as the more traditional IRC clients with their .txt logfiles and needing tools external to the IRC client. Ostensibly the point of moving away from the human-readable logfiles to something like an SQL DB was to let the client be a more powerful search engine into your chat history. So this is mostly a lament that while there's a great vision to what an IRC client can be in designing Quassel's infrastructure, Quassel has not yet fully realized its vision in this area, but I'm sure it'll get there some day.
I think the OP's original complaint is bore out of the idea that: if the client is already storing the logs in a structured format with a schema to accompany it, and the data engine has query features for that data which is powerful like grep (as SQL does), and it's already using that engine to power search for the immediate buffer - it seems a bit odd then to not build 'global' search right into the application, for all logs, based on the same mechanism.
I think it's nice you can do all the SQL dumping/munging stuff, given the implementation. I just don't want that in 99% of all use cases - the application doing search itself is enough normally. It's not like I use any of grep's more powerful features when I search logs, 99% of the time it's just something like "| grep foo" and I narrow it down iteratively or just pick out the result.
Honestly, technical specifics aside, this is also a matter of usability, and is something Slack gets very right: you never have to do anything for search to work well for the vast majority of use cases, even for very long histories. You just type the words you want and the results always come back, even from weeks or months before. Telling users to enable logs and then search text files is just much more activation energy. Telling them to do that after exporting their data from SQLite, even more so.
I'm using it with postgres, and yeah I don't know why there's no option to search all historical logs (well I guess if I really wanted it, it is an open source project), but since I have desktop client opened all the time, in settings I have it configured to fetch some ridiculous amount of backlog, and then ctrl-f searches quite far in the past.
Have you had a look at WeeChat + Glowing Bear? The idea is to keep WeeChat running permanently on a server (screen/tmux) and to connect to it from a browser (desktop or mobile). All the logs and highlights will be there, and read status is synced. No cloud, communication is direct between browser and WeeChat via websockets.
Disclosure: I am a maintainer of Glowing Bear. Join us in #glowing-bear if you have questions :)
Judging by the screenshots it does look quite similar, nice. Do you know whether it works well on mobile? That's one of the main selling points for many users. The tmux+ssh user experience is not that great on mobile :)
Well, for quassel, there's also a mobile app. On the Play Store the beta version is quite neat, and the F-Droid version. The normal Play Store version is from 2013, though.
I - maintainer of QuasselDroid - am currently working on a next version, though, which will take another few months.
For iOS, though, quassel-webserver is the best you'll be able to get, and it's quite meh on mobile.
I also use weechat (on cygwin since they don't have native windows builds) + glowing bear. It's great as long as you're at a PC, but it's missing a way to get notifications (for example when you receive a /msg or /notice) when you're away from the PC but have your mobile with you.
Yeah, that's hard to implement without a central server component or annoying setup. I use IrssiNotifier (despite the name, it also works with WeeChat). It's not great but I get push notifications for highlights on my phone.
Well irssinotifier uses Google cloud messaging (is that the current name? The Google push service). It encrypts messages on the server and decrypts them in the client, using a passphrase. It's a technically neat solution but a bit annoying to set up.
It has a script for weechat (and of course irssi), not sure about other clients.
Or you can use pushbullet /..., there should be scripts for any popular scriptable client
The only problem about it for me, is that having search and offline messages is not possible by default. I'm using IRC for the #redis community channel, and joining a discussion after my laptop has been in my bag for a couple of hours is not really feasible.
To my understanding you can setup Quassel as a bouncer on a server, so when you reconnect it will update all you missed, you just need a cheap VPS or another desktop to connect through elsewhere. Some channels also have searchable logs via bots as well. Ironically BotBot.ME which is powered by redis doesn't have a bot at #redis but oh well...
can you please elaborate more? I am looking to setup something similar. I have minimal linux knowledge and I have done a basic setup of weechat+screen.
This seems to do same thing as tmux+weechat on server and weechat/weechat-android/glowing bear as client but graphical.
If you want try tmux+weechat combo but don't have/want to setup a VPS, create an account at hashbang.sh. It's a free shell service and we drop new users in weechat instance running tmux.
The main difference is that quassel puts logs in sqlite/postgres. The database makes the entirety of your logs easily searchable. The Gui lacks a great search tool, but I just use a few python scripts.
Basically, the same features as The Lounge, but it just connects to a Quassel core, allowing you to connect to the same core with the desktop app or with the Android app, and allowing you to use the ecosystem of software developed around Quassel.
Does this allow for me to be "always on"? The reason I moved from IRC to Slack is exactly this. If there was a way for me to use many different peers to keep my connections alive even when I'm offline, that would make want to use IRC again.
Otherwise I just don't have time/energy/money to get a server just to host my IRC session.
You are looking for a BNC[1]. Quassel is a superset of the features you could expect in one.
I think that there is a lot of people in your situation. They don't know about the existence of this tools or think their setup is hard or time consuming and ends using Slack.
When I first looked for something to let me be "always on" I ran into the same advice you're giving. It didn't help me at all. Most people looking for the answer to "how can I have always-on IRC with a backlog" don't want to learn about what a BNC is or the pros and cons of the various BNC solutions out there, they want something actionable.
I ended up installing Quassel with a docker image and downloading a Quassel client for my laptop and smartphone. I hear it's possible to connect to Quassel (and other bouncers?) with regular IRC clients, too, but I can't be arsed to figure out how.
> When I first looked for something to let me be "always on" I ran into the same advice you're giving. It didn't help me at all. Most people looking for the answer to "how can I have always-on IRC with a backlog" don't want to learn about what a BNC is or the pros and cons of the various BNC solutions out there, they want something actionable.
This is a really strange comment. If the question is "How do I get always-on IRC" then the answer is "Use a bouncer". Following up with "People don't want to learn about a bouncer" is the same thing as "People don't really want the answer". I'm confused.
How is "Install ZNC" (as an example of a bouncer) not "actionable"?
The double-edged sword of bouncers is that they try to strap the behavior we're looking for on top of IRC which forces them to do it in a convoluted way.
Connecting to multiple networks with a bouncer has always felt like a kludgey disaster to me because of this. I don't want to have to define another connection from each of my actual clients to my bouncer to add another network, I just want to add another network. When I get a new system or reinstall an old one I don't want to have to set up a half dozen connections.
Quassel gets this right and keeps things separated. All IRC network settings exist at the server (bouncer) only, the client needs nothing more than a username and a password for the server and gets everything else from there.
Installing a bouncer means following technical documentation and having a server free. The first requirement kills the interest of people who want a single app install. The second kills the interest of people who want the service free and run by a third party.
These are not enormous barriers but they were enough to put me off of setting up Quassel on a VPS for a few years. Now that I've done it I don't want to go back, of course, and I don't see it as a huge chore to do it again. But that's what's making it "not actionable" - the perception that this is going to end in a nightmare of configuration files and Stack Overflow searches.
That's part of the reason why "Quassel as a service" would be a very powerful tool.
Currently, though, we have to tell users who want that to use IRCCloud instead - about half of the people come back after the first week of free usage of IRCCloud when it asks you to pay, and start using Quassel from then on.
Weechat, the terminal based client, also supports a protocol like this. There aren't really any nice graphical clients for it, but there is a mobile one which is very usable, and there's an HTML5-y one, but I haven't tried that.
If you like irssi, but wish you had a better way to use it on mobile, you might like Weechat - that's how I use it currently, terminal over SSH on desktops, mobile client over the relay protocol on the go.
Speaking of IRC clients, I don't understand why one particular feature that has been requested all time (feature request in various clients I've gone through) but never implemented - keyword highlight and notification, but customizable depending on the channel. This way you don't have to pay visual attention to certain channels.
And I thought the need is common enough and it's easy enough to implement..
This is definitely possible in Quassel - Each highlight rule has a regex for the message, and a regex for the channel. Only if both match, it will highlight.
This means you can get highlights on every message in channel #support, or highlights on "quassel" in every channel.
Perfect, then I'd definitely switch from LimeChat. I thought it wasn't possible because of this http://bugs.quassel-irc.org/issues/1348 , and saw no mention of it in the doc.
I guess it's just a request for blacklist instead.
I never faced this need and is the first time I saw it stated.
If it appeared in various clients and got implemented in none then it should be a reason. Examples:
- It is not a need for enough people
- No developer suffers your problem (you can always try to do the PR by yourself)
This feature requests got ignored or received some reply by devs? I am curious.
e.g. https://github.com/psychs/limechat/issues/31
I remember I spent quite a bit of fruitless time searching for a reasonably good looking and well maintained one having such feature on OSX.
I've used Quassel for a few years now, it's great. Your always only, history is preserved and shown on all devices - no matter how long they've been disconnected for.
Unlike most BNCs, this also makes sure all the timestamps are correct when data is replayed..it also doesn't notify you for mentions if you've already been notified about the message. 10x more useable than any other BNC I've used.
I evaluated this along with some other clients fairly recently (4-5 months ago). I really liked it except for an issue where it appeared (from my end) that I was online but I was actually disconnected. I missed a couple of days of discussion and my messages ended up in a void. I dunno if it didn't like my ZNC bouncer, but I considered it a showstopper nonetheless.
So many clients, so much effort spent... I wish the shared functionality could be encapsulated and used within other clients (some of which arguably far more flexible and thus usable), like pidgin (which is my favorite) and irssi...
Very interesting. Right now I'm using a znc bounce to allow all my clients to stay connected. For clients I use either weechat, Textual from macOS, or Mutter from iOS. All clients work seamlessly. Same nicks, channels, and logs from any device.
Quassel is nice and I'd recommend it, even when I stopped using it for a year and moved to AdiIRC (mainly because I found the customization on AdiIRC is more fun to play with)
Sadly, the current iOS client hasn’t been supported in quite a while.
But there are 2 independent projects that allow sending notifications via Pushbullet or GCM to your phone if you get a highlight via quassel, quassel-pushbullet and quassel-irssi-notifier.
While searching for things in the immediately loaded buffer is easy (CTRL+F), searching for things said a long time ago can't be searched via the client. You either have to use command line tools to dump the sqlite db into a grepable text file or install the quasselsuche web app (last updated in 2012).
Once better long term search has been implemented in the client, quassel will become the best GUI IRC client hands down, I look forward to seeing the progress made in this area.