At first I thought that sounded great, but then I realized that that would exclude files that I want to be backed up, like `dir-locals-2.el`, which should be excluded from git, but should also be backed up. There doesn't seem to be a great solution to that in general.
If you are making a client for anyone besides yourself at some point people will expect to be able to use one of the many "optional" features. At that point it doesn't matter if you technically don't need to support it as users will then simply see it as a shortcoming of your client.
So if we are talking about anything more than a MVP client these optional specs should be included in the argument as only being optional in theory.
The official spec is a combination of hundreds of tiny specs and extensions, akin to XMPP. There may be one single reference, but it's constantly evolving.
> It is a very simple format.
In a best case scenario, sure. The Discord version of your example would just be "Hello, world" without any of the other JSON.
In practice, you need to deal with a whole range of message types with various references and slight variations. Inner Matrix message bodies are essentially freeform, which makes Matrix quite powerful but also difficult to deal with compared to the "different HTTP endpoint per request type" approach Discord takes.
> This is also optional. If you want to talk in unencrypted public rooms, for example, you needn't bother with it.
Sure, if you accept having your users install two different apps, one for encrypted chat and one for group chats.
> The official spec is a combination of hundreds of tiny specs and extensions, akin to XMPP.
You could say the same thing about any specification that involved multiple features.
> There may be one single reference, but it's constantly evolving.
So is HTML. But one of my Matrix clients from 7 years ago still works. How well would a 7-year-old Web browser work on today's Web? Could you use a 7-year-old version of a third-party Discord client?
> In a best case scenario, sure. The Discord version of your example would just be "Hello, world" without any of the other JSON.
So Discord encodes the message type in the URL instead of the body. So what? It has to go somewhere, and I'd generally rather have URLs include less, not more.
I actually messed up earlier: The `type` field is included in the event as seen after sending. The sent event could just be, e.g.
I can't see anything to complain about there. (Sure, I'd prefer Lisp expressions over JSON, but come on.)
> In practice, you need to deal with a whole range of message types with various references and slight variations.
Is the same not true for Discord? It supports a variety of message types as well, and Discord also constantly evolves the system and adds new features (every time I log on to it I'm bombarded with news of updates, yet I still can't find a way to view a simple list of "servers" I'm in by names instead of by unintelligible icons).
> In practice, you need to deal with a whole range of message types with various references and slight variations. Inner Matrix message bodies are essentially freeform, which makes Matrix quite powerful but also difficult to deal with compared to the "different HTTP endpoint per request type" approach Discord takes.
That seems to conflate two issues. And I don't see how it's more difficult to deal with than any key-value store in any program. You collect the values from the keys you care about. That's it. Every Matrix event has certain basic fields in common. A few are specific for message type (e.g. a filename field for a file or image upload event). Where's the problem? Destructuring incoming data is probably the easiest part of writing a messaging client.
> Sure, if you accept having your users install two different apps, one for encrypted chat and one for group chats.
I use unencrypted 1:1 chats as well (in which case it's no worse than IRC or Discord, where the server operator could read your messages).
I think that's pretty cool, frankly: that a modern system with well-audited end-to-end encryption still allows it to be used optionally. You're not required to deal with the complexity of key management and session verification if you don't need or want it. Matrix lets me choose.
And I can choose my homeserver or run my own. Can you run your own Discord server (actual server)?
The only significant appeal I see for Discord is the existing user base. Well, that didn't save AOL. I guess we'll see how it turns out.
> You could say the same thing about any specification that involved multiple features.
You could, which is why I find APIs like Discord's easier to program for.
> So is HTML.
Web dev had a certain reputation, partially because of that.
> Is the same not true for Discord?
Discord sure has a bunch of weird format options, but the core messaging API hasn't changed significantly in years as far as I can tell. You have text messages, sometimes with attachments, and that's about it. Even the base structure of usernames changing has been backwards compatible without API changes.
> Destructuring incoming data is probably the easiest part of writing a messaging client.
That depends on the structure of the data, really.
> I use unencrypted 1:1 chats as well
That does make things easier. But I don't. A fancy GTK version of Cinny would he completely useless to me without basic encryption support. I still run into encryption bugs from time to time using multiple types of client.
> And I can choose my homeserver or run my own. Can you run your own Discord server (actual server)?
So do I! And I can't, obviously. But realistically, who cares? The Venn diagram between "people who want to be able to run their own server" and "people I know who know how to install Arch" is pretty much a single circle.
I want Matrix/XMPP/the Fediverse to succeed, but nobody but technology enthusiasts seems to care about any of this. A chat service I can use to talk to developers and fellow server admins is great in its own right, but it's not a replacement for Discord where the normal people hang out.
From what I can tell, dissent is built in a way that shouldn't make it too hard to convert into a Matrix client. You'll need to fight with Spaces to get the "Discord server" concept across, though. For the people who don't want to use Discord, most of the work is there. All you need is to grab a Matrix library for go (gomatrix died a month ago so you'd need to fork/vendor that I guess?) and rework the data store.
I think my biggest issue with Matrix is mostly the status of most existing libraries. Many of them are outdated, partially cover the stack, and there's not a lot of info on how to use them. Libraries get partially developed, and then abandoned for various reasons. Because of this, it's easier to maintain your own data model code rather than reusing existing work.
Another thing that's rather annoying to work with is the way Matrix deals with things like emoji reactions and state. Everything is one big additive list of messages that needs to be read completely to get a proper view of the room.
Whatever the exact reasons may be, I had an easier experience writing a small Discord client than I had writing a small Matrix client. Perhaps my expectations were simply too high.
> You could say the same thing about any specification that involved multiple features.
You could, which is why I find APIs like Discord's easier to program for.
> So is HTML.
Web dev had a certain reputation, partially because of that.
> Is the same not true for Discord?
Discord sure has a bunch of weird format options, but the core messaging API hasn't changed significantly in years as far as I can tell. You have text messages, sometimes with attachments, and that's about it. Even the base structure of usernames changing has been backwards compatible without API changes.
> Destructuring incoming data is probably the easiest part of writing a messaging client.
That depends on the structure of the data, really.
> I use unencrypted 1:1 chats as well
That does make things easier. But I don't. A fancy GTK version of Cinny would he completely useless to me without basic encryption support. I still run into encryption bugs from time to time using multiple types of client.
> And I can choose my homeserver or run my own. Can you run your own Discord server (actual server)?
So do I! And I can't, obviously. But realistically, who cares? The Venn diagram between "people who want to be able to run their own server" and "people I know who know how to install Arch" is pretty much a single circle.
I want Matrix/XMPP/the Fediverse to succeed, but nobody but technology enthusiasts seems to care about any of this. A chat service I can use to talk to developers and fellow server admins is great in its own right, but it's not a replacement for Discord where the normal people hang out.
From what I can tell, dissent is built in a way that shouldn't make it too hard to convert into a Matrix client. You'll need to fight with Spaces to get the "Discord server" concept across, though. For the people who don't want to use Discord, most of the work is there. All you need is to grab a Matrix library for go (gomatrix died a month ago so you'd need to fork/vendor that I guess?) and rework the data store.
I think my biggest issue with Matrix is mostly the status of most existing libraries. Many of them are outdated, partially cover the stack, and there's not a lot of info on how to use them. Libraries get partially developed, and then abandoned for various reasons.
Another thing that's rather annoying to work with is the way Matrix deals with things like emoji reactions and state. Everything is one big additive list of messages that needs to be read completely to get a proper view of the room.
Whatever the exact reasons may be, I had an easier experience writing a small Discord client than I had writing a small Matrix client. Matrix can be as easy as Discord, but only if you don't try to do anything more complex than an IRC client.
Wow, Brian, funny running into you here after all these years! You may remember me as a guy who ran the site for you for a year or two when you needed a break. You also helped me get started with Web development on the server-side. You were always kind, encouraging, and trusting--sometimes I still marvel at how well everything worked out considering how little any of us really knew each other. You seemed to have a knack for finding good-natured people to join in. I have a lot of fond memories from playing JK and working on the site with the great community.
Do you still have the same email address at the .net domain? I'd like to contact you again. :)
I actually emailed you a couple of days ago (at something alphapapa) -- my email address is the same but with `massassi.com` instead of `massassi.net`. Hope to hear from you!!!
I agree, we had so many great people help over the years. It was amazing because virtually everybody had essentially root access to the site and we had no backups, no recovery plan, nothing at all in case things went south. It's quite a bit better now!
See https://github.com/alphapapa/org-ql, which can be used to select entries with a SQL-like language, and then you can do whatever you like with the results.
Thanks for the kind words. I'm glad they're useful to you.
org-ql is a search tool. It provides an alternative to some parts of org-agenda and integrates with it to some extent. Its searching is much faster and more powerful than the built-in Org search tools; see its documentation for details.
> But I get the vibe that we won't be seeing a client I like anytime soon; or it'll be a very minimalistic client with no support for all the fancy modern features, in which case I'd likely get the same or better experience with IRC anyway.
I don't know if you're the Emacs type, but you might be interested in https://github.com/alphapapa/ement.el. It feels kind of like an upgraded IRC, with support for features like images and rich text, and it tries to be privacy-respecting (e.g. read receipts and typing notifications are enabled by default, to imitate Element, but optional).
It doesn't support E2EE natively, but E2EE works through the Pantalaimon proxy, so it can be used with E2EE rooms that way. (Or if you don't care about E2EE rooms, like me (I mostly don't), you can use it in unencrypted rooms without using Pantalaimon.)
reply