Echelog is Shutting Down!

I would completely and wholeheartedly support moving to matrix if we had a stable / native matrix client in our software repositories.

Until that day comes, i’ll be aginst it.

@X512, you should write a native matrix client. We already have libmatrix_client and libmatrix_client_devel in our repos :slight_smile:

Matrix is kinda slow and clunky from my experiences… but my original goto (Keybase) is dead in the water so i’m looking for alternatives.

You forgot Witchhunts and The War on Christmas…

Seriously, if people are afraid the Haiku Community will turn on them, they may want to avoid being off-topic in #haiku and the forums. There are plenty of places on the web to be politically provocative. Let’s keep all that out of our forums/IRC.

4 Likes

mtxclient depends on boost, until that dep can be lifted (which mainly would require building a Bhttp backend for the lib, and rebuild some definitions) I don’t think that is a good idea.
(I asked red sky about this and it’s probably possible to do, but it depends on boost internal type definitions currently)

Matrix is kinda clunky indeed, but it works “okay”
I am still against using it for anything serious aslong as the media repository is still unauthenticated, it basically behaves like an open ftp relay which is something we don’t really want imo.
(basically user A uploads media tp server B and then /anyone/ can request the media from us and the server will mirror it)

We also already have a native client for XMPP that PulkoMandy is working on, which to ne seems like a better solution to our problems.
(though that depends on gplv3 gloox… cant have everything i suppose)

I have been working on a native XMPP client, which is almost working well enough to replace Vision (I need to add nickname notifications and activity indicators in the channel list). I use it with an IRC gateway for now to connect to existing Haiku channels.

Personally I would prefer that to Matrix, because I already use XMPP for various other things.

3 Likes

This should not ever happen. Important details should be in commit messages, source code, and internal documentation. I cannot remember ever solving some problem because of some important detail found only on IRC and nowhere else (on the other hand, I have asked people on IRC for help and they have often pointed me to the right place.)

I’m not concerned about the Haiku community, I’m concerned about the webmob going after everyone, for nothing.

just stop logging chat

Hi,
i have a lot of things.
Why we need a replace for vision. This software is good, is there a license problem? The problem with the >>webmob<< can’t be solved, but the logging of the echelog is important.
If a ask something in the irc, sometimes i get no answer in one hour and in the next day i’m looking in the echelog i found the answer.

The problem is not with Vision itself, but with the IRC protocol.

For example:

  • IRC require a stable internet connection so it doesn’t work very well on mobile phones
  • The only way to access the logs is in a separate website. It would be better to have them directly inside the application
  • IRC is sometimes targetted by spammers and other attacks (a real problem, compared to the mostly imaginary “webmob”, I can’t imagine people would find and read our IRC logs to find someone to attack when they are not otherwise involved in Haiku?), and due to the way IRC works, it is difficult to control these
  • Some “advanced” usage is a bit complicated (for example, registering your nickname and setting a password)

Of all these, the main problem is clearly “requires a stable connection”. In my case it is a problem because often I’m using Vision inside Haiku and maybe I’m rebooting my computer a lot (to test some Haiku things). As a result I would miss most of the discussion going on while I’m rebooting. With a more modern protocol, the missed messages could be sent when I reconnect.

I know other people (including several past GSoC students) have also mentionned that this is a problem for them. As a result (probably not only of this, but at least partially), they tend to not get very involved in the community and they move on to other things.

That being said, if we decide to move the channel to somewhere else, we will surely consider setting up some kind of bridge so that people who really want to stay on IRC can still reach us (like there is one between IRC and BeShare already)

Hi PulkoMandy,

Thanks for the explanation. All points i understand and fully agree. Especially the 2 point is also my main problem.

I agree about all the issues with IRC. Some of the modern web-based chats really have a lot of nice features but I cannot stand the bloat required to run most of them. So if there is some middle ground Haiku can move toward that sounds great.

Does the end goal for using XMPP chat require a server run by the Haiku project? That’s fine, I am just curious.

For easy solution. Why not embed the echolog output in Vision? Or put a link to the log files in Vision? What is so difficult in open the log files in a browser window?

Not necessarily, we could use an existing server as well. Some servers offer a way to use our own DNS with their infrastructure so our channels could have addresses ending in @chat.haiku-os.org and we could still have someone else taking care of the hosting (ideally we would give them a small amount of money in return, I guess? or hope they find a sponsor, as Freenode does for IRC)

It is not difficult if you know it. But imagine you never used IRC before and you want to join the Haiku chat. If you just connect and there is no context, you just get an empty window saying “you have joined #haiku”. If you don’t say hi or something like that, it looks like nothing is happening.

On the other hand, imagine that when you connect, you get about one page of the recent discussions directly in your client. Now, you immediately can see if the channel is active or not, and what kind of things people are talking about. So it becomes clearer how the channel operates and what is going on.

This is a small difference, but I think it has big consequences for people joining for the first time. And it will help them stay around.

2 Likes

It’s not really a hard requirement. I really liked XMPP given how light and flexible it was. With that said, I feel like XMPP is kind of dying (sorry @PulkoMandy :slight_smile: ) . I really don’t know many folks left on it. (back in the 2005-2010 days it was popular because of the AIM/Yahoo bridges)

Honestly, I’m not sure why XMPP feels dead. Maybe lack of unified model for message encryption?

Google trends seem to agree:
https://trends.google.com/trends/explore?date=all&q=XMPP

Trying to compare a bunch of common solutions:
https://trends.google.com/trends/explore?date=all&q=XMPP%20Chat,Telegram%20Chat,IRC%20Chat,Matrix%20Chat,Signal%20Chat

By this metric, Haiku is probably more “dead” than xmpp. I don’t really care. Let’s focus on what fit our needs, in particular, availability of a client for Haiku or possibility to write one. I’m doing the xmpp client because I happen to need it for other things. For Haiku I guess I’d be fine with other protocols if needed.

End-to-end encryption in xmpp is possible with omemo (we don’t really need it for the haiku channels however?)

The lack of success of xmpp is most likely because of the very fragmented ecosystem (there are many clients and servers to pick from). As a result no one is going to advertise for xmpp as a whole, and each client is quite small. This is dnfferent for exemple with Matrix, which has one main client and are doing a lot more marketing

2 Likes