Live data from Hacker News

Matrix 1.0 – Are We Ready Yet?

matrix.org

161–170 of 208 posts

Re: Matrix 1.0 – Are We Ready Yet?

#161
post #143

Earlier quoted context omitted.

XML is not popular because of JavaScript developers. Coming from .NET, I do not care using JSON or XML, because the APIs System.Xml.Linq, Newtonsoft.Json and the upcoming System.Text.Json are a joy to use. I think the lack of good native representation of XML in JavaScript made it a unwanted choice. Regards SOAP I tend to agree to you. Beyond the Basic profile it was a hassle to interop.

>XML is not popular because of JavaScript developers. This could not be more false. JavaScript is built around the DOM. You can parse XML with DOMParser and query it with the same interfaces that you build your UI with. The X in AJAX is XML. The "good native representation" of XML in JavaScript is the very core data structure that JavaScript was designed to interact with. XML is not popular because it's complex. Esca…

Good arguments but using DOM Api in JavaScript needs many more lines than JSON parsing and access. jQuery made HTML access bearable for a simple reason: DOM sucks :)

Average Joe Dev does not reach the impedance mismatch you mention correctly.

Re: Matrix 1.0 – Are We Ready Yet?

#162
post #156

No. But I mean that in a nice way. Here's why... My understanding (limited, to be fair), is that a large percentage (most?) users have a matrix.org account instead of an account somewhere else. By definition, this is not federation. Certainly riot.im users get that by default. Let's look at a different example - email. What if the inventors of email created email.org and created accounts on it. Everyone would also as…

modular does support custom dns (at no extra charge) - eg webchat.kde.org is hosted on it.

there are a bunch of public servers you can sign up on rather than matrix.org - see https://www.hello-matrix.net/public_servers.php.

our hope is to turn off matrix.org sooner or later (or at least disable signups) to prevent these misconceptions.

Re: Matrix 1.0 – Are We Ready Yet?

#163
post #147

Earlier quoted context omitted.

I'm not sure that the problem is missing manpower on the implementation side - it's more that it's hard to know as a developer which current blend of XEPs is the recommended combination and which might have the most chance of working between a given client & server (and server & client) combo. Things like the XMPP compliance suite XEPs have helped a bit with this, but looking at the XEP list and trying to work out wh…

> I'm not sure that the problem is missing manpower on the implementation side If it isn't, why are there so many red crosses on https://matrix.org/docs/projects/clients-matrix and so many servers that aren't even capable of talking to matrix.org?

> why are there so many red crosses on https://matrix.org/docs/projects/clients-matrix

Because the world is littered with unfinished projects? The key thing being that the authors KNOW very concretely that the project is unfinished, and there is a big red X next to the feature in question.

> so many servers that aren't even capable of talking to matrix.org?

Because we only released the first stable release of our federation API a month ago?

Re: Matrix 1.0 – Are We Ready Yet?

#164
post #153

Earlier quoted context omitted.

Matrix isn't really decentralized. It's federated.

I think a useful way of looking at it is that the rooms are decentralized, i.e. not owned by a single server, but the user accounts are (for now).

> but the user accounts are (for now)

aren't? If so can you explain?

Re: Matrix 1.0 – Are We Ready Yet?

#165
post #156

No. But I mean that in a nice way. Here's why... My understanding (limited, to be fair), is that a large percentage (most?) users have a matrix.org account instead of an account somewhere else. By definition, this is not federation. Certainly riot.im users get that by default. Let's look at a different example - email. What if the inventors of email created email.org and created accounts on it. Everyone would also as…

modular does support custom dns (at no extra charge) - eg webchat.kde.org is hosted on it. there are a bunch of public servers you can sign up on rather than matrix.org - see https://www.hello-matrix.net/public_servers.php . our hope is to turn off matrix.org sooner or later (or at least disable signups) to prevent these misconceptions.

Thank you!

As a side-note, someone should make that link a bit more visible on the matrix.org site.

Re: Matrix 1.0 – Are We Ready Yet?

#166

Earlier quoted context omitted.

I have very same impression. XMPP is basing on XML where parsing is order of magniture more complex than JSON. In lot of ways very similar to SOAP mess where you could not comunicate across different software because each of them supportet different set of SOAP extensions and good luck with communicating with web client.

Sure, XMPP has problems, but ZERO of them comes from using XML. Thinking that using JSON will help solve the real problems any federated protocol would face is very naive and will lead to more than a few unpleasant discoveries down the road.

fwiw, nobody on the Matrix team (or that I know in the community) thinks that JSON is somehow fundamentally superior to XML - it’s just a data encoding. More recently we’ve been using CBOR over JSON for instance. Anyone who claims Matrix is about “using JSON rather than XML” to do the same thing is catastrophically missing the point.

Re: Matrix 1.0 – Are We Ready Yet?

#167
post #43

Earlier quoted context omitted.

The future is now https://medium.com/@RiotChat/the-big-1-0-68fa7c6050be

I don't want to knock the hard work the Riot developers have put into their application, but I just don't understand: why does 'modern' web design seem to require wasting so much white space? Looking at the screenshot on that blog post, the actual chat transcript is somewhere in the middle of the screen (sandwiched between giant sidebars on either side). Compare to irssi (or any other console IRC program), which uses…

Too late to edit, but I confess that TFA refutes what I wrote!

We’ve also made usability improvements pretty much across the board, including making the left and right panels resizable [...]

Re: Matrix 1.0 – Are We Ready Yet?

#168
post #111

Earlier quoted context omitted.

Thanks for your post. I've been wondering about federation distribution in various protocols since seeing similar stats for Mastodon [0]. Having federated protocol where vast majority of users still use one server is sub-optimal IMHO (this is not only for Matrix). [0]: https://rosenzweig.io/blog/the-federation-fallacy.html As for identity server, it was just surprising for me (from user's perspective) that when my fr…

the mobile clients lagged a bit on .well-known support, but it landed over the last few weeks: https://github.com/matrix-org/matrix-ios-sdk/pull/644 and https://github.com/matrix-org/matrix-android-sdk/pull/436 . Hopefully this should improve things a bunch. For 'the federation fallacy' thing: our approach is to first decentralise accounts (so you can transparently move them between servers), at which we can turn off…

Doing the same for XMPP: http://upload.zinid.ru/xep-eax-cir.html

Let's compete.

Re: Matrix 1.0 – Are We Ready Yet?

#170
post #98

I'm not very much into chat apps and protocols, but isn't it possible to just revive XMPP? Ten years ago we used Adium and Pidgin, and federated chat seemed like a solved problem. I understand XMPP with its extensions and use of XML fragments might be complex, but it sounds like matrix or another new protocol isn't easier. In a way, those willing to invest time into F/OSS chat apps have done the best they could with…

The problem of XMPP is just lack of good clients on some platforms, most notably for iOS. For Android there is an excellent Conversations.im client [0] that I've successfully use with my non-technical family and friends. (There is also Quicksy [1] that uses phone numbers for onboarding but it's XMPP all the way down). Conversations doesn't use a lot of battery (anecdata but it's 1% on my phone) and just works. [0]: h…

In case of iOS/macOS - there are: * BeagleIM by Tigase (https://beagle.im/) for macOS * Tigase Messenger for iOS (https://itunes.apple.com/us/app/tigase-messenger/id115351683...)
Post reply on HN