zinid

> go-ipfs with a few pinned files taking more than 5GB

Yeah, I don't understand the hype around IPFS when it performs so badly. After reporting the issue and having a conversation with the devs I had an impression that they are just dilettantes.

> This problem doesn't exist for JSON, because pretty much every language directly supports arrays, objects/maps and primitives

No, JSON will not map directly to a language with advanced type system (with tuples, variants, etc). Even in Elm it's recommended to write a decoder to convert incoming JSON into an internal structure. So in fact the mapping is very poor. And I see no difference in this regard: both XML and JSON is crap.

> In my experience, there's virtually no overlap between the two groups, and therefore no fragmentation

Right, so there are two groups of developers working on different IM protocols. If this is not fragmentation (of developers) then what is it?

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

Let's compete.

> it'll need institutional buy-in from corporations and existing tech companies. Hope there is a plan for that type of out-reach.

"Failing to plan is planning to fail".

I don't see why would corporations and existing tech companies be interested in yet another IM protocol they cannot control, especially in the era of total silos and FAANGs. Doesn't sound like a solid plan to me at all.

And admins will update their deployments instantly? Because of monolithic core? Interesting...

> You can see our governance model at https://github.com/matrix-org/matrix-doc/blob/matthew/msc177.... and see that we do everything we can to ensure that the wider community can contribute to the spec and steer it in the right direction... And fwiw, we'd be perfectly happy to contribute the spec to IETF or W3C or whoever once it's relatively stable, just like XMPP did.

I'm not a lawyer to read such documents. Just "contribute" your core to the IETF, prove me wrong.

> Rather than burning all this energy spreading FUD about Matrix, perhaps it might be better spent improving XMPP? :/

Yeah, didn't I say above about such kind of arguments?

> is still a half-locked platform... but that is still not a standards body

Exactly. That's why I always stress the importance of the IETF. The whole point of the IETF is that you cooperate with people, deal with opposite opinions, accept criticism, come to agreement, develop a compromise and produce a high quality absurdly documented standard. In Matrix bubble (and any others, see cryptocurrency or p2p community for example) they are the only one who makes the decision. They don't care on other opinions. If you disagree with them you're asked to stop "fighting", "focus on interaction", "understand their goals" and other meaningless stuff like "let the best standard wins" (when in reality the whole point of the standard is to cooperate). Formally speaking they try to substitute a "standard document" with an "open document" and people kinda swallow this because they don't see the difference.

> I'm not sure about that. If the main matrix server disappeared today that'd be problematic

This ^^ Currently a large amount of users (I'm told around a half, but I'm not sure) have matrix.org as their home server. So Matrix is effectively building a power-law network with all its drawbacks: when the "power node" of the network goes down the whole network falls apart.

> It's quite subjective, but my view is Matrix is what XMPP would like if it was written today.

That's indeed a subjective view.

> The main advantages are it is using JSON instead of XML, and HTTP instead of custom protocols

The Matrix dev said a day ago that "It's NOTHING to do with HTTP+JSON": https://news.ycombinator.com/item?id=19217412

Also, what custom protocol are you talking about? XMPP works on top of TCP/TLS (or Websocket). Those are the IETF standards. In fact XMPP doesn't require an additional layer of HTTP at all.

> with lightweight mobile clients

Where are they? Anything even remotely comparable battery-wise with Conversations (an XMPP client)?

Not to mention that Matrix has a terrible server implementation which requires several GB of RAM just to join matrix.org room.

> It also has a lot built into the core protocol, where as to get XMPP to do anything useful you will need to use a lot of extensions (and ensure the server and all clients support them).

I fail to see how having a monolith core versus splitted specs has to do anything with code written to support that. Of course, initially every implementation will strive to implement full core (that was in XMPP in 2000s), but when the core evolves you have absolutely no guarantee that every developer will implement all new parts of the core. How is that addressed in Matrix?

> 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.

> Simply that quotas work and encouragement doesn't

I wonder what other outcome one might expect from quotas.

And it consumed 8.7Gb :) I wonder if the editor itself is of the same quality :/

So I tried to install it and got fancy error:

$ ./install.tcl

...skipped...

Copying data to lib/tke/data... done.

Copying doc to lib/tke/doc... done.

Copying lib to lib/tke/lib... error!

  error copying "lib" to "lib/tke/lib": "lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/...skipped.../tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/doc/md/TKE Developer Guide/Plugin Development/Safe (Untrusted) Interpreter Description.md": file name too long

Well, dunno, in my opinion both are equally obscure. I personally don't like "dot notation" and that's one of the reason I don't like Rust. The main problem I see with dot notation is the Pigeon hole problem: why sometimes you write x(y) and sometimes y.x()? While the functions in the above example are trivial, there exist not so obvious cases.

> From my perspective it’s one of the very few general purpose languages (along with erlang)

Maybe I'm missing something, but since when Erlang is a general purpose language? Erlang was designed for a quite narrow niche and feels very well there, but Go... well, honestly, I don't understand what Go was designed for.

> age of JSON

Yeah, modern and shiny JSON. IT is now a subdivision of the fashion industry. Suck it up ;)