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

Synchronous Messaging at Mozilla: The Decision

discourse.mozilla.org

Post reply on HN
Print view View original

181–190 of 258 posts

Re: Synchronous Messaging at Mozilla: The Decision

#181

Post by uhoreg »

boring_twenties wrote: post #172
Arathorn wrote: post #161

Earlier quoted context omitted.

1a/1b and 2 is where all our work is going currently. We're trying to get E2E on by default in Jan, and likewise exit beta for RiotX/Android around the same time. We're going as fast as we can. 3: Matrix.org homeserver performance should be absolutely fine now. Delays when doing things like joining big rooms are unrelated to the hardware, but perf optimisations we need to do to synapse in general. They're on the rada…

After spending several months convincing a few friends to use Riot, the ongoing fiasco with E2E has caused all of them to leave within a couple of days. Obviously they're unlikely to ever come back. It's a real shame. These are technical people who don't particularly mind verifying a key by hand. In fact I personally even prefer it. The problem is not only that certain things are not done automatically, but that the…

> E.g., I have one device 'foo' which you already trust. I add a new device 'bar'. Why on earth would you want to verify its key manually when I could just send you the new key from 'foo' which you already trust?

This particular issue is being worked on right now in Riot, and should be fixed early in the new year.

Re: Synchronous Messaging at Mozilla: The Decision

#182

Post by cowedbyprgrssvs »

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 country and under 40) and I don't think I'd feel comfortable working for one of those organizations because I suspect the progressives there would be angry or offended with my reluctance to embrace the identity politics dogma. I didn't even feel comfortable posting this under my usual account, such is the atmosphere.

Accessibility is clearly important. But "safety" concerns have become overblown: reasonable concerns have become polluted by the politics of the "safe space" contingent, and the sorts of people that are closing down legitimate debate in the name of progressive/identity politics. And technical suitability for the 95% of modally-abled users is still an important consideration.

Re: Synchronous Messaging at Mozilla: The Decision

#183

Post by tsimionescu »

anoncake wrote: post #126
w354kjhllkj wrote: post #63

Earlier quoted context omitted.

You answered your own question. You can write a pretty and functional Electron app in a weekend. To implement the same level of functionality and prettiness in a native app toolkit like Qt is at least a month of work. It's the same story as Python versus C, or C versus Assembly. When C was introduced, the old-timers had the same complains like we do today: why would you program in such a slow and inefficient language…

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.

Re: Synchronous Messaging at Mozilla: The Decision

#184

Post by boring_twenties »

uhoreg wrote: post #181
boring_twenties wrote: post #172

Earlier quoted context omitted.

After spending several months convincing a few friends to use Riot, the ongoing fiasco with E2E has caused all of them to leave within a couple of days. Obviously they're unlikely to ever come back. It's a real shame. These are technical people who don't particularly mind verifying a key by hand. In fact I personally even prefer it. The problem is not only that certain things are not done automatically, but that the…

> E.g., I have one device 'foo' which you already trust. I add a new device 'bar'. Why on earth would you want to verify its key manually when I could just send you the new key from 'foo' which you already trust? This particular issue is being worked on right now in Riot, and should be fixed early in the new year.

That is awesome, but any thoughts on why I cannot easily view the keys of my other devices in the UI?

If I could then this would be a minor inconvenience at best, I'd just copy/paste the key from the already-trusted device.

Re: Synchronous Messaging at Mozilla: The Decision

#185

Post by kingbirdy »

kibwen wrote: post #128
CiPHPerCoder wrote: post #125

Earlier quoted context omitted.

I love the name of your podcast.

Thanks! Also, while we're here, let me advertise that this is not just "my" podcast, it's a community-based podcast that accepts audio files from anyone who wants to make any Rust-related podcast content but who doesn't want to go through the trouble of setting up a website, file hosting solution, podcast index integration, and so on. Contributions accepted. :) https://github.com/rustacean-station/rustacean-station.o…

What a cool concept. Have you had many episodes contributed so far?

Re: Synchronous Messaging at Mozilla: The Decision

#186

Post by lousken »

Arathorn wrote: post #161
lousken wrote: post #160

So after testing matrix and riot with friends for a couple of months, there're still a ton of work to be done. We all used the most common setup - matrix.org homeserver, riot and riotX as apps. (Also please don't point me to dev version, I am only considering what's in stable.) Random stuff not in particular order: 1a) e2e is a choice that affects experience in riot, a lot - you can't use search, you don't see recent…

1a/1b and 2 is where all our work is going currently. We're trying to get E2E on by default in Jan, and likewise exit beta for RiotX/Android around the same time. We're going as fast as we can. 3: Matrix.org homeserver performance should be absolutely fine now. Delays when doing things like joining big rooms are unrelated to the hardware, but perf optimisations we need to do to synapse in general. They're on the rada…

ad 1a - E2E by default - meaning you'll flip the switch once there's a feature parity with non encypted rooms in riot?

ad 3 - from my testing it's fine for about 98% of the time, but sometimes it takes ~3-8seconds to send a message (sitting on 300 or 500Mbps wired connection), in e2e direct message room

ad 4 - @ copy entire message - interesting, i needed it just recenly so i went into the submenu and there's show source, show decrypted source (which is cool but maybe something that should probably be enabled in via a toggle in the options menu) and quote but no message copy (and using quote messes up markdown formatting...)

ad many people asking - i totally understand that, however, this could be used as a roadmap for shipping features. And since I don't write code (read javascript) I am trying to contribute with testing/reporting bugs (so although not obvious from my OP, my testing continues as is suffering of my friends ;) )

Re: Synchronous Messaging at Mozilla: The Decision

#187

Post by jlarocco »

w354kjhllkj wrote: post #63
rtpg wrote: post #12

Earlier quoted context omitted.

Seriously, I feel like it’s such an indictment on native app tool development that we have a bazillion new electron apps written by ppl all the time for weekend projects yet almost no one spitting out native apps to interface with services. It’s clearly in demand (if a bit of a niche kind of demand)

You answered your own question. You can write a pretty and functional Electron app in a weekend. To implement the same level of functionality and prettiness in a native app toolkit like Qt is at least a month of work. It's the same story as Python versus C, or C versus Assembly. When C was introduced, the old-timers had the same complains like we do today: why would you program in such a slow and inefficient language…

> To implement the same level of functionality and prettiness in a native app toolkit like Qt is at least a month of work.

That's really only true for web developers trying to make native apps, and only because they're used to the mess that is web development.

It's a piece of cake to build a small app in Qt with C++, and it's even easier using Python or Common Lisp or one of the other language bindings.

Like everything, it depends on each developer's experience which one is easier for them.

Re: Synchronous Messaging at Mozilla: The Decision

#188

Post by shmerl »

stjohnswarts wrote: post #173
shmerl wrote: 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…

Personally, I see no problem with using Matrix for pragmatism reasons included. Your argument could make sense, if good quality FOSS IMs weren't an option. But they are. So I see no reason to turn to Discord and will not going to use it myself.

Re: Synchronous Messaging at Mozilla: The Decision

#189

Post by iudqnolq »

asymmetric wrote: post #135
iudqnolq wrote: post #57

Earlier quoted context omitted.

FYI #rust-beginners is on discord, but many of the teams have transitioned to Zulip because it has threads. I'd love if Zulip was OSS, but at least it's a highly innovative company that's improved a lot on the UX of IRC (far beyond not needing to setup a bouncer). The mismatch between Discord's targeted audience of gamers can get funny at times. One rust dev has had their status we to "playing systemd" for days. Edit…

Where’s the other thread with Rob Pike?

There isn't one, because ... I'm not even sure what I was thinking, except that I probably should have gotten a few more hours of sleep last night.

Maybe I was thinking about this comment by someone else when I wrote that???: https://news.ycombinator.com/user?id=kibwen

Re: Synchronous Messaging at Mozilla: The Decision

#190

Post by MayeulC »

Arathorn wrote: post #85
rtpg wrote: post #12

Earlier quoted context omitted.

Seriously, I feel like it’s such an indictment on native app tool development that we have a bazillion new electron apps written by ppl all the time for weekend projects yet almost no one spitting out native apps to interface with services. It’s clearly in demand (if a bit of a niche kind of demand)

There are a bunch of very promising native desktop Matrix clients in progress: https://github.com/Nheko-Reborn/nheko as a Qt telegram-like https://github.com/quotient-im/Quaternion as a Qt xchat-like https://github.com/manuroe/messagerie for instance is a SwiftUI client proof-of-concept that should work on macOS as well as iOS None are as polished as Riot functionalitywise, but we will get there eventually - even mor…

Spectral is quite usable as well in my experience (At-based) https://spectral.encom.eu.org/

Fractal is the GTK counterpart https://wiki.gnome.org/Apps/Fractal

Thunderbird also has a Matrix back-end, though XUL is quite close to electron.

Lots of other clients https://matrix.org/clients/

Post reply on HN