Very nice, GJ! Matrix is the FURURE. Now the work begins converting all slackers...
Hail the furure!
Gitter now speaks Matrix
91–100 of 122 posts
Re: Gitter now speaks Matrix
#92Earlier quoted context omitted.
It's totally different because it is a message syncing http+json API and totally not a messaging and presence protocol based on XML. /joke It is interesting because Matrix has money thus full-time developers, marketing, exposure, and time to defend their work to the depth of the deepest reddit thread. (The Element page on F-Droid reads "Element is able to do all this because it operates on Matrix - the standard for o…
I love that all 3 of the snarky points here are illfounded :D Yes, Matrix is a conversation history syncing protocol, and XMPP is a message-passing protocol. They genuinely are fundamentally different. It's a bit like the difference between SVG and Canvas. Sure, you can use both to draw pretty vector artwork. But one's an object graph, and the other's immediate mode. In terms of Matrix having money: yup, it's true th…
> However, the whole "marketing, exposure and time to defend their work to the depth of the deepest reddit thread" trope is hilarious, given Matrix's marketing department is... me, the project lead?
At this point you've probably realized that it's still immensely more than what XMPP-the-protocol has ever done: a voice that is present on all fronts to talk about it and spread the word about our Savior :)
When you want to "get into" XMPP you have to choose between NN clients, and pick a proper provider among the YY that can give you an xmpp address. When you're starting with Matrix there's a server that is "right" for beginners, with a client that is the flagship so every standard feature can be expected to be there and work, there's a company that funds its development...
You might be the only person in Matrix's marketing departement, but I guess it works this way because the way the ecosystem is today, one person is enough !
Re: Gitter now speaks Matrix
#93Earlier quoted context omitted.
Part of me wonders if this is a fatal flaw in the very concept of distributed systems. It seems to me that as soon as a protocol or technology loses its single authority (multiple companies write implementations) it becomes feature frozen since it would be impossible for multiple companies to come to an agreement on what the new features should be or getting them all to implement them. If matrix actually does succeed…
it doesn’t have to be a fatal flaw. you “just” have to layer the protocol to give decent abstractions to allow diversity on top of each layer, so as each layer matures you just keep innovating upwards - like the ethernet/ip/tcp/http stack for instance.
The problem I see is every time you drop an extra layer of innovation, you fragment the final product.
For example, Apple adds person to person payments in imessage and it suddenly just works for every single imessage user. If someone did that as a feature on top of matrix you now have a situation where some clients support it and some don't so the feature never really gets used as its too unreliable. Maybe over time the feature rolls out to more clients but there will always be some devs who think "No I don't like this feature, I won't ever add it"
I guess things are a little simpler here since it might be possible to implement new features without server changes as they may just work on top of the standard matrix spec.
Re: Gitter now speaks Matrix
#94Earlier quoted context omitted.
XMPP is anything but dead yet. There were a lot of XEPs added and updated in recent years and it turned into a modern protocol being able to provide all features you could expect from a modern messaging service. It's just that you need a client and server that supports those features. Daniel Gultsch has written an Android client[1], that's as good as it can be. He also offers a maintained XMPP server [2] providing th…
Needing a client that supports those features seems like a big ask, though. You're right that Conversations is about as good as an XMPP client can be, and it's a joy to use... but it's one of very few. Among other things, my server has message archiving configured for MUCs, but Conversations is the only client I've ever been able to get to sync that history locally. That's something I just don't ever have to worry ab…
How many different full-featured Matrix clients do you know? And what about lean ones that don’t come in a huge Electron package?
Also, Gajim has support for MAM and can sync everything locally. I believe Monal has it, too.
Re: Gitter now speaks Matrix
#95Earlier quoted context omitted.
it doesn’t have to be a fatal flaw. you “just” have to layer the protocol to give decent abstractions to allow diversity on top of each layer, so as each layer matures you just keep innovating upwards - like the ethernet/ip/tcp/http stack for instance.
The problem I see is every time you drop an extra layer of innovation, you fragment the final product. For example, Apple adds person to person payments in imessage and it suddenly just works for every single imessage user. If someone did that as a feature on top of matrix you now have a situation where some clients support it and some don't so the feature never really gets used as its too unreliable. Maybe over time…
This is a great example. Matrix has the concept of widgets which let you embed little webapps, which can be used as a compatibility layer for stuff like payments. For instance video conferencing is done in Matrix as a widget (Jitsi) for clients who just support widgets... but clients with native jitsi support (Element iOS and Android) integrate it natively rather than using a widget.
Re: Gitter now speaks Matrix
#96Earlier quoted context omitted.
Yup. Can't wait for someone to implement a Matrix-powered Disqus clone!
Wow, it would be really, really interesting for a blog to offer a Matrix room as a "comment section". If you didn't care about threading, you could probably do something like that even today.
That can definitely be done today: just point a link to a public matrix room...well, the participants would need an account associated to a homeserver first in order to interact...but that's no different - conceptually - than needing to have a disqus account. The benefit of course is that their account can be associated to their __own__ homeserver! In fact, i do this already on my website; though for general contact (like a poorman's contact form), rather than a comment section for blog posts - but the approach works for either perspective.
Re: Gitter now speaks Matrix
#97Earlier quoted context omitted.
Needing a client that supports those features seems like a big ask, though. You're right that Conversations is about as good as an XMPP client can be, and it's a joy to use... but it's one of very few. Among other things, my server has message archiving configured for MUCs, but Conversations is the only client I've ever been able to get to sync that history locally. That's something I just don't ever have to worry ab…
How many different full-featured Matrix clients do you know? And what about lean ones that don’t come in a huge Electron package? Also, Gajim has support for MAM and can sync everything locally. I believe Monal has it, too.
Also not many, but they all get history syncing down. They have to, it's at the core of the protocol. (And that aside, at least Element is available on just about every platform.)
Yes, I've heard that Gajim and Monal support it. I'm running both of them right now; Gajim doesn't appear to be fetching history from the server for the MUC I'm looking at in either the chat or history windows, Monal seems to attempt to but shows a progress spinner indefinitely. Conversations successfully loads history from the server; I can scroll back to well before I got this phone so I know it's not just local.
Re: Gitter now speaks Matrix
#98Earlier quoted context omitted.
Jabber needed reinventing. XMPP grew and thrived in the early 2000s and died as every participant fragmented off to spin up a proprietary walled garden replacement. You then need something better than XMPP to fight back against that partitioning of the messaging space because XMPP implementations became too fragmented in feature compatibility to reliably compete.
XMPP is anything but dead yet. There were a lot of XEPs added and updated in recent years and it turned into a modern protocol being able to provide all features you could expect from a modern messaging service. It's just that you need a client and server that supports those features. Daniel Gultsch has written an Android client[1], that's as good as it can be. He also offers a maintained XMPP server [2] providing th…
I spent a long time trying to get the following to all work:
1. Store and forward 2. e2e encryption 3. Messages received on multiple clients at the same time, with clients being able to reconnect and pick up the complete conversation history.
In theory, all possible.
In reality, none of the clients I tried supported the same combo of XMPP plugins and encryption methods.
Oh, and I need clients that work on MacOS, Windows, and Android.
I am using conversations legacy on Android right now because that works with how ejabberd is setup on my machine, and how ejabberd is setup works with the clients other people I want to talk to are using.
I gave up using XMPP on a laptop since I'd get encrypted messages with the wrong key sent to other devices except whichever one I'd used most recently to send a message with.
I never did manage to set sending images working at faster than ~2KB/s.
It is like I am back in 1996 and using AOL IM, but worse.
Re: Gitter now speaks Matrix
#99This is great news! Congrats to the matrix (and element) and gitter teams!!
Re: Gitter now speaks Matrix
#100Earlier quoted context omitted.
I like threads a lot in the way we use it. With 60+ people in one channel, being able to ask a question and get answers in the thread, while not spamming the channel with replies and potentially interweaving multiple question & answer "threads" is really useful.
Threads in Slack are useful but the implementation is pretty bad. For example you don't see new responses in a visible thread until you click the button for more messages. It makes them really frustrating to use. Slack does a lot of things really well which makes the pain of using threads even worse.
I also wish there wasn't 'sharing', or at least not to the same channel, so that there's one clear way for the 'continue earlier topic' use case.
Having said that, there's also 'reply to thread and also share to channel', making it even worse. I think that one's the closest Slack has to fixing threading's problems though - if you're aware of it being a potential issue, you can at least highlight it.
It'd be good if there were an 'active thread(s)' thing that appeared on the right side or something (at the bottom of what is the the thread panel when one's open, I'm imagining though. Easy to ignore, but when you're checking if there's new messages in your main channel you'd also see if there were new thread activity.