++blog post
This commit is contained in:
parent
e10301ae29
commit
3eb4d8c943
|
@ -0,0 +1,104 @@
|
|||
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!
|
|
@ -0,0 +1 @@
|
|||
2023-10-27
|
|
@ -0,0 +1 @@
|
|||
I'm finally breaking my worst habit. I'm writing a Matrix client.
|
Reference in a new issue