[githubalphapapa]

> Matrix has a billion different standards

There is one specification, available on the official site. It isn't, and never will be, required to implement all of it.

> a complex message format

It is a very simple format. Here's an example message (as sent by a client; additional fields are added by the server, such as server-side timestamp):

    {
        "content": {
            "body": "Hello, world.",
            "msgtype": "m.text"
        },
        "type": "m.room.message",
    }

> and encryption to deal with

This is also optional. If you want to talk in unencrypted public rooms, for example, you needn't bother with it.

The spec is so simple that you can send a Matrix message from a shell with curl. It's just JSON over HTTP.

[creesch]

With all due respect but

> This is also optional.

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.

[jeroenhd]

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.

[githubalphapapa]

> 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.

    {
        "content": {
            "body": "Hello, world.",
            "msgtype": "m.text"
        }
    }

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.

[jeroenhd]

> 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.

[jeroenhd]

> 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.