First impression: I created an account on desktop and on mobile. I used the same display name and password in both cases. I got two different addresses. Good.
I don't see any means to copy an identity across the boundary (e.g. with Telegram, I can participate in the same conversation as the same identity from multiple devices).
Which means one of two things happens:
1. Users are encouraged to use on dedicated device for all private communications.
2. If users want multi-device, they have to leak facts about their setup (one public key per device) to the people they're talking to.
(This isn't a criticism; I'm just observing the user experience.)
Really like the idea behind this. The basic premise is really interesting: Conversation between two people is direct p2p through tor, while groups require a server that people need to host. It's a really interesting middle ground between having to trust a single party with all your conversations and making everything truly p2p.
Easy to get around residential ISP NAT issues too. It's really easy for any software to start a local ephemeral onion service on Tor on their local machine and have it reachable worldwide in a couple seconds.
I'm a fan of this project and have been watching it for a while. It is my hope that more self-at-home-hosted options pop up in this space around Tor onion services.
Shameless plug, I also wrote a simple lib that makes onion services easy: https://github.com/cretz/bine (OP's project uses a fork of it and I plan on putting more time into it soon)
The whole internet requires that any connection traverses numerous switches and routers. Unless you're pointing a microwave antenna at the destination to deliver your packets, the distinction here is pointless.
To be fair to the grandparent poster, who was downvoted, in the decentralized networking community there are protocols designed to be robust to different hardware setups, like over wifi or other ad hoc systems. Depending on tor from that perspective might be seen as restrictive.
Cwtch isn't made specifically for the decentralized networking community. The properties of a globally-usable, decentralized, and private system are almost entirely at odds with the constraints of decentralized networking. Making such a system robust against network partitions and latency and keeping your IP/location private while still being truly decentralized (and not federated) is an incredibly hard—and perhaps unsolved—problem.
Hi Sarah from Open Privacy / Cwtch team here - the main major difference is that Cwtch servers are completely untrusted under the risk model - they don't learn anything about the groups they are hosting, who is a member of which group, or who each message is for.
Metadata resistant group comms is still a fairly large open research problem, and we are also working on the research side to reduce some of the bandwidth requirements that are currently required by our group protocol: https://git.openprivacy.ca/openprivacy/niwl
On Android we implement a background service that will wake up periodically and either use the active tor connection or start a new one if the kernel has stopped it for any reason - and also reconnects the UI. This makes Cwtch connections fairly stable on android devices - even for p2p.
However, it also means that Cwtch on Android is fairly battery intensive. We provide a way to easily shutdown Cwtch completely for this reason - and we are researching ways to minimize power consumption (both through tor optimizations and alternative anonymous communication networks)
Not merely centralized, but also openly hostile to decentralization. Going so far as to hold talks about why decentralization is a bad thing for a chat app. I also never heard a rebuttal to this claim of Wire's:
> Moxie et al have publicly stated that they want wide adoption of the Axolotl [Signal] protocol — but if you do an independent implementation, using the published reference documentation and background knowledge from having seen their code online, you can be accused of copyright infringement and asked to pay a “license fee.”
I'm on Signal because of the network effect and its reliability, and I actively invite people to use it over things like Telegram, but I do wish we had a better alternative. Matrix (Element) is buggy, Threema people need to pay for, Jami and this Tor-based chat app (I forget the name) don't have the features people expect, Wire is a good contestant but also not decentralized (nor does it have fancy things like sealed sender), and of course nobody has the network effect that Signal has... no good alternatives.
You missed from your list of alternatives the whole XMPP network. It's a federated model (similar to email/Matrix), self-hostable and there are also public providers.
The XMPP ecosystem is pretty diverse and predominantly open-source.
Personally I'm working on Snikket, which is aiming to be the easiest way to get a group of people onto XMPP (often that's family groups, but also social).
Looks like this Conversations app doesn't do video calling, which kinda makes it a non-competitor compared to all of the alternatives that already exist.
I'm aware of XMPP and tried it out back in the MSN days along with IRC, but then Telegram came along which promised encryption and a much better user experience and until not so long ago I believed that Telegram would 'any day now' come around to implementing encryption proper (as everything ICT, from WhatsApp that sent plaintext messages over tcp/443 to websites around the world after LetsEncrypt, all turned on proper encryption, I didn't think that this self-proclaimed privacy-focused messenger would stay behind). And so I found myself in late 2018 starting to more and more doubt Telegram, but by then there were many competitors and Matrix seemed to be the hot thing that everyone was excited about (and it turned out that it didn't even work properly after you turned on encryption, only the unencrypted form seems to be somewhat reliable). XMPP didn't come to mind as potentially having evolved, perhaps because in the decade since MSN, I don't think I heard of a single person using XMPP for end-to-end encrypted calls. Perhaps it's great but... somehow I doubt that I never heard of a functional free decentralized/federated end-to-end encrypted multi-device user-friendly chat and (video) calling system.
> Looks like this Conversations app doesn't do video calling, which kinda makes it a non-competitor compared to all of the alternatives that already exist.
I hope that XMPP or matrix wins out and becomes a de-facto standard that everyone uses (like email) over things like slack, signal, whatsapp, telegram, teams and all the rest.
What I don't get about Snikket is why it tries to distance/hide itself from XMPP. The homepage does not mention it, the app page only mentions it by saying that Snikket is "Compatible" with Conversations which is also compatible with XMPP. The server page does not mention it at all. Is Snikket XMPP and a few XEPs? Is it something else? Can I use a XMPP client with Snikket? Can I use a Snikket client with a XMPP server?
That makes me doubt that Snikket cares about interop with XMPP or the wider ecosystem.
I'd hope that the blog post goes some way towards explaining that.
The ultimate reason is that we're not building something for the 1% of people who know what XMPP is. The protocol used is absolutely irrelevant to most people. Feature set and ease of use matter far more.
For the people who do know what a protocol is, it's not hidden information.
The perspective to have is that the use of XMPP adds features (federation, security, interoperability) but it does not (and should not) define everything Snikket is to end users.
I get that making things understandable to non-techie users is good, but even on pages talking about the server (even on the install guide and the github readme for the server: https://github.com/snikket-im/snikket-server) you don't mention XMPP.
> it does not (and should not) define everything Snikket is to end users.
Does that mean that interop with XMPP is not a feature one should depend on? Is Snikket a XMPP app, a XMPP service, a XMPP fork or is it not XMPP at all despite being based on XMPP software?
> even on the install guide and the github readme for the server you don't mention XMPP.
Sure, and I don't see a problem with this. It's irrelevant information for an install guide.
It probably should be in the readme (which frankly needs an overhaul). However if someone is looking for an "XMPP server" then there is a good chance that they are not in the target audience for Snikket. I happen to also be a developer of Prosody, the XMPP server software Snikket uses. Prosody is an extremely flexible and customisable XMPP server, and most Prosody users love that about it. But a Snikket server is totally opinionated, preconfigured and exposes minimal controls to the admin.
> Does that mean that interop with XMPP is not a feature one should depend on?
It's a feature you can depend on as much as you can depend on it having e.g. video calls. Removing it would have a negative impact on the project.
Replacing it? If there were alternatives and they were interoperable, sure, maybe. Matrix is probably the only alternative that comes close to that, but it has a way to go before it could meet our needs. I consider a switch from XMPP very unlikely.
> Is Snikket a XMPP app, a XMPP service, a XMPP fork or is it not XMPP at all despite being based on XMPP software?
It's an app and server that implements XMPP. It's not a fork of XMPP (we actively participate in XMPP development).
One final thing to note is that Snikket projects, while using standard XMPP, will focus on pushing XMPP forwards, and prioritise this over backwards compatibility with other projects in the XMPP ecosystem. Example: a couple of XMPP clients don't do encrypted calls yet. Snikket calls are encrypted always. We won't compromise on security or usability in the name of backwards compatibility. Related projects such as modernxmpp.org are part of this mission to keep XMPP moving forwards.
Their homepage explains why I never heard of it: it "uses the most massive and diverse open messaging system ever: the existing e-mail server network". That won't work for (video) calling; not an option for me. I might as well just send my mom an email at that point? (Since I self-host mail, it wouldn't even have to leave localhost. Also, guess what I'm debugging right now... what monster even created this thing called sendmail...)
>I was at a talk that had something to do with Unix. Fortunately, I’ve succeeded in repressing all but the speaker’s opening remark:
>I’m rather surprised that the author of sendmail is still walking around alive.
>The thing that gets me is that one of the arguments that landed Robert Morris, author of “the Internet Worm” in jail was all the sysadmins’ time his prank cost. Yet the author of sendmail is still walking around free without even a U (for Unixery) branded on his forehead.
Signal requires a phone number for contact discovery, which many people have given out about because it's tied to your meatspace identity, so it's harder to be anonymous with Signal.
Signal is centralized, server is closed source last time I checked, smells like a fed op, one of the creators was trying to use it to pump some shitcoin, it requires you to give them your phone number.
Check again. It's been updated for a while now. It's always updated, just sometimes less frequently then some people expect. There's no obligation to publish code every x months.
> smells like a fed op
You clearly have no idea what your talking about if you believe this. Signal is open source, it has been audited, it provides deterministic builds, is using state of the art cryptography, it's protocol is now the defacto secure communication protocol all other serious communication apps use, and is recommended and used by all the leading experts in cryptography and infosec...
> one of the creators was trying to use it to pump some shitcoin
Except there is 0 evidence that any pump and dump is going on. Or that moxie even owns mobilcoin. And calling it a "shitcoin" makes you out to be some cryptobro who shouldn't be taken seriously. There are numerous reasons they used a coin that was designed and optimized for use on a mobile phone. No other coins met their criteria. They also built some cool tech on top of that as well.
You're either seriously uninformed or are trying to spread fud.
Signal is encrypted and likes to show off how little they store, but it is not decentralized. Not being decentralized has many advantages, but a paranoid enough approach does see it as a point of failure for security (I use and love Signal, fyi)
The outbox has to exist somewhere. Instead of a central server like the group chat you could use some sort of distributed storage... but then some node(s) need to be online at all times to deliver asynchronous messages.
What if I have a friend who, due to timezones, is never online when I am. Or very rarely. Seems a bit ignorant of the wider needs of an internet community to not allow people to talk if they don't share enough of a timezone.
I supposed I'm (and you seem to be) implying that in the scenario of a group made up of A, B and C, if A and C are online when A sends a message (and then A goes offline) then B can receive A's message forwarded by C. We wouldn't need a server in this case, would we?
How do you mean? Could you link to where you could find that? Because I searched for 'metadata' in the Noise Protocol repository and came up with nothing (https://github.com/noiseprotocol/noise_wiki/search?q=metadat...)
N.b. I am very much an amateur and am fascinated by private communication methods
The Noise Protocol is a specific project, that, funnily enough, doesn’t include generating noise. I believe the name is intended to mean that the messages look like noise.
Here are some protocols that use noise (specifically differentially private noise):
> How do I pronounce Cwtch? Like "kutch", to rhyme with "butch".
> Cwtch (/kʊtʃ/ - a Welsh word roughly translating to “a hug that creates a safe place”) is a decentralized, privacy-preserving, multi-party messaging protocol that can be used to build metadata resistant applications
They do need to localize the name to fit the language of people using it although. It's like Kakaotalk insisting keep all written forms of their app's name in hangul: 카카오톡, which sounds like "kakaotog" in korean. That would be a recipie for not being searchable outside of Korea.
Similarly, for English, I would label it Kutch and probably make other appropriate photogenic transliterations for other languages.
Such an odd word. My 1-second judgment of it sent me in an entirely different direction: cthulhu, witch, crotch. I wonder if the emotional gap between cover and contents will be a problem.
Cwtch is an important word in Welsh, like hyggelig in Danish or koselig in Norwegian, etc. It's kind of a "national identity" word, you see it on tourist souvenirs.
It's a word from another language, what purpose would a 1 second judgment like that serve when the post you're replying to already explains that it's Welsh?
One thing I realized with this is that there are multiple levels of metadata privacy:
1. Messaging provider cannot see which accounts message each other
2. ISP cannot see which IP addresses message each other
Using Tor here gets you both 1 and 2, but at the cost of latency: it is something like 6 hops to rendezvous with a hidden service. WebRTC (assuming Tor as a TURN fallback) would be a lot faster, but would not include 2.
Many words have some not ideal meaning in another language. We (Switzerland) have cities with names that in other languages mean male genitalia yet we are not going to rename them.
Short answer; When done well, it makes the app more resilient against a variety of issues/risks that arise from relying on a server/service/single-point-of-failure.
> The answer to why is there no Mac/iOS version of Cwtch / why does Cwtch not have feature X is that last year we raised only a fraction of our donation target. You can help change that!
> @OpenPriv is powered by hundreds of individual donors just like you!
The status of Cwtch right now is probably more analogous to Moxie’s work on Axolotl before he launched Signal: a boundary-pushing messaging protocol that looks promising but is not yet widely deployed.
A bit tangential but I'd be honestly curious how many people use iOS and explicitly value their privacy. Everyone has something to hide so we all care implicitly to a certain extent obviously, but for the real nuts (that includes myself), Android is the only OS where you get to both have the freedom to turn things off as you please (at the flip of a setting for most manufacturers, at least) as well as install regular applications. A Linux phone is fun and all, but much less practical.
With iOS you have to either be a leading expert in vulnerability research or hope that someone else finds a serious security issue in your operating system, leave it unpatched, and then exploit it yourself to get proper access and control your device.
I'd trust Apple more than Google to do the right thing any day of the week, but they're not some foundation with a mission. Cutting Apple out of your data is a lot harder on an Apple than it is to cut Google out on Google's platform.
Maybe talk to Apple, whom have made it increasingly hard to theoretically impossible for our type of privacy preserving app to run on iOS. We aren't the first, and Brair has been around a bit longer and has run into the same problem.
As an even smaller team with less funding, we have so far decided it would be irresponsible to risk sinking a sizable portion of our limited funds into trying to port to iOS when it may be impossible.
But if you really want it, please, donate, we need iphones, macs, dev accounts and budget for the research and work!
Talking to Apple won't change the circumstance that I am alluding to, which is that most people willingly opt for closed, centrally censored platforms.
You can't solve this problem at the application layer.
I don't see any means to copy an identity across the boundary (e.g. with Telegram, I can participate in the same conversation as the same identity from multiple devices).
Which means one of two things happens:
1. Users are encouraged to use on dedicated device for all private communications.
2. If users want multi-device, they have to leak facts about their setup (one public key per device) to the people they're talking to.
(This isn't a criticism; I'm just observing the user experience.)