5 ms·

i'd argue that the Matrix.org Foundation is just as 'recognized' as the XMPP Standards Foundation :) In terms of disingenuousness - i'd argue that the definiti

i'd argue that the Matrix.org Foundation is just as 'recognized' as the XMPP Standards Foundation :) In terms of disingenuousness - i'd argue that the definition of disingenuous is accusing us of reinventing the wheel rather than acknowledging that Matrix is an entirely different type of technology to IRC or XMPP. It's more similar to NNTP or Git than either IRC or XMPP. For better or worse, trying to solve existing problems using new approaches is how things evolve. On which note, it's cool to see delta.chat and COI trying a totally different approach too.

SamWhited 8y ago
> Matrix is an entirely different type of technology to IRC or XMPP. It's more similar to NNTP or Git than either IRC or XMPP. What does this have to do with anything? It's used for chat and solves all the same problems. You could easily have done all the same things (including building a system that does syncing like matrix nodes) on top of an existing protocol instead of reinventing the wheel.
- Arathorn 8y ago
  We seem to have this same dead-end conversation every few months, so indulge me as I try to break the impasse with a story instead. When I was about 13, I worked on a really fun chat system at school called (wait for it) iNFERNO][ (it was the second attempt at a chat system called iNFERNO). It was pretty awesome, and worked like this: the school ran a large network of 68k-based Macs (LCs, Centrises, even a Quadra) networked to a single Apple Workgroup Server, which ran a Filemaker Pro db instance that the school used for its HR and record keeping. As it happened, the DB server was set up such that anyone could create DBs on it, so the school geek community spun up a few to play with. If you've ever used Filemaker, you'll know that it's a visual DB - almost creating Forms as the first-class citizen (a bit like Hypercard) and the fact they're backed by tabular data is almost hidden. Even more excitingly, it even had basic networking so you could run network queries between DB instances - including exchanging arbitrary objects (e.g. images, videos etc), if i remember correctly. So, what we did was to set up a centralised DB (iNFERNO itself) on the server, shared over the network, which stored a bunch of chatroom history and provided a graphical timeline view onto the room when opened up over the network from a Mac (set up to occupy the top 2/3rds of your screen). Meanwhile, and this is the fun bit: we also wrote a DB instance called your "iNFERNO Key", which you stored on a 3.5" floppy disk and could run as a local DB off the disk on any Mac you happened to walk up to. It coughed up a window on the bottom 1/3rd of the screen, which provided your composer prompt. Everyone had their own key, and customised it to their heart's content with different themes, colour schemes, buttons, bot-functionality etc. And it stored their credentials (and we even tried some basic shared-secret e2e crypto) to make logging in trivial - you just put the disk in the drive and clicked the DB (which would in turn spawn the separate main window to view the shared DB timeline). When you sent a message (which could be text, or arbitrary filemaker objects like images, videos etc), Filemaker let you stage the table row locally and then insert it into the shared DB instance, so you ended up with a surprisingly fun and usable server/client chat system, with arbitrary scrollback, multidevice support, file-transfer etc... using a batshit crazy architecture which involved schoolkids running around waving 3.5" disks around and forking each other's "keys" and somewhat unnecessarily authoring messages using a local DB instance when the whole thing could have been done on the serverside DB instead. The whole thing lasted about 3 months, getting increasingly popular until the school went nuts at their Filemaker server being completely overloaded and tragically turned it all off. And whilst I still probably have my Key somewhere, we surely didn't have a backup of the central server itself :( So, my point is: this was a chat system, with many of the features shared by XMPP, Matrix, Slack, Discord etc today. Could we have built it on top of something else? Sure, we could have built it on IRC instead or Talk or some BBS based thing. But instead we chose to experiment with a totally different architecture, which had its own weird trade-offs and benefits, and learned a bunch of stuff along the way. (I still miss the idea of literally synchronising rich graphical objects over the network - it almost felt like Croquet or one of the virtual world things). And so, whilst you're totally right that we could have tried to layer Matrix semantics over the top of XMPP or IMAP or Filemaker(!), we similarly wanted to try a totally different architecture; one without stanzas and message passing; one without all the historical baggage of XMPP; one which only does group conversations; etc. So I'd argue this is how stuff evolves, and sometimes it's good to experiment with building on a new base. And if it doesn't work out; hopefully it at least provided a learning experience for all concerned. The same goes for COI layering chat over IMAP; almost as questionable as layering chat over a networked DB ;). So, let's just get on with building stuff and seeing what works and what doesn't. This isn't a case of re-inventing the wheel for the sake of it, but seeing how well things work if you build on an entirely different set of foundations.
  - fock 8y ago
    +1 and arguably the concurrent clients + multiuser thing is something which XMPP did never get around really. There are at least a dozen or so XEPs which noone is implementing (except for Conversations) which make basic functionality a mess. You download any client and get basic 1on1-chat with no missed messages when both parties are online. Everything else depends on, .... whatever. Even major providers needed some years to get around this (look at Whatsapp). So I think it's really not reinventing the wheel if one tries to implement something anew learning from the pasts mistakes (if you are affiliated with riot/matrix: keep up the good work!)
    - jjrh 8y ago
      What do you mean? Unless you're using a very old client like pidgin, this stuff shouldn't be a problem.
      - fock 8y ago
        well, I'm open to client suggestions (and to public servers, where I can try them out too). I was told by Google (tm) that gajim should be one of the most feature-complete clients on the desktop. tried it with conversations on the phone. group messages go into some archive-window (instead of showing up in the chat window like in every over program), sometimes the archive misses them... pictures are a link to the server, so I have to manually download them all. encryption with multiple clients is a mess (even more so than matrix). av is completely missing. of course this are all relatively minor things from a technical standpoint but they add up and together with the thing that a large amount also depends on the server this makes for a very bad user experience (basically it currently means: run your own server and use conversations)...
        jjrh 8y ago
        > group messages go into some archive-window (instead of showing up in the chat window like in every over program), sometimes the archive misses them... Not sure what that even means. Worth reporting. > pictures are a link to the server, so I have to manually download them all. I think you need to install the image preview plugin. For gajim make sure it's a recent version. Dino-im https://dino.im/ https://dino.im/ is decent. poezio https://poez.io/en/ https://poez.io/en/ if you want a text client. converse.js https://conversejs.org/ https://conversejs.org/ for a web client. Public server wise I don't have any recommendations (but i'm sure others have plenty) other than movim. https://movim.eu/#try https://movim.eu/#try they have a baked in client (and do a whole bunch of other stuff like micro blogging) but once you have a account, there is no reason you can't use any client you want. Encryption with omemo is a issue and usability could be improved (I believe people are working on that).
zinid 8y ago
> i'd argue that the Matrix.org Foundation is just as 'recognized' as the XMPP Standards Foundation :) Recognized by whom? The XSF has standardized their core in IETF. Is there something similar for Matrix.org Foundation? > trying to solve existing problems using new approaches is how things evolve. What new approaches? You're just recreating federated IM network using different wire format. How on earth is it innovative or new? Using HTTP+JSON instead of TCP+XML is something new? Bridging to other IM networks is something innovative? > Matrix is an entirely different type of technology to IRC or XMPP. It's more similar to NNTP or Git than either IRC or XMPP. I've heard this argument many times already, but the truth is that XMPP formally speaking is de juro an "XML routing protocol", but both XMPP and Matrix de facto are being used largely as IM protocols. > For better or worse, trying to solve existing problems using new approaches is how things evolve. Since you invented nothing new, you evolve nothing.
- Arathorn 8y ago
  > Recognized by whom? The foundations responsible for the protocols look to be pretty similar to me (both non-profit orgs), and would be equally recognized as such by the general public. Obviously XSF contributed XMPP to the IETF after 10 years or so, and perhaps we'll end up contributing Matrix to IETF or W3C or whoever too if they'll have it. > How on earth is it innovative or new? > Since you invented nothing new, you evolve nothing. sigh - I wonder if the XMPP community would spend less time constantly complaining about Matrix if they understood what it was :/ The innovative bit of Matrix is that it's a replicated database of objects (events), similar to Git, but designed for syncing conversation history around in realtime. The events for a given room get replicated over all the participating nodes. There is no central server responsible for coordinating the room; instead all the participating ones do so equally. It's impossible to communicate with someone on a different node without effectively giving them a lazy-loaded HA replica of the room. Architecturally this is about as opposite of MUC (or MIX or FMUC or DMUC or whatever) as I can think of. It's NOTHING to do with HTTP+JSON versus TCP+XML - Matrix can use whatever transport and encoding floats your boat. For instance, at FOSDEM we showed Matrix running over CoAP+CBOR to try to spell this out: https://fosdem.org/2019/schedule/event/matrix/ https://fosdem.org/2019/schedule/event/matrix/.

SamWhited 8y ago

> Matrix is an entirely different type of technology to IRC or XMPP. It's more similar to NNTP or Git than either IRC or XMPP. What does this have to do with anything? It's used for chat and solves all the same problems. You could easily have done all the same things (including building a system that does syncing like matrix nodes) on top of an existing protocol instead of reinventing the wheel.

Arathorn 8y ago
We seem to have this same dead-end conversation every few months, so indulge me as I try to break the impasse with a story instead. When I was about 13, I worked on a really fun chat system at school called (wait for it) iNFERNO][ (it was the second attempt at a chat system called iNFERNO). It was pretty awesome, and worked like this: the school ran a large network of 68k-based Macs (LCs, Centrises, even a Quadra) networked to a single Apple Workgroup Server, which ran a Filemaker Pro db instance that the school used for its HR and record keeping. As it happened, the DB server was set up such that anyone could create DBs on it, so the school geek community spun up a few to play with. If you've ever used Filemaker, you'll know that it's a visual DB - almost creating Forms as the first-class citizen (a bit like Hypercard) and the fact they're backed by tabular data is almost hidden. Even more excitingly, it even had basic networking so you could run network queries between DB instances - including exchanging arbitrary objects (e.g. images, videos etc), if i remember correctly. So, what we did was to set up a centralised DB (iNFERNO itself) on the server, shared over the network, which stored a bunch of chatroom history and provided a graphical timeline view onto the room when opened up over the network from a Mac (set up to occupy the top 2/3rds of your screen). Meanwhile, and this is the fun bit: we also wrote a DB instance called your "iNFERNO Key", which you stored on a 3.5" floppy disk and could run as a local DB off the disk on any Mac you happened to walk up to. It coughed up a window on the bottom 1/3rd of the screen, which provided your composer prompt. Everyone had their own key, and customised it to their heart's content with different themes, colour schemes, buttons, bot-functionality etc. And it stored their credentials (and we even tried some basic shared-secret e2e crypto) to make logging in trivial - you just put the disk in the drive and clicked the DB (which would in turn spawn the separate main window to view the shared DB timeline). When you sent a message (which could be text, or arbitrary filemaker objects like images, videos etc), Filemaker let you stage the table row locally and then insert it into the shared DB instance, so you ended up with a surprisingly fun and usable server/client chat system, with arbitrary scrollback, multidevice support, file-transfer etc... using a batshit crazy architecture which involved schoolkids running around waving 3.5" disks around and forking each other's "keys" and somewhat unnecessarily authoring messages using a local DB instance when the whole thing could have been done on the serverside DB instead. The whole thing lasted about 3 months, getting increasingly popular until the school went nuts at their Filemaker server being completely overloaded and tragically turned it all off. And whilst I still probably have my Key somewhere, we surely didn't have a backup of the central server itself :( So, my point is: this was a chat system, with many of the features shared by XMPP, Matrix, Slack, Discord etc today. Could we have built it on top of something else? Sure, we could have built it on IRC instead or Talk or some BBS based thing. But instead we chose to experiment with a totally different architecture, which had its own weird trade-offs and benefits, and learned a bunch of stuff along the way. (I still miss the idea of literally synchronising rich graphical objects over the network - it almost felt like Croquet or one of the virtual world things). And so, whilst you're totally right that we could have tried to layer Matrix semantics over the top of XMPP or IMAP or Filemaker(!), we similarly wanted to try a totally different architecture; one without stanzas and message passing; one without all the historical baggage of XMPP; one which only does group conversations; etc. So I'd argue this is how stuff evolves, and sometimes it's good to experiment with building on a new base. And if it doesn't work out; hopefully it at least provided a learning experience for all concerned. The same goes for COI layering chat over IMAP; almost as questionable as layering chat over a networked DB ;). So, let's just get on with building stuff and seeing what works and what doesn't. This isn't a case of re-inventing the wheel for the sake of it, but seeing how well things work if you build on an entirely different set of foundations.
- fock 8y ago
  +1 and arguably the concurrent clients + multiuser thing is something which XMPP did never get around really. There are at least a dozen or so XEPs which noone is implementing (except for Conversations) which make basic functionality a mess. You download any client and get basic 1on1-chat with no missed messages when both parties are online. Everything else depends on, .... whatever. Even major providers needed some years to get around this (look at Whatsapp). So I think it's really not reinventing the wheel if one tries to implement something anew learning from the pasts mistakes (if you are affiliated with riot/matrix: keep up the good work!)
  - jjrh 8y ago
    What do you mean? Unless you're using a very old client like pidgin, this stuff shouldn't be a problem.
    - fock 8y ago
      well, I'm open to client suggestions (and to public servers, where I can try them out too). I was told by Google (tm) that gajim should be one of the most feature-complete clients on the desktop. tried it with conversations on the phone. group messages go into some archive-window (instead of showing up in the chat window like in every over program), sometimes the archive misses them... pictures are a link to the server, so I have to manually download them all. encryption with multiple clients is a mess (even more so than matrix). av is completely missing. of course this are all relatively minor things from a technical standpoint but they add up and together with the thing that a large amount also depends on the server this makes for a very bad user experience (basically it currently means: run your own server and use conversations)...
      - jjrh 8y ago
        > group messages go into some archive-window (instead of showing up in the chat window like in every over program), sometimes the archive misses them... Not sure what that even means. Worth reporting. > pictures are a link to the server, so I have to manually download them all. I think you need to install the image preview plugin. For gajim make sure it's a recent version. Dino-im https://dino.im/ https://dino.im/ is decent. poezio https://poez.io/en/ https://poez.io/en/ if you want a text client. converse.js https://conversejs.org/ https://conversejs.org/ for a web client. Public server wise I don't have any recommendations (but i'm sure others have plenty) other than movim. https://movim.eu/#try https://movim.eu/#try they have a baked in client (and do a whole bunch of other stuff like micro blogging) but once you have a account, there is no reason you can't use any client you want. Encryption with omemo is a issue and usability could be improved (I believe people are working on that).

zinid 8y ago

> i'd argue that the Matrix.org Foundation is just as 'recognized' as the XMPP Standards Foundation :) Recognized by whom? The XSF has standardized their core in IETF. Is there something similar for Matrix.org Foundation? > trying to solve existing problems using new approaches is how things evolve. What new approaches? You're just recreating federated IM network using different wire format. How on earth is it innovative or new? Using HTTP+JSON instead of TCP+XML is something new? Bridging to other IM networks is something innovative? > Matrix is an entirely different type of technology to IRC or XMPP. It's more similar to NNTP or Git than either IRC or XMPP. I've heard this argument many times already, but the truth is that XMPP formally speaking is de juro an "XML routing protocol", but both XMPP and Matrix de facto are being used largely as IM protocols. > For better or worse, trying to solve existing problems using new approaches is how things evolve. Since you invented nothing new, you evolve nothing.

Arathorn 8y ago
> Recognized by whom? The foundations responsible for the protocols look to be pretty similar to me (both non-profit orgs), and would be equally recognized as such by the general public. Obviously XSF contributed XMPP to the IETF after 10 years or so, and perhaps we'll end up contributing Matrix to IETF or W3C or whoever too if they'll have it. > How on earth is it innovative or new? > Since you invented nothing new, you evolve nothing. sigh - I wonder if the XMPP community would spend less time constantly complaining about Matrix if they understood what it was :/ The innovative bit of Matrix is that it's a replicated database of objects (events), similar to Git, but designed for syncing conversation history around in realtime. The events for a given room get replicated over all the participating nodes. There is no central server responsible for coordinating the room; instead all the participating ones do so equally. It's impossible to communicate with someone on a different node without effectively giving them a lazy-loaded HA replica of the room. Architecturally this is about as opposite of MUC (or MIX or FMUC or DMUC or whatever) as I can think of. It's NOTHING to do with HTTP+JSON versus TCP+XML - Matrix can use whatever transport and encoding floats your boat. For instance, at FOSDEM we showed Matrix running over CoAP+CBOR to try to spell this out: https://fosdem.org/2019/schedule/event/matrix/ https://fosdem.org/2019/schedule/event/matrix/.