4 ms·

That sounds a lot like IRC https://matrix.org/docs/guides/introduction https://matrix.org/docs/guides/introduction

by kken 5y ago

corty 5y ago
Well, yes. Matrix is a federated protocol like IRC, XMPP/Jabber, IRCv3 and a few other less known ones. Being federated is basically what made Email so widespread, and I guess in the long run that model of doing things will be the only viable one. For most people, states, companies and organisations, using a centralized foreign service, no matter how trustworthy it were said to be, isn't an option.
dividedbyzero 5y ago
I think it shares lots of the core ideas behind IRC, but it thankfully incorporates a lot of progress made since IRC. You get creature comforts like Slack and the like (depending on the client), but it's still decentralized (even the Gematik setup, apparently!) and it you can make it very secure.
preya2k 5y ago
Similar, but different: IRC is decentralized (you connect to a certain server, and you can interact with users/rooms on this server). Matrix is federated (you connect to a certain server, but you can interact with users/rooms on every other server – much like you can write E-Mails to anyone who has an E-Mail address, no matter if its Gmail or Yahoo). So when you want to compare it to anything else: it's much rather like XMPP than it is like IRC.
- q3k 5y ago
  It goes even further than XMPP, as rooms in Matrix are fully distributed, with no single server owning them. Names like #foo:example.com are aliases, and aliases can be added under other homserver domains, too. XMPP MUC rooms are, IIRC, dependent on the server hosting them and generally coordinating exchange.
  - jsmsmsj 5y ago
    So if #foo:example.com is in use in a cluster of servers and there's a netsplit for some reason and servers in group A lose connection with group B but both groups continue using the channel, what happens to the message history when the netsplit is resolved?
    - q3k 5y ago
      All room events (ie. messages) are part of a DAG, with each message indicating the most recent causality source, eg. another message that the client saw when sending this one. Think vector clocks, but more explicit. Any time an event arrives referencing some other missing event, servers and clients can act on that knowing that there's some kind of split happening. Each event is also signed by the homeserver of the originator of the messages, so missing messages (due to partial netsplits) can be routed through third-parties, around the netsplit. For full split-brain scenerios, after a merge, the two DAGs get joined and the effective room state is reconciled. The big picture is that Matrix rooms are best seen as eventually-consisted distributed event log . :) https://matrix.org/docs/spec/#event-graphs https://matrix.org/docs/spec/#event-graphs
    - Arathorn 5y ago
      The scrollback ends up syncing up after the netsplit on both sides of the partition - you see a flood of messages come in from the other side of the split. In the relatively near future the remote side of the split will shown as a thread (if your client supports threads). Technically, every message you send in Matrix is a mini-netsplit which then resolves as soon as it's received by the other server(s). So you don't tend to notice partitions, unless they go on for minutes on end and disrupt the conversation, but even then the history syncs up afterwards.
    - ryukafalz 5y ago
      From the server's perspective, the graph of conversation history from group A and group B merge. From the client's perspective... depends on the client I think, but most seem to display the messages from the other side of the split all at once when they're first received. Clients don't currently make it clear when messages came from the other side of a long netsplit, but the data is there on the server so in principle they could. I think the client API might need some changes before that'd be possible though.
- ndndjfj 5y ago
  Except XMPP uses DNS for message routing from a human readable handle, user@host.com, but Matrix uses a central database "identity server" operated by Matrix.org and federation fails if this service goes down. So Matrix is like XMPP, except that XMPP is really federated, but Matrix's "federation" is partial and therefore it's mostly marketing. Matrix is really mostly marketing overall. That's part of why it's so popular here; HNers love shiny bullshit. Honestly XMPP is a better protocol, it's even still being updated and has many more server and client implementations, including modern ones, but Matrix has great PR.
  - q3k 5y ago
    > but Matrix uses a central database "identity server" operated by Matrix.org and federation fails if this service goes down. It doesn't. Matrix identities (like @q3k:hackerspace.pl) are resolved to homeserver instances via DNS or HTTPS .well-known requests. $ curl https://hackerspace.pl/.well-known/matrix/server {"m.homeserver":{"base_url":"https://matrix.hackerspace.pl"},"m.server":"matrix.hackerspace.pl:443"} or $ dig +short SRV _matrix._tcp.asra.gr 10 0 443 synapse.asra.gr.
  - ryukafalz 5y ago
    > Except XMPP uses DNS for message routing from a human readable handle, user@host.com, but Matrix uses a central database "identity server" operated by Matrix.org and federation fails if this service goes down. Uh, no? Federation certainly does not fail if the identity server goes down. You won't be able to invite someone to a room by email address or phone number if whatever identity server you're using goes down, but it's nowhere near the critical path for federation.
  - stryan 5y ago
    > Except XMPP uses DNS for message routing from a human readable handle, user@host.com, but Matrix uses a central database "identity server" operated by Matrix.org and federation fails if this service goes down. This statement is almost entirely wrong. The identity server is A) only for mapping 3PID (3rd Party Identities, i.e. email addresses or phone numbers) to matrix usernames, B) can be self-hosted, and C) not required at all for federation. Federation does not in anyway require services provided by Matrix.org
- ptman 5y ago
  Matrix is open federation, like Email. IRC is closed federation, more like a database cluster or some other distributed service where all components are run by a single team.

That sounds a lot like IRC https://matrix.org/docs/guides/introduction https://matrix.org/docs/guides/introduction

by kken 5y ago

That sounds a lot like IRC https://matrix.org/docs/guides/introduction https://matrix.org/docs/guides/introduction

Well, yes. Matrix is a federated protocol like IRC, XMPP/Jabber, IRCv3 and a few other less known ones. Being federated is basically what made Email so widespread, and I guess in the long run that model of doing things will be the only viable one. For most people, states, companies and organisations, using a centralized foreign service, no matter how trustworthy it were said to be, isn't an option.

dividedbyzero 5y ago

I think it shares lots of the core ideas behind IRC, but it thankfully incorporates a lot of progress made since IRC. You get creature comforts like Slack and the like (depending on the client), but it's still decentralized (even the Gematik setup, apparently!) and it you can make it very secure.

preya2k 5y ago

Similar, but different: IRC is decentralized (you connect to a certain server, and you can interact with users/rooms on this server). Matrix is federated (you connect to a certain server, but you can interact with users/rooms on every other server – much like you can write E-Mails to anyone who has an E-Mail address, no matter if its Gmail or Yahoo). So when you want to compare it to anything else: it's much rather like XMPP than it is like IRC.

q3k 5y ago
It goes even further than XMPP, as rooms in Matrix are fully distributed, with no single server owning them. Names like #foo:example.com are aliases, and aliases can be added under other homserver domains, too. XMPP MUC rooms are, IIRC, dependent on the server hosting them and generally coordinating exchange.
- jsmsmsj 5y ago
  So if #foo:example.com is in use in a cluster of servers and there's a netsplit for some reason and servers in group A lose connection with group B but both groups continue using the channel, what happens to the message history when the netsplit is resolved?
  - q3k 5y ago
    All room events (ie. messages) are part of a DAG, with each message indicating the most recent causality source, eg. another message that the client saw when sending this one. Think vector clocks, but more explicit. Any time an event arrives referencing some other missing event, servers and clients can act on that knowing that there's some kind of split happening. Each event is also signed by the homeserver of the originator of the messages, so missing messages (due to partial netsplits) can be routed through third-parties, around the netsplit. For full split-brain scenerios, after a merge, the two DAGs get joined and the effective room state is reconciled. The big picture is that Matrix rooms are best seen as eventually-consisted distributed event log . :) https://matrix.org/docs/spec/#event-graphs https://matrix.org/docs/spec/#event-graphs
  - Arathorn 5y ago
    The scrollback ends up syncing up after the netsplit on both sides of the partition - you see a flood of messages come in from the other side of the split. In the relatively near future the remote side of the split will shown as a thread (if your client supports threads). Technically, every message you send in Matrix is a mini-netsplit which then resolves as soon as it's received by the other server(s). So you don't tend to notice partitions, unless they go on for minutes on end and disrupt the conversation, but even then the history syncs up afterwards.
  - ryukafalz 5y ago
    From the server's perspective, the graph of conversation history from group A and group B merge. From the client's perspective... depends on the client I think, but most seem to display the messages from the other side of the split all at once when they're first received. Clients don't currently make it clear when messages came from the other side of a long netsplit, but the data is there on the server so in principle they could. I think the client API might need some changes before that'd be possible though.
ndndjfj 5y ago
Except XMPP uses DNS for message routing from a human readable handle, user@host.com, but Matrix uses a central database "identity server" operated by Matrix.org and federation fails if this service goes down. So Matrix is like XMPP, except that XMPP is really federated, but Matrix's "federation" is partial and therefore it's mostly marketing. Matrix is really mostly marketing overall. That's part of why it's so popular here; HNers love shiny bullshit. Honestly XMPP is a better protocol, it's even still being updated and has many more server and client implementations, including modern ones, but Matrix has great PR.
- q3k 5y ago
  > but Matrix uses a central database "identity server" operated by Matrix.org and federation fails if this service goes down. It doesn't. Matrix identities (like @q3k:hackerspace.pl) are resolved to homeserver instances via DNS or HTTPS .well-known requests. $ curl https://hackerspace.pl/.well-known/matrix/server {"m.homeserver":{"base_url":"https://matrix.hackerspace.pl"},"m.server":"matrix.hackerspace.pl:443"} or $ dig +short SRV _matrix._tcp.asra.gr 10 0 443 synapse.asra.gr.
- ryukafalz 5y ago
  > Except XMPP uses DNS for message routing from a human readable handle, user@host.com, but Matrix uses a central database "identity server" operated by Matrix.org and federation fails if this service goes down. Uh, no? Federation certainly does not fail if the identity server goes down. You won't be able to invite someone to a room by email address or phone number if whatever identity server you're using goes down, but it's nowhere near the critical path for federation.
- stryan 5y ago
  > Except XMPP uses DNS for message routing from a human readable handle, user@host.com, but Matrix uses a central database "identity server" operated by Matrix.org and federation fails if this service goes down. This statement is almost entirely wrong. The identity server is A) only for mapping 3PID (3rd Party Identities, i.e. email addresses or phone numbers) to matrix usernames, B) can be self-hosted, and C) not required at all for federation. Federation does not in anyway require services provided by Matrix.org
ptman 5y ago
Matrix is open federation, like Email. IRC is closed federation, more like a database cluster or some other distributed service where all components are run by a single team.