Live data from Hacker News

Synchronous Messaging at Mozilla: The Decision

discourse.mozilla.org

231–240 of 258 posts

Re: Synchronous Messaging at Mozilla: The Decision

#231
post #19

Earlier quoted context omitted.

Native development on OSX and iOS both kind of suck unless you completely embrace objective C and coaca. I think that’s what’s turned so many people off to it. It’s comparatively easy to write complex portable applications with tk (or even just strait win32 and whichever X11 widget toolkit is your favorite.)

> Native development on OSX and iOS both kind of suck unless you completely embrace objective C and coaca. You can try all-Swift development with SwiftUI.

Well yeah that gives you an OS X app and you get to reimplement it completely from scratch for all the other platforms. So it’s exactly the same problem as objective C (except you can at least compile objective C on other platforms you just don’t get the GUI stuff.)

Re: Synchronous Messaging at Mozilla: The Decision

#232
post #118
post #19

Earlier quoted context omitted.

Native development on OSX and iOS both kind of suck unless you completely embrace objective C and coaca. I think that’s what’s turned so many people off to it. It’s comparatively easy to write complex portable applications with tk (or even just strait win32 and whichever X11 widget toolkit is your favorite.)

https://github.com/neilalexander/seaglass looks promising.

That’s exactly what I’m talking about; you can’t reuse code on OSX and more or less have to start from scratch.

Re: Synchronous Messaging at Mozilla: The Decision

#233

Earlier quoted context omitted.

> Obviously they're unlikely to ever come back. I recognize this is a common attitude, but it makes no sense to me. Some software you tried today isn't designed in a way you prefer, so you go back to using something else. Okay. Makes sense. But to declare the whole project forever hopeless as if it can never be improved upon because the snapshot of your first experience with it was negative is truly irrational.

Keep in mind the only reason they tried the software is that I regularly pressured to do so for months, before they finally caved. After all that they quickly come to realize that something simple like adding a new device is a massive pain in the ass. It's not that they declare the whole project as forever hopeless, it's that they invested time and effort into trying it already and it turned out (for them) to be a wa…

The same thing happened to me, but I am thinking of having another go and just discouraging the use of E2EE. (The community I’m thinking of is currently on Slack, so there would be no marginal loss of privacy.) Have you considered that, or is your group already using another E2EE platform that isn’t a massive pain in the ass? I’ve yet to discover one myself.

Re: Synchronous Messaging at Mozilla: The Decision

#234

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…

Disclaimer: I work for Mozilla, and I was quite happy with IRC personally.

The announcement may not mention it, but there were trial instances of a number of messaging apps set up, people could use them and submit feedback, and that feedback was in fact considered as far as I know. Accessibility and safety were not the only criteria at all.

As far as "safety" concerns being overblown... I personally had approximately zero problems with IRC that way, though some of the random spammers who sounded like foul-mouthed 12-year-olds could be annoying at (rare, in my experience) times. But I absolutely have co-workers whose IRC experience was a lot less pleasant. And if moving to a different system lets us get rid of that unpleasantness for them, that is a _very_ strong reason to consider such a move, both on general moral grounds and on purely business-reasons "people who can get their work done sanely get more work done" efficiency grounds.

Note that we're not talking about safety from debate or opposing viewpoints or whatnot. We're talking about people being able to discuss a bugfix with others without being constantly spammed with invective and threats in the process. _That_ is what "safety" means in this context.

Re: Synchronous Messaging at Mozilla: The Decision

#235
post #233

Earlier quoted context omitted.

Keep in mind the only reason they tried the software is that I regularly pressured to do so for months, before they finally caved. After all that they quickly come to realize that something simple like adding a new device is a massive pain in the ass. It's not that they declare the whole project as forever hopeless, it's that they invested time and effort into trying it already and it turned out (for them) to be a wa…

The same thing happened to me, but I am thinking of having another go and just discouraging the use of E2EE. (The community I’m thinking of is currently on Slack, so there would be no marginal loss of privacy.) Have you considered that, or is your group already using another E2EE platform that isn’t a massive pain in the ass? I’ve yet to discover one myself.

They all use Signal, with varying degrees of dissatisfaction. I'm the only one who doesn't have a Signal account.

Re: Synchronous Messaging at Mozilla: The Decision

#236
post #154

Earlier quoted context omitted.

I still find it inappropriate for a FOSS project to promote closed non federated communication tools. Hopefully they won't be stuck with Discord because "we already switched to it".

I think they are just being pragmatic. No one, not even RMS, ever felt that open source needed to be open source from bottom to top, just the final product. You have to be pragmatic in this life. We can't wait for open source processors running on open source hardware on and open source OS compiled on an open source compiler before something gets released. I find it entirely appropriate for them to be pragmatic and u…

"not even RMS". You underestimate RMS.

Re: Synchronous Messaging at Mozilla: The Decision

#237
post #193
post #37

Earlier quoted context omitted.

Matrix can bridge in IRC, Slack, Gitter and a few other protocols very nicely, it reminds me of Pidgin but with much better UX.

I haven't managed to properly use Matrix myself, but I am part of a number of Gitter rooms that includes people using the Matrix bridge. I certainly wouldn't call that bridge "nice": all their messages are posted by a single user called matrixbot, that simply prefixes it message by their Matrix username in backticks. I'm not sure if the people in the room who aren't aware of Matrix understand that that's what's going…

Maybe a limitation of the gitter api? Better than nothing, but improvement welcome

Re: Synchronous Messaging at Mozilla: The Decision

#238
post #221

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/

Matrix has bridges to many different chat systems

Re: Synchronous Messaging at Mozilla: The Decision

#239

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…

AFAIK it is planned but not done

Re: Synchronous Messaging at Mozilla: The Decision

#240
post #239

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…

AFAIK it is planned but not done

https://github.com/vector-im/riot-web/issues/5857 or https://github.com/matrix-org/synapse/issues/4762
Post reply on HN