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.
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.
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
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).
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.
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 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!
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.
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.
> ...self-at-home-hosted options pop up in this space around Tor onion services.
See also: https://github.com/agl/pond
With Snowflake bridges, apps can now connect to the Tor network from within a browser.
Ref: https://snowflake.torproject.org/
1 reply →
Tor isn't really P2P since messages need to go through Tor's network of routers.
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.
2 replies →
My first thought as well, since tor is built around the idea of bouncing connections around the network.
But "p2p" still makes sense, if we just consider tor a black box.
So nothing on the internet is peer to peer, since you have to go through ISP’s network of routers?
1 reply →
How does this compare with something like Matrix, which also does decentralized encrypted communications? https://matrix.org/
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.
The design for groups is still in flux, and they are marked experimental but there are a few more details in our Secure Development Handbook https://docs.openprivacy.ca/cwtch-security-handbook/groups.h...
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
Interesting project! I've been looking for something to replace Signal, and this scratches an itch.
I see that you're using Tor to route messages? How would mobile devices fair with Tor connections when they go to sleep?
1 reply →
how will it compare to P2P Matrix?
I'm wondering that too, or specifically how it compares to Matrix run as a Tor hidden service, which is apparently possible:
https://github.com/matrix-org/synapse/issues/2111#issuecomme...
I'm not sure if Cootch is federated, like Matrix, or peer-to-peer. I assume the first, if Tor is being used?
Berry also sounds similar, although it is not released yet: https://berty.tech/
It's Cwtch, pronounced more like Cutch than Cootch
Edit. Cutch was supposed to be more of a phonetic way to pronounce it as opposed to a word with a similar sound.
10 replies →
Wait, why do we dislike Signal?
I'm always late to the secure comm party...
EDIT: Got it, Cwtch is decentralized p2p, Signal ain't. Thanks!
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.”
Or that fiasco with integrating a shitcoin in the application: https://www.stephendiehl.com/blog/signal.html
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).
We published a blog post comparing the Signal approach with XMPP/Snikket: https://snikket.org/blog/products-vs-protocols/
7 replies →
DeltaChat?
2 replies →
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.
My understanding is that Signal is centralized, and this is not. That's an important difference.
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.
> server is closed source last time I checked
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)
Haven't looked in to this properly yet but already in love with the name!
So... Why does Alice and Bob need to be online to be able to communicate? Can't Alice place a message in a outbox while waiting for Bob to be online?
Also, couldn't we avoid having a server for group chat based on same idea (cache messages in outbox until other parties come online?)
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.
If you care abt privacy you could just wait till someone is online to send the outbox content.
You dont need asynchronous messages to be stored centrally, but you d need both to be online at the same time at some point.
That s a feature I never saw in a chat app, they always have a central crap keeping messages defeating any kind of serverless claim.
1 reply →
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?
3 replies →
Twitter thread from a dev: https://twitter.com/SarahJamieLewis/status/14085012588523110...
From their faq.
> 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.
It is a word from the Welsh language, so it may seem weird to someone unfamiliar with the language.
1 reply →
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.
Can it handle multiple devices of the same account?
According to the FAQ on the linked page, not yet.
thanks!
It's where telegram won over signal for me for a long time. It's still not perfect, but ok now :)
Crashed with no message within the first 30 seconds clicking around on the UI (windows build)
I'll try again in a year or so if it still exists.
damn I can't even imagine the level of autism of those who decided that cwtch is an ok name, interesting product tho
[flagged]
No, not really. It more like Kutch.
They have a section as follows:
How do I pronounce Cwtch? Like "kutch", to rhyme with "butch".
Just scroll down the homepage
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.
The township of Dickcöcknbahls is not going to abandon their proud heritage due to prudish Anglophones!
No, not really. It's Welsh for "Hug".
The competitors found that "Riot" was too controversial a name for popular adoption... good luck to "Cootch"...
No. It's Welsh
Why do we need decentralisation in a chat app?
More robust. You can use P2P stuff offline in a disaster scenario. The entire thing will never be down for maintenance or from an error.
I haven't yet familiarized myself with this particular protocol, I have something like Briar in mind when it comes to P2P chat.
Why do we need decentralization in any app?
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.
Android and desktop only, so most people I know won't be able to use it on the only device they message on.
If you're speaking about iOS, the dev just tweeted this: https://twitter.com/SarahJamieLewis/status/14088573160870584...
> 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!
> https://openprivacy.ca/donate/
They are competing with Signal (and also every other insecure messenger like WhatsApp and Telegram), and Signal already exists.
Cross-platform support is table stakes for a messenger. This will likely go the way of Ricochet.
2 replies →
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.
Or just use a hardware firewall upstream of the device, which is what I do. My iPhone doesn't have a SIM in it.
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.
https://briarproject.org/news/2018-1.0-released-new-funding/
https://code.briarproject.org/briar/briar/-/issues/445
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.