105 lines
4.8 KiB
Markdown
105 lines
4.8 KiB
Markdown
I tend to complain about bad software, but instead of writing a better
|
|
replacement like any sane developer I simply bitch about it and do something
|
|
else. But I'm finally putting an end to that.
|
|
|
|
## libleet
|
|
|
|
Back in September I finally started working on a Matrix client library,
|
|
or what they call SDK. Not much happened though, as I used Windows for a
|
|
week and I also worked on other projects such as curload. I got back into
|
|
the project in October though and 6 days I had implemented most of the basic
|
|
features. At this point, it was actually quite capable and could log in,
|
|
return rooms and spaces, download messages, upload messages, handle discovery,
|
|
aliases, upload/download to/from mxc:// media URLs and some other small
|
|
features.
|
|
|
|
After that, I started working on end to end encryption using libolm. This
|
|
has been quite time consuming, and although it's not complete just yet,
|
|
I hope to finish most of it very soon, and then I can work on other
|
|
simpler features.
|
|
|
|
Anyways, the library is called
|
|
[libleet](https://git.speedie.site/speedie/libleet)
|
|
and it's written in C++20 and partially C (unfortunately). You can see
|
|
`examples/basic-chat-program.cpp` for a basic example, which has about as
|
|
many features as an IRC client, and in just 134 lines of code including
|
|
comments because as of now the library abstracts a lot of stuff. This
|
|
is a design goal, but I don't want abstraction to be required, because
|
|
that just leads to an unhackable codebase. I believe abstraction is
|
|
important so developers can focus on designing the graphical user
|
|
interface, rather than the backend.
|
|
|
|
libleet design goals:
|
|
|
|
- Written in modern C++, do not hesitate to use modern features.
|
|
- Classes and vectors are god
|
|
- Clean codebase (that includes variable and function names)
|
|
- Excellent documentation
|
|
- Implement most features in the Matrix spec, and maybe more on
|
|
top. Most libraries only implement basic features, some don't
|
|
even implement what I consider to be basic features, such as spaces.
|
|
- Abstract a lot of junk so developers don't
|
|
have to spend months implementing Matrix basics before they
|
|
can get anywhere.
|
|
- Optionally try to be compatible with Element, so that the experience
|
|
is smooth if you use both clients. For example, support the Element
|
|
'People' feature.
|
|
- Matrix 2.0 support
|
|
|
|
## leetchat?
|
|
|
|
But what about the *client*? I've only talked about a library so far.
|
|
Well, I will be writing a client as well, and the general goal is of
|
|
course to improve on some of the things that existing clients suck at.
|
|
There are plenty of things, and as such I've created a
|
|
[matrix client wishlist](https://git.speedie.site/speedie/matrix-client-wishlist)
|
|
repository which is simply a list of features that I want from the client.
|
|
You can create an issue for any features you might want.
|
|
|
|
The client will be using a backend written using libleet in C++, and
|
|
a frontend written in HTML, CSS and JavaScript. That might not make
|
|
that much sense at first, but hear me out. If we use a backend that
|
|
runs on a server, it means we can add additional features that
|
|
require a server but aren't part of the Matrix specification.
|
|
One thing on my Matrix client wishlist is friends. Of course,
|
|
features like these could only apply to this specific client
|
|
and not any other clients, but if that means improving the
|
|
user experience for users of said client then I think it's worth it.
|
|
|
|
Writing the client as a web page has several benefits, too. I
|
|
was initially going to write either a GTK or QT program, but I
|
|
quickly realized how limited those are in terms of customization.
|
|
They're fine if you want to stick to the OS native theming,
|
|
but as soon as you want anything outside of that you're
|
|
totally screwed as a developer and as a user. By writing a
|
|
web client, the client will run on any device that has a modern
|
|
web browser, the client will be extremely customizable as we
|
|
can do absolutely anything using CSS style sheets and JavaScript.
|
|
So the idea is to use AJAX to interact with a C++ backend.
|
|
|
|
Design goals for leetchat:
|
|
|
|
- Resizeable and movable UI elements (basic but important feature)
|
|
- User CSS/JavaScript
|
|
- Spaces (very very important)
|
|
- Friends
|
|
- Bulk actions (how does almost every Matrix client not have this?)
|
|
- Sliding sync (for speed, once Matrix 2.0 is actually supported by
|
|
most home servers)
|
|
- Cache as much as possible, preferably serverside
|
|
- Eventually support most if not all Element features
|
|
|
|
I will probably not be sticking with this name, so if you have any
|
|
name suggestions, I guess create an issue for that as well.
|
|
|
|
## sample text
|
|
|
|
So yeah, I just wanted to talk about that for a bit. If you want
|
|
to help implementing Matrix features and you know C++ I'd appreciate
|
|
it if you could help me implement stuff from the Matrix spec.
|
|
Also, feel free to request features in the matrix-client-wishlist
|
|
repository. It would be useful to know what others actually want
|
|
rather than just what I personally want.
|
|
|
|
That's it for today, have a nice day!
|