Hacker News new | ask | show | jobs
by godelski 1793 days ago
I don't think Signal has many devs[0] and if you look at the contributors[1] you can see that Grayson is pretty much the only dev for the Android app. So seeing a second dev get involved is probably them freaking out.

[0] Personally I believe this is a big bump in the road for Signal and is why a lot of people are frustrated. About promises about things like usernames (it is no longer early 2021), channels, and everything else. A few devs can only do so much. A dozen (maybe 2 dozen?) devs can still only do so much. How do you compete with other platforms like Telegram that has hundreds of employees or WhatsApp with far more than that?

[1] https://github.com/signalapp/Signal-Android/graphs/contribut...

4 comments

I mean, they invested a year into covert development of a crypto wallet inside Signal. Maybe that time could have been spent better.
From the commits I only really saw Moxie adding this and he hasn't been doing as much dev work in the last few years. So I don't feel that this took much away. It's hard to tell if it is a good move or not since Telegram and WA are both adding payments to their platforms and there is a need for feature parity. But regardless, MOB probably wasn't a good fit and we've seen no update since.

My complaint is more than Signal moves far too slow. I'm not saying to move fast and break things, that's far from what I want. But I am saying maybe add a few more devs.

> But I am saying maybe add a few more devs.

Absolutely, then such an important issue probably wouldn't stay open for this long.

No, Signal does not get to play the limited resources card when they so firmly discourage 3rd parties from working on their project.
No, contrary to common belief, coordinating with multiple client projects to release features simultaneously etc, is not easier. The number of meetings does not drop, the quality will not improve if you now have to check that multiple clients are safe. You won't magically get more eyes on your code, when people are working on their code, not yours. And at that point you now have to deal with people who think they have as much say as you have because their fork is "equally important". And trying to explain to a non-cryptographer hobbyist why some change needs to be done, or why some feature can/should not be implemented, is not speeding things up.
Could you explain what Signal is doing to discourage contributions?
By not allowing 3rd parties apps to coexist with official signal app. (Using same servers)
Signal placing restrictions on who can use their service has nothing to do with whether or not people can contribute to the codebase.
It does. There is less incentive to work on a Signal client fork if it can't be used to interoperate with the Signal service.
That's a bit like saying there's less incentive to work on (for example) Elasticsearch, because you can't deploy your fork on Elastic Co's official managed service. It's nonsense.
Nor when they've received millions in grant money.
Not true
Bug report is eight months old now. I don't think they're freaking out much.
But the issue is fixed. Forgetting to close a bug report is different than not fixing the bug
True, but the issue was fixed in 5.17, which was released only 10 days ago [1]. For an issue opened December last year, that's still quite a lot of time before a fix could be found.

[1] https://github.com/signalapp/Signal-Android/commit/a47448b6c...

Try fixing a rare bug quicker without constant user metrics.
Yes, indeed.

This kind of bug is an argument for having metrics.

I'm not convinced. The bug is rare and requires a specific set of circumstances that not many people are going to perform. That is not an argument to collect metrics, or in other words, change the entire paradigm of Signal (no collection of Metadata). It does propose an argument for more audits, more eyes, and more care. But we do not expect Signal to be perfect, as no software is. Systematic failure, on the other hand, creates worry about Signal. But not individual.
If this is the case, then we should just say:

Signal is not secure because they have limited resource and cannot invest in an area with Security adequately.

Or perhaps we drop the pretence of anything being absolute ('secure' vs 'not secure') and have a more honest discussion about the different threats and where different products do better or worse? I'm sure Whatsapp is much better in being able to resource their security measures, yet being owned by Facebook, and being closed-source diminishes their security in other ways.
I personally trust whatsapp, great product