Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Matrix 1.0 – Are We Ready Yet?

matrix.org

Post reply on HN
Print view View original

131–140 of 208 posts

Re: Matrix 1.0 – Are We Ready Yet?

#131

Post by Arathorn »

cloogshicer wrote: post #92
est wrote: post #35

I sincerely hope someone took the Telegram client code and add Matrix protocol to it. Really, Telegram client is open source and the app is more usable than any other bloatware on the market.

Agreed, the Telegram desktop client is super fast. EDIT: Someone seems to already have done this: https://matrix.org/docs/projects/client/nheko.html

I think nheko is a clone of the telegram UI rather a fork of it.

I agree it'd be awesome if someone took the actual Telegram FOSS clients and ripped out the TG backend and replaced it with Matrix (a bit like the Delta.chat folks did, but replacing with email)

Re: Matrix 1.0 – Are We Ready Yet?

#133

Post by ubercow13 »

kkarakk wrote: post #86
ubercow13 wrote: post #72

Earlier quoted context omitted.

What if your window doesn't span the entire screen? It's a frustrating and common flaw in so many modern websites and apps that they simply do not work unless the app is fullscreen on a widescreen monitor. For example Discord is borderline unusable if it is one of two windows side-by-side on my laptop, and completely unusable if you have three. This can't even be an unusual case for people on UNIX derivatives using t…

Discord isn't meant to be used side by side,it's default usecase is joining a channel and continuously talking while doing something else(mostly gaming). not being able to snap the window seems to be a conscious choice on their part

I assure you there are lots of people who don't use it that way. It probably depends on what circle you end up in on it. There are text-based communities on there related to all sorts of topics. The Rust community was even considering using it as a default communication channel at one point I believe.

Re: Matrix 1.0 – Are We Ready Yet?

#134

Post by techntoke »

Arathorn wrote: post #21
fro0116 wrote: post #8

I had a pretty positive view of Matrix until I came across this post and the follow up responses from the developer behind an unofficial Matrix server implementation: https://news.ycombinator.com/item?id=19365968 I'd say tread carefully given their apparent hostility towards competing server implementations, which is literally the only thing that makes the protocol meaningfully "federated" to begin with. This part in…

I'm the project lead for Matrix (and CEO of New Vector, the company which hires most of the core Matrix team) and can try to clarify this. 1. We don't have any hostility to alternative server implementations; it would be utterly idiotic to sabotage the project by doing so. Instead, we promote them, even when they're written by people who for whatever reason have issues with the project. For instance, if you look at h…

I find it strange to suggest that he is using sockpuppet accounts on HN without any proof. You may as well be using sockpuppet accounts to promote Matrix. It is also really suspicious to attack someone that has spent a significant amount of time on your project.

Re: Matrix 1.0 – Are We Ready Yet?

#136

Post by emias »

Arathorn wrote: post #80
hannob wrote: post #77

Earlier quoted context omitted.

Matrix is the perfect example of xkcd 927 - https://xkcd.com/927/ They built something like XMPP, just a bit different. What they got is more fragmentation in the space of free messaging. None of the justifications they have how their approach is different justifies the costs of additional fragmentation they create. This is super frustrating, people don't seem to have an understanding what the costs of incompatibilit…

I'd counter and suggest that the super frustrating thing is XMPP zealots saying "oh my god how dare you try to create a different protocol". With this mentality, nothing would evolve and we'd be stuck on svn rather than git... To reiterate once again, the things which Matrix tries to do differently to XMPP include: * Be a replicated conversation database for realtime conversations, more like usenet (NNTP) if anything…

> Have a single monolithic versioned protocol rather than a finely granular cloud of XEPs which may or may not be compatible or best practices or implemented at any given point.

I totally get where you came from, the fragmentation within the XMPP universe is annoying. The problem is that a monolithic spec doesn't solve this issue at all. It's not like code magically updates itself when you update a monolithic spec. The problem is missing manpower on the implementation side, and ditching modularity from the spec just makes it harder to cope with this in graceful ways.

Re: Matrix 1.0 – Are We Ready Yet?

#137

Post by severine »

Arathorn wrote: post #67
dboreham wrote: post #42

Earlier quoted context omitted.

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

In Matrix the conversations really are decentralised, not federated, over the servers - they are replicated over the nodes just as you would with git or a blockchain. Meanwhile we’re actively working on running servers clientside, at which point it becomes fully p2p as well as decentralised if you want that.

> we’re actively working on running servers clientside, at which point it becomes fully p2p as well as decentralised if you want that.

Where can I read more about this?

Re: Matrix 1.0 – Are We Ready Yet?

#139

Post by DygFiul »

OK, you want XMPP. But without the many XEPs, something with a monolithic specification. And you like to use the latest trendy hipster stuff, like JSON over HTTP instead of XML. Then you get:

Monolithic, Awefully Trendy Re-Implementation of XMPP (M.A.T.R.I.X.)

Which is also a dedication to XMPP, which has been invented in 1999, the year of the Matrix film.

Re: Matrix 1.0 – Are We Ready Yet?

#140

Post by Arathorn »

emias wrote: post #136
Arathorn wrote: post #80

Earlier quoted context omitted.

I'd counter and suggest that the super frustrating thing is XMPP zealots saying "oh my god how dare you try to create a different protocol". With this mentality, nothing would evolve and we'd be stuck on svn rather than git... To reiterate once again, the things which Matrix tries to do differently to XMPP include: * Be a replicated conversation database for realtime conversations, more like usenet (NNTP) if anything…

> Have a single monolithic versioned protocol rather than a finely granular cloud of XEPs which may or may not be compatible or best practices or implemented at any given point. I totally get where you came from, the fragmentation within the XMPP universe is annoying. The problem is that a monolithic spec doesn't solve this issue at all . It's not like code magically updates itself when you update a monolithic spec.…

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 which XEPs you should be using on a given day is still daunting - as well as trying to track which clients are most likely to be supporting them.

The idea on Matrix is that you say "Hi, I talk Matrix CS API 0.4" and be done with it - and you end up with much more social pressure to keep up to date with the current latest spec, because otherwise you are simply falling behind (rather than happening to chose not to implement some XEPs).

It boils down to a question of governance & social dynamics rather than anything related to writing code (magically or otherwise).

Post reply on HN