Notices tagged with wire, page 4

@sheogorath just popping in with a necropost to point out that AFAIK all parts of #Wire are now #FreeCode (all clients and server), source code on GH:
https://github.com/wireapp/
@Privacy

@shura that might be possible, if there were a single #XMPP client that supports all the major OS, and the web, like #Wire does.
@jcbrand @z428

@alexl to me, a community is by definition of group of people who trust each other. Also, there are ways to do #E2E encryption over the web. #LavaBit did it. #Wire does it. There are other examples.

@dazinism @clacke yes. But I wouldn't use it, because I don't trust the motives of the people who make Signal, or their approach to security. If I want to use a centralized, #E2E encrypted chat app that I can't install via #FDroid, I use #Wire.

@ghostdancer @clacke this is why I encourage people to use #Wire instead of Signal, as it is user-friendly for non-geeks, and the Wire devs are much more willing to work towards;
* removing any remaining non-free dependencies from their clients
* having their #Android client distributed through F-Droid
* federating with other E2E encrypted chat systems

If everyone who worked on #LibreSignal went and helped with this, maybe Wire could be in F-Droid in the forseeable future.

@charlag @clacke from what I've read, Moxie doesn't care if #Signal is on F-Droid or not, but is no longer of to it if someone else does the work. I got a support email from #Wire today saying they'd like to be on F-Droid, but they have a few non-free dependencies to replace before it would be possible. Also that Wire only requires Play Services on Android versions older than 5.x

Hopefully this might lead to chat apps like #Wire and #Signal breaking their final dependencies on proprietary components, so they can finally be distributed through @fdroidorg

@joshsharp oh and one more thing. #Wire (encrypted chat app) is another example of a company that started out proprietary, and has now liberated all their code. They have paying customers that AFAIK have continued to pay to support the continuation of code dev and the hosted service. Like WP, the codebase, paid hosting service, and free hosting service, are all under the one brand name. Something to think about :)

@ink_slinger @danyspin97 it depends what your threat model is (secure from whom, and how skilled and scary are they?), and who you want to use it with, of course. If you're just looking for a #FreeCode alternative to #Skype/ FB #Messenger that has user-friendly mobile apps, I suggest #Wire. It's the first free code chat app I've managed to my non-geek family to use. Like Signal, and unlike Telegram, both client *and* server source are available under free code licenses.

@danyspin97 @TheOuterLinux
> Wire is centralized and is really similar to Telegram in design

Yes, in that both are server/client and not federated. The difference is that #Telegram server source code is non-free. #Wire has released all their source code under copyleft licenses (GPL/AGPL). So, I could run my own Wire server instead of using theirs, but users would probably have to download a modified client to use my server, and they wouldn't be able to chat to users on Wire's server with it.

@TheOuterLinux @danyspin97 have you tried #Wire and #Ring? Wire relies on a centralized server, but Ring is #P2P (like #Tox). They're both #FreeCode and both work pretty well for text chat, one-to-one voice calls (although I had persistent echo on Ring the one time I've tesed it so far). I've also tested file-transfer and image sharing on Wire, which work fine. Haven't test conference calling or video chat on either yet.

One of the challenges for federating #FreeCode chat apps is the risk that doing so punches security holes in the privacy protecting #E2E #encryption they use. This is one of the reasons we have #XMPP competing with #Matrix, and both competing with walled gardens like #Wire and #Signal, even though both of these have liberated the code for both their clients and servers.

@AmarOk @wuhei @mayel I understand why. There would have to be supernodes in the #P2P network that could hold the messages until delivery. It would improve the #UX if they could figure out how to add them. It helped me a lot on #Wire when I was lining up times to test voice calls.

Just tested a voice call on #GNU #Ring for the first time (my Ring ID is 'strypey'). Worked pretty well. Not quite as good as #Wire, mainly because with Ring there was 3 sec delay, and I couldn't get it to stop echoing my own voice back to me, even using headphones and an external mic. More tweaking required (at my end or theirs)? Quite impressive though considering no server is involved. Client #UX isn't quite a smooth as Wire yet, but it has a lot of potential.