Re: [dev] an approach to Matrix client that sucks less
tox didn't die it's alive and well On Thu, 20 Feb 2020 20:54:42 +0100 Laslo Hunhold wrote: > On Thu, 20 Feb 2020 11:44:19 -0500 > "Greg Reagle" wrote: > > Dear Greg, > > > Hi y'all. I don't see any Matrix client at > > https://suckless.org/rocks/ or https://suckless.org/other_projects/ > > and I am thinking of making one. I use the Riot.im web app client > > which has a lot of features, but is bloated. > > > > Do any of you know of a Matrix client that is not bloated? I have > > looked at many of the clients at https://matrix.org/clients. I have > > tried several. Some of them are either too bloated, use a language > > I'm not crazy about, or lack some basic features (too immature). > > > > I have never used Weechat and am feeling too lazy to learn. I > > expect there would be a lot to learn just to use it as an IRC > > client, then as a Matrix client I don't know how well it works. I > > am reluctant to invest the time and effort (but maybe I should, I > > don't know). > > > > I might write my own Matrix client. I would probably use Lua. C is > > too low level for my taste. Would any of you be interested in > > contributing? I expect I would start by writing command line > > interface. CLI would be good to have, and I could learn a lot about > > implementing Matrix without being bothered by UI issues. After the > > CLI was done, then I would consider what to do next, maybe a GUI, > > maybe a TUI, etc. > > yes, we haven't looked into Matrix much here. I have to admit that > it's the most promising protocol out there, in my opinion. What > matters for a suckless client is the interface. A few years ago, > Dimitris, Hiltjo, I and a few others wrote a client for toxcore, and > we kept it similar to ii with a file based hierarchy. The client > itself was event-driven and had a pretty sophisticated state machine > to handle the different states. We even supported calls and file > transfers, but sadly, tox died due to internal conflicts and an > inconsistent API. > > Investigating Matrix is definitely a nice thing! I am not a big fan of > Lua though, but what matters is the interface. From that point on, it > shouldn't matter which language you use to implement it. > > With best regards > > Laslo >
Re: [dev] an approach to Matrix client that sucks less
On Thu, 20 Feb 2020 15:33:25 -0500 "Greg Reagle" wrote: Dear Greg, > Thank you Laslo Hunhold for your feedback. sure, happy to give it! :) > Based on your other comments, I assume that when you stress the > importance of the "interface", you are not referring to end-user > interface (like command line, or curses, or GTK, etc.) but more of a > lower level interface, like the way that ii works with files and > directories and FIFOs? yes, exactly. If you do that right and work out good, solid, data structures, higher interfaces are easy to implement on top of this interface. With chat clients, you mostly deal with state changes. If you manage to represent them properly in your interface, you are fine. I wouldn't probably do it with files, even though ii shows how easy it is to write chatbots and stuff. Instead, I'd go the route of popular OpenBSD projects like OpenSMTPD or httpd which have multiple "worker" threads that communicate over a form of IPC. This greatly reduces the attack surface, allows you to implement things like unveil and pledge easily, and is very unixy but does not limit you to just the filesystem. > Are you referring to https://git.2f30.org/ratox/file/README.html. > Are you suggesting that I use it as a template for the interface > (along with ii). See above. :) To be honest, we struggled a lot with state changes within toxcore and really hit a wall when they implemented video conferences on top of the protocol in a really ugly way. Ratox is full of finite state machines, but maybe another approach is better (e.g. the one I give above for security and resiliency reasons). The popular Riot client is literally one big blob where everything accesses everything. Concerns need to be separated to really have a solid application. If the only thing an attacker can use is your IPC mechanism and you are pretty strict with your parsing in this regard, you are already in a good direction. Make up your mind in this regard, but to just give you an idea: Matrix fundamentally builds on top of JSON that is served via HTTP. Thus, one of the aforementioned "threads" could just have the task to do the HTTP-dispatching and JSON-parsing and -creating. When it has parsed and "categorized" the type of request, it can then use IPC to send it off to another component. The dispatcher itself doesn't need to have file system access. It only needs to listen on a socket, so if an attacker manages to use a vulnerability in the IP-stack and gain full control of that process, with proper pledge/unveil in effect, they cannot read any of the file system or do any syscalls other than networking syscalls. If you then have properly sealed off the IPC mechanism and filter off malformed stuff properly (YMMV), you are relatively safe. > I am certainly open to suggestions to other languages. If using a > different language can get me more contribution from others, that > would be very valuable to me indeed. But I do want something higher > level than C. I understand that. However, I often see that people are just scared of breaking their projects up into multiple sub-modules. Higher level languages invite you to do it all in one process or at least permission-level. In the end, everything is as unsafe as C once you have control over the process, so it's best, in my opinion, to adapt the coding style to the language rather than trying to solve more complex problems with more elaborate paradigms. With best regards Laslo
Re: [dev] an approach to Matrix client that sucks less
Thank you Laslo Hunhold for your feedback. On Thu, Feb 20, 2020, at 14:54, Laslo Hunhold wrote: > yes, we haven't looked into Matrix much here. I have to admit that it's > the most promising protocol out there, in my opinion. What matters for > a suckless client is the interface. Based on your other comments, I assume that when you stress the importance of the "interface", you are not referring to end-user interface (like command line, or curses, or GTK, etc.) but more of a lower level interface, like the way that ii works with files and directories and FIFOs? > A few years ago, Dimitris, Hiltjo, > I and a few others wrote a client for toxcore, and we kept it similar > to ii with a file based hierarchy. The client itself was event-driven > and had a pretty sophisticated state machine to handle the different > states. We even supported calls and file transfers, but sadly, tox died > due to internal conflicts and an inconsistent API. Are you referring to https://git.2f30.org/ratox/file/README.html. Are you suggesting that I use it as a template for the interface (along with ii). > Investigating Matrix is definitely a nice thing! I am not a big fan of > Lua though, I am certainly open to suggestions to other languages. If using a different language can get me more contribution from others, that would be very valuable to me indeed. But I do want something higher level than C. > but what matters is the interface. From that point on, it > shouldn't matter which language you use to implement it. I understand. I am not very familiar with IRC or with ii (I've used IRC very very little). Could you recommend and IRC client that works on top of ii that is fairly easy to use, not requiring a lot of scripting and setup and so forth? Maybe something on the level of mutt? So that I can get an idea of how to make a friendly UI on top of the FIFOs.
Re: [dev] an approach to Matrix client that sucks less
On Thu, 20 Feb 2020 11:44:19 -0500 "Greg Reagle" wrote: Dear Greg, > Hi y'all. I don't see any Matrix client at > https://suckless.org/rocks/ or https://suckless.org/other_projects/ > and I am thinking of making one. I use the Riot.im web app client > which has a lot of features, but is bloated. > > Do any of you know of a Matrix client that is not bloated? I have > looked at many of the clients at https://matrix.org/clients. I have > tried several. Some of them are either too bloated, use a language > I'm not crazy about, or lack some basic features (too immature). > > I have never used Weechat and am feeling too lazy to learn. I expect > there would be a lot to learn just to use it as an IRC client, then > as a Matrix client I don't know how well it works. I am reluctant to > invest the time and effort (but maybe I should, I don't know). > > I might write my own Matrix client. I would probably use Lua. C is > too low level for my taste. Would any of you be interested in > contributing? I expect I would start by writing command line > interface. CLI would be good to have, and I could learn a lot about > implementing Matrix without being bothered by UI issues. After the > CLI was done, then I would consider what to do next, maybe a GUI, > maybe a TUI, etc. yes, we haven't looked into Matrix much here. I have to admit that it's the most promising protocol out there, in my opinion. What matters for a suckless client is the interface. A few years ago, Dimitris, Hiltjo, I and a few others wrote a client for toxcore, and we kept it similar to ii with a file based hierarchy. The client itself was event-driven and had a pretty sophisticated state machine to handle the different states. We even supported calls and file transfers, but sadly, tox died due to internal conflicts and an inconsistent API. Investigating Matrix is definitely a nice thing! I am not a big fan of Lua though, but what matters is the interface. From that point on, it shouldn't matter which language you use to implement it. With best regards Laslo
[dev] an approach to Matrix client that sucks less
Hi y'all. I don't see any Matrix client at https://suckless.org/rocks/ or https://suckless.org/other_projects/ and I am thinking of making one. I use the Riot.im web app client which has a lot of features, but is bloated. Do any of you know of a Matrix client that is not bloated? I have looked at many of the clients at https://matrix.org/clients. I have tried several. Some of them are either too bloated, use a language I'm not crazy about, or lack some basic features (too immature). I have never used Weechat and am feeling too lazy to learn. I expect there would be a lot to learn just to use it as an IRC client, then as a Matrix client I don't know how well it works. I am reluctant to invest the time and effort (but maybe I should, I don't know). I might write my own Matrix client. I would probably use Lua. C is too low level for my taste. Would any of you be interested in contributing? I expect I would start by writing command line interface. CLI would be good to have, and I could learn a lot about implementing Matrix without being bothered by UI issues. After the CLI was done, then I would consider what to do next, maybe a GUI, maybe a TUI, etc.
