Live data from Hacker News

Wire open-sourced

github.com

121–130 of 140 posts

Re: Wire open-sourced

#121
post #117

Earlier quoted context omitted.

Surprisingly, the best feature of Wire has been audio quality. Security/privacy is a welcome bonus.

Is the audio quality good enough to make hundreds of millions of people switch from WhatsApp? They've been trying for a few years, and it hasn't happened. I think open sourcing the apps is probably a last gasp, and we're likely to see Wire shutting down soon. I've also heard they might be looking for a buyer.

That would be a shame. Skype sold (twice!) for billions of dollars, and the Wire investors should have access to internal growth metrics to justify a long-term investment. Like every messaging app that relies on network effects, some growth is inevitable. I've been steadily adding new contacts, each installing Wire for the first time.

Re: Wire open-sourced

#122
post #119

Earlier quoted context omitted.

Doesn't it? Not to challenge the authority, but I believe the only requirements OTR impose are constraints on the initial presence (thus, lack of offline operation) and constraints on message ordering. Which doesn't seem too severe to me, if the saying about "always connected" world is true enough in reality. Maybe I'm deeply mistaken here. But, I mean, 99% of my conversations are when both participants are online, a…

> Doesn't it? Not to challenge the authority, but I believe the only requirements OTR impose are constraints on the initial presence (thus, lack of offline operation) and constraints on message ordering. It's an asynchronous world, trying to use a synchronous protocol in that world doesn't make a lot of sense. If you want to initiate an OTR session with your friend on an iPhone, you have to wait for them to pull the…

> If you want to initiate an OTR session with your friend on an iPhone, you have to wait for them to pull the device out of their pocket and physically tap the notification

Is it still the case? I have never wrote code for iOS, but believe I heard this was the limitation only for very old versions and was solved quite a long time ago, with introduction of "silent" pushes (or whatever they call it, when there's no notification message but only a data transfer that wakes up the application). Should work unless the user had force-quit the app, in which case iOS won't start it.

> so if you want the benefits of forward secrecy, you have to "end" your OTR session after each conversation

[edit/upd some minutes later] I'm confused now. If full system state (incl. long-term keys) is compromised, the whole system isn't secure anymore, no matter how many times it's rekeyed. And if only ephemeral keys (but not long-term ones) are compromised, won't OTR "heal" itself after a few messages, so FS property remains?

I was misunderstanding OTR - I had assumed "ending" the conversation is required for deniability (by disclosing the MAC keys so anyone can forge the messages later), and encryption keys are changing as the conversation goes.

> You can do this today if you want to

In theory, yes, I suppose so. In practice, I've looked for a libpurple patch/fork with SP OTR-like overlay support, but haven't found any.

> but what's the point when Signal Protocol is being baked into the messaging services themselves

The problem is some popular services (e.g. Skype or Telegram) won't bake SP in. And a lot of users are there and aren't switching. The only viable short-term scenario is to ask them to layer the encryption (in my experience, there's way less resistance than when asking everyone to hop to another network) until the platform dies or otherwise becomes uncool.

Re: Wire open-sourced

#125
post #105

Earlier quoted context omitted.

MIT has one condition: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. As the code include this, the author who distribute the code can thus prove in court that they are compliant with the wishes of the author/s of the MIT licensed software. The added GPL means that copies of this specific version also adds additional conditions that those…

IANAL but I thought the compatibility was only one way. I.e., you can use MIT code in a GLP project but you can't do the reverse. My understanding is if you use GPL code in an MIT project, you have to make your entire project GPL.

Yes and no :). The MIT authors can not sue someone for not following GPL, and the GPL authors can't sue someone for using the MIT licensed code under MIT.

There is one consideration however. One of the GPL license condition says "must license the entire work under GPL", which mean that in order to legally distribute the GPL part, the MIT licensed code will be under both GPL and MIT. As such the patent grant in GPL will cover the whole project for anyone distributing the GPL included version, and many interpret this condition as making the entire project GPL. The exception to that view is that a project can still continue license new code as MIT, and a distributor could simply remove the GPL parts when they want to use it in a MIT and BSD only/Proprietary/Patent enforcing situations.

While I have not seen many MIT projects do this in regard to GPL add-ons and patches, it is the standard model for open core MIT projects to do this in regard to proprietary add-ons. I would thus not call the existence of optional GPL patches or add-ons as "make your entire project GPL", unless the additional code is essential to run the program.

Re: Wire open-sourced

#126

Earlier quoted context omitted.

Because it's horrible UX. I don't want to open a whole other application, search for it on their placeform, and then authenticate with AppleID. Instead you can just download a .dmg or a .zip right from their website, like how it's been done for aeons.

What searching? The developer links you directly to their app in the store. For free apps you don't necessarily need to enter a password, for paid apps it's still simpler than whatever payment system the developer might be using. With the MAS you can go from viewing the app/developer website to the app being installed in as little as two clicks. How is that worse ux than manually downloading an archive/image, opening…

Installing apps from web:

    wget http://example.com/app.zip
    unzip app.zip -d app_files
    mv app_files/App.app /Applications
    rm -rf app.zip app_files
With Mac App Store, I have to leave the CLI and use the mouse like a filthy peasant.

And I pirate paid apps. Way easier UX there, because I don't have to spend any money.

Re: Wire open-sourced

#127

Earlier quoted context omitted.

What searching? The developer links you directly to their app in the store. For free apps you don't necessarily need to enter a password, for paid apps it's still simpler than whatever payment system the developer might be using. With the MAS you can go from viewing the app/developer website to the app being installed in as little as two clicks. How is that worse ux than manually downloading an archive/image, opening…

Installing apps from web: wget http://example.com/app.zip unzip app.zip -d app_files mv app_files/App.app /Applications rm -rf app.zip app_files With Mac App Store, I have to leave the CLI and use the mouse like a filthy peasant. And I pirate paid apps. Way easier UX there, because I don't have to spend any money.

> With Mac App Store, I have to leave the CLI and use the mouse like a filthy peasant.

I found https://github.com/argon/mas in about 5 minutes.

Also, that tool will show you app id's from a search. What's the wget command to identify the correct download link for a given domain, assuming you even know the domain name for the app you want.

> And I pirate paid apps

Right so at this point your opinions are essentially worth less than nothing.

Re: Wire open-sourced

#128
post #35

Earlier quoted context omitted.

Correct, there's no server. I will avoid blockquoting large amounts of text but on their open source summary page [1], they give you two options: 1. you point your implementation to their server and you have to abide by their additional terms (which is exactly what I'd expect) - or - 2. you point your implementation to somewhere else, unspecified, and you're only bound by GPLv3 Right now, #2 is moot because there is…

Does the Wire licence agreement allow you to create a standalone server though? https://github.com/wireapp/wire/blob/master/README.md "Additionally, if you choose to build an Open Source App, certain restrictions apply, as follows: a. You agree not to change the way the Open Source App connects and interacts with our servers" Even if the company behind Wire seems trustworthy, if I cared about security I wouldn't want…

Ugh, they are doing it wrong.

Software with restrictions like that isn't GPL compatible. Full stop.

In the parlance of the Free Software Foundation: Restrictions like that violate Freedom Zero: https://www.gnu.org/philosophy/free-sw.html

In this case, there is a clear path forward: remove these restrictions from the FOSS apps and place them in the ToS of the services operated by Wire Swiss GmbH.

It's obvious that Wire wants to be able to ban clients that behave poorly. (Like spambots, flooders, etc.)

By presuming that all official Wire clients will always be good, they a muddling the issue. What they really need here is a ToS on their server. Basically: "You can connect here with whatever client you want, but we reserve the right to killban you."

Re: Wire open-sourced

#129
post #117

Earlier quoted context omitted.

Is the audio quality good enough to make hundreds of millions of people switch from WhatsApp? They've been trying for a few years, and it hasn't happened. I think open sourcing the apps is probably a last gasp, and we're likely to see Wire shutting down soon. I've also heard they might be looking for a buyer.

That would be a shame. Skype sold (twice!) for billions of dollars, and the Wire investors should have access to internal growth metrics to justify a long-term investment. Like every messaging app that relies on network effects, some growth is inevitable. I've been steadily adding new contacts, each installing Wire for the first time.

I don't know what kind of internal metrics would be telling a different story than the external metrics visible to us. The app store data alone is pretty damning, any growth they've had over the past few years is very slow linear growth. People don't seem to like the app enough to switch.

You're right, they sold Skype twice, so they're not stupid. They're unlikely to keep throwing money away when the writing on the wall is this clear, and word on the street is that they're looking for an exit.

Post reply on HN