Synchronous Messaging at Mozilla: The Decision • Hacker News Board

Re: Synchronous Messaging at Mozilla: The Decision

#221

Post by pabs3 » Fri, Dec 20, 2019, 1:14 AM UTC

bloopernova wrote: post #177

Has anyone had experience with both Matrix and Mattermost? What are the main differences between the two? Apropos of nothing, currently I am running: * Signal * Wife * Family * Google Hangouts (web) * Friends and ex-coworkers * Slack * Vendor A * Vendor B * Team C * Team D * Keybase * Some friends * SMS * My Stepdaughter * Skype * Coworkers too stubborn to open Mattermost or change what they do * Mattermost * Coworke…

I really wish Telepathy took off, then you could have one single app that speaks each of those protocols and talks to the relevant servers.

https://telepathy.freedesktop.org/

Re: Synchronous Messaging at Mozilla: The Decision

#222

Post by [deleted] » Fri, Dec 20, 2019, 1:18 AM UTC

orthecreedence wrote: post #174

chrisseaton wrote: post #150

Earlier quoted context omitted.

Is lots of half finished clients rather than one finished client an advantage?

Riot is pretty finished. So you have one fully-baked client, and a bunch of others to choose from if you don't like Riot. Compare that to Slack, which only has one client, and it gets worse seemingly every day (somehow?).

[deleted]

Re: Synchronous Messaging at Mozilla: The Decision

#223

Post by mwcampbell » Fri, Dec 20, 2019, 1:31 AM UTC

chrisseaton wrote: post #150

dvdgsng wrote: post #144

Earlier quoted context omitted.

Wait, are we complaining about one of the key advantages of open source now?

Is lots of half finished clients rather than one finished client an advantage?

Maybe if the one "finished" client doesn't work well for some users, e.g. is cumbersome to use with a screen reader, but there's a "half-finished" client that works well for them.

Re: Synchronous Messaging at Mozilla: The Decision

#224

Post by mwcampbell » Fri, Dec 20, 2019, 1:52 AM UTC

cowedbyprgrssvs wrote: post #182

The announcement mentions only two features: safety and accessibility, but places no emphasis on the technical merits of the choice for the majority of users. That is disappointingly irrational for a technology organization. I don't feel comfortable with the strong emphasis on "progressive" concerns that mozilla (and the rust community) have. It's not inclusive: I have normal liberal views (I'm from a European countr…

> technical suitability for the 95% of modally-abled users is still an important consideration.

Are you saying that we should give more advantages to people who already have the advantage of having no significant disability, while adding difficulty for people who already have extra difficulties (or at best making only token efforts toward accessibility)? That seems unreasonable to me.

Fortunately, with an open system like Matrix, everyone can have a client that works well for them.

Re: Synchronous Messaging at Mozilla: The Decision

#225

Post by wildfire » Fri, Dec 20, 2019, 2:16 AM UTC

steveklabnik wrote: post #215

hu3 wrote: post #211

Earlier quoted context omitted.

Every fulltime Rust developer is paid by Mozilla. Saying Rust development isn't owned by Mozilla is more laughable than saying Go development isn't owned by Google.

That’s not how governance works.

Governance doesn't preclude the organisation which pays for the developers to have them do something else.

Goverance: We should complete the async work before we do X

Pay master: We need X done. Do the async work later.

i.e. the person who is paying the money gets to set the priority.

Re: Synchronous Messaging at Mozilla: The Decision

#226

Post by Quiark » Fri, Dec 20, 2019, 2:35 AM UTC

tsimionescu wrote: post #183

anoncake wrote: post #126

Earlier quoted context omitted.

This is not at all the same thing. Programs written in C aren't inherently low-quality, everything abusing the web stack as an application platform – including Electron – is.

If you had said low performance, you would have had a point. Even then, someone else could say that programs based on Electron at least aren't inherently insecure, like programs written in C are.

Don't get that optimistic about Electron apps security

Re: Synchronous Messaging at Mozilla: The Decision

#227

Post by steveklabnik » Fri, Dec 20, 2019, 2:37 AM UTC

wildfire wrote: post #225

steveklabnik wrote: post #215

Earlier quoted context omitted.

That’s not how governance works.

Governance doesn't preclude the organisation which pays for the developers to have them do something else. Goverance: We should complete the async work before we do X Pay master: We need X done. Do the async work later. i.e. the person who is paying the money gets to set the priority.

“We need x done” can’t be done at all until it’s approved by those who govern the project.

Actual example of this: years ago, the Servo team really would have liked a form of inheritance, to help with DOM stuff. We thought it wouldn’t be right for the language. Rust still doesn’t have inheritance today.

This argument is also predicated on the idea that full time devs get more done than part time ones do. That’s true in a one on one comparison, but there are far more part time ones, so collectively they do way more work.

Re: Synchronous Messaging at Mozilla: The Decision

#228

Post by bsder » Fri, Dec 20, 2019, 3:14 AM UTC

jokoon wrote: post #145

I'm curious, what's wrong with IRC? Is it too old? Too difficult to monitor and moderate? Too easy to spam? I don't understand. I've never really understood why mozilla chose their own servers and not freenode. I've never really grasped the whole history of enet vs freenode either.

> I'm curious, what's wrong with IRC?

It seems that the most significant complaint is bad mobile experience.

Re: Synchronous Messaging at Mozilla: The Decision

#229

Post by mcny » Fri, Dec 20, 2019, 3:19 AM UTC

kibwen wrote: post #153

jeltz wrote: post #148

Earlier quoted context omitted.

But Cargo supports having multiple crates in the same git repo. Many projects do this like regex (regex and regex-syntax are in the same repo) and openssl (openssl, openssl-sys, openssl-errors). Maybe I am missing something but it seems very easy to handle multiple closely related crates in the same repo.

What makes this possible is Cargo's "workspace" feature, which is relatively new enough that it's not hard to imagine that some older projects may simply predate it.

Would something like git subtree help here? Allow people to continue working with their individual repos but present a unified view for outsiders to follow along? We could automate this, right?

Re: Synchronous Messaging at Mozilla: The Decision

#230

Post by sandGorgon » Fri, Dec 20, 2019, 4:05 AM UTC

Are you guys planning "private communities" usecases ?

When I last evaluated Riot, it was vehemently public...so Slack/Mattermost like usecases were very hard to do.

Ideally a private community should be possible, where users invited to that community have access to all channels. however within the community, I should have private channels restricted to only few invited users.

I was told that the only possible way to do this was make all channels of a community private ..and when adding a new user, you should explicitly invite to every single one of the channels. This is not viable for an org.

I really hope this has changed.