top | item 32732158

Show HN: Chitchatter – P2P chat app that is serverless, decentralized, ephemeral

191 points| jckahn | 3 years ago |chitchatter.im | reply

For anyone who is interested to learn more about Chitchatter, please check out the project README: https://github.com/jeremyckahn/chitchatter#readme

Chitchatter is very much an early MVP, so I'd like to get your feedback. Thanks for looking!

86 comments

order
[+] adg001|3 years ago|reply
Jeremy, thanks for Chitchatter and for bringing this up here. The first feedback I can give you is about the threat model and the associated OPSEC measures mentioned in the README.

Anyone with knowledge of the room UUID can listen to the conversation, even though the presence of the eavesdropper may (or may not) show up in the connected peers' counter. It is of essence to share such UUIDs over a secure channel, or the communication security will be compromised trivially.

It is mentioned in the README the relevance of government level threat actors and email, SMS, Discord, among the possible mediums over which the UUIDs can be shared. Of course this leaves Chitchatter open to be attacked by governments and network operators, who do have access to the phone network(s), email servers, and other platforms involved. It would be best to prefer other out-of-bound channels, or come up with one-time UUIDs generators able to resynchronise and shared among the peers.

[+] jckahn|3 years ago|reply
That's a great point. I'll tweak the README a little later to suggest using https://burnernote.com/ (as others here have suggested) to more securely share room links. Thanks for the suggestion!

> Anyone with knowledge of the room UUID can listen to the conversation, even though the presence of the eavesdropper may (or may not) show up in the connected peers' counter.

Though much of Chitchatter's security model is based on security by obscurity, I don't know that peers would be able to connect without room participants being notified. Is there a scenario you have in mind where a peer would be able to connect and intercept messages without the peer counter incrementing?

[+] feb|3 years ago|reply
The README is a bit optimistic about it the security model. Like the parent said the room UUID is a very critical asset and should be handled as a critical secret. Sadly, users may not know that.

In addition, the README says one can audit the full code and the assets used. For example, it suggests to audit the gh-pages branch for the static assets. But when hosting with github, that branch could change at any time and deliver non-audited content. Powerful attackers like government could do it easily, and less powerful ones too.

[+] DreamFlasher|3 years ago|reply
Initial key exchange via public private keys would be an amazing addition!
[+] ajconway|3 years ago|reply
On top of that, like every p2p service without onion routing, one's IP address is visible to every other room participant by design.
[+] TheJoeMan|3 years ago|reply
I had a relevant thought just the other day: why do our chat apps (sms, wechat, etc) need the ability to message someone without first meeting face to face? Maybe just use a QR code you scan from their phone and that’s it. If anyone gets your phone number they can send you unwanted spam because it’s “push”
[+] kornhole|3 years ago|reply
Butnernote.com could be a good way to share the room URL over generally insecure channels. After MVP, maybe an ephemeral room link could be created using the code from burnernote to save a step.
[+] laserfly|3 years ago|reply
Thanks for the post, nice to see new apps. In my experience with webRTC, a lot of the time the p2p connection does not get fully achieved, and the connection falls back to the server. Are you saying that the chat room will not run unless it is true p2p? If not, it would be good if the app shows the type of connection that is being used (p2p or via server).
[+] jckahn|3 years ago|reply
Thanks for the feedback! Chitchatter uses https://www.metered.ca/tools/openrelay/ for relaying communication when P2P connections can't be established. So, chatting should "just work" for users right now. I don't know if the current connection type (P2P or relayed) can be determined by JavaScript. If not, it seems that allowing the user to disable relaying servers might be the safest option (at the expense of the app not actually working).
[+] ackbar03|3 years ago|reply
I was curious about this too. In my experience the real obstacle behind true p2p is everyone is behind a router or firewall these days with shared ip. Most also prevent hole punching through port randomization.
[+] gfodor|3 years ago|reply
Author might be interested in a recent thing I released to use a cloudflare worker instead of webtorrent servers for signaling:

https://github.com/gfodor/p2pcf

[+] Sophira|3 years ago|reply
Wouldn't that make it centralised, though, with Cloudflare being necessary for it to work?
[+] bilekas|3 years ago|reply
This looks kind of interesting, can't dig too much into right now on my phone, but is the idea just for signalling while the "rooms/channels" are empty?

I'm not sure what the point might be in that case.

Or is it a cloudflare service based websocket service?

I'll check it out when I have a chance at Which point I'll probably have some more dumb questions!

[+] jckahn|3 years ago|reply
I'm using https://github.com/dmotz/trystero for all the networking, and I don't think it supports p2pcf. If that existed a connection strategy for Trystero, I'd be open to experimenting with it!
[+] deepstack|3 years ago|reply
gfodor, just FYI your link on github is not working. I get "We had issues producing the response to your request." from github.
[+] earnesti|3 years ago|reply
Sounds centralized
[+] cjtrowbridge|3 years ago|reply
I know this is an MVP but it seems unclear what meaningful structural improvements you're making over more feature-rich alternatives like Tox?
[+] jckahn|3 years ago|reply
Thanks for taking a look! This is my first time hearing of Tox, so it’s hard to for me give a great answer at the moment. Based on a quick look at Tox, it seems that a key differentiator is that Chitchatter conversations are ephemeral. Also the Chitchatter client is web-based, so you can just share a room link without anyone having to install anything to participate.
[+] rendaw|3 years ago|reply
What is Tox actually?

The Tox website doesn't say anything about the architecture, neither does Wikipedia. Apparently it's a library implemented in C and everyone's expected to use that. The Wikipedia reference links are dead, the only 3rd party implementation says "On hold until Tox gets proper docs."

[+] e12e|3 years ago|reply
> If you would like to verify that the app hosted at https://chitchatter.im/ is the one that is hosted on GitHub, you can use dig:

And if you trust github/Microsoft to not play games on what is delivered to you (say, because someone backed by the patriot act asked them to).

[+] snewhacker|3 years ago|reply
"Only rely on github" is amazing. And I have anticipated something crazier, maybe too crazy to be true. A server-less IM/forum mobile app which can hold persistant multi-party chatting. I know, server-less can mean a lot of information loss. I'm simply wondering if people can still find each other after going offline and online with a different IP, and even somehow retrieve information during offline time. As a tradeoff, the users understand and don't care if some messages are dropped (as chatters can figure it out using human brains) or security threats (MITM, eavesdropping, etc.). Since I'm new to network and P2P, this can be nonsense. And if this is possible, can anyone provide some links concerning the problem? first comment on HN :)
[+] jstanley|3 years ago|reply
Cool project. I'm curious why you don't use Tor to provide peer-to-peer connectivity? It gives you NAT hole-punching and encryption for free. It seems the obvious choice.

For an alternative (but sadly barely-used) chat protocol that does use Tor, see Ricochet: https://en.wikipedia.org/wiki/Ricochet_(software)

[+] jckahn|3 years ago|reply
Thanks for checking out the project! Chitchatter uses https://github.com/dmotz/trystero for peer connectivity, which doesn't support Tor. I don't know how Tor would be supported in a typical web browser. Have you seen Tor being used directly in that way?
[+] timbit42|3 years ago|reply
Another option is I2P which, unlike Tor, supports UDP.
[+] porcc|3 years ago|reply
Excellent work. We need more of these build-it-once peer to peer serverless webpages.
[+] blamestross|3 years ago|reply
Why write a really long hn post when you can write a blog post: https://www.miasma.space/anon-dhts/

The short of it is, sending secure messages without anonymity is pretty well solved, and while DHTs/webtorrent will buy you some obscurity, it can't solve any anonymity problems at scale.

[+] jckahn|3 years ago|reply
This blog post was really helpful. Thank you blamestross! My understanding of your concern: So long as there is a static WebTorrent tracker initiating the peer connections, the system can't be fully trusted. I agree with this, and I plan to counter this threat vector by enabling users to specify their WebTorrent pairing server and STUN/TURN relay servers. That way, concerned users can choose to self-host the relevant servers and effectively treat Chitchatter as a front end to those. Do you think that would address the concern you brought up?

Additionally, a core feature of Chitchatter is that all communication is ephemeral and not persisted to disk, ever. Even if peers are identified, there would be no record of what communication took place. Do you think that should sufficiently protect users?

[+] saimiam|3 years ago|reply
Not sure how this was supposed to work but I had two different browsers (safari and Ddg) open on my phone connected to the same room.

When I sent a message from the second browser, it didn’t get delivered to anyone, and the first room showed a message saying “someone has left the room”.

Looks like your message identity is driven off ip or something unique to the device rather than browser.

[+] djbusby|3 years ago|reply
Could the browsers lose the connexion when not the app with focus on the phone? Like maybe it reset the websocket?
[+] nl|3 years ago|reply
Specific suggestions:

Make it clear you can use markdown

Have a max size of message (noting that MD can make short messages take a lot of space)

Allow rooms to have names

QR Code to link to room

[+] jckahn|3 years ago|reply
These are excellent suggestions. Thank you! I will add this to my list of improvements to make to the app. :)
[+] can16358p|3 years ago|reply
Perhaps irrelevant question but:

Why does it have the feeling of something being designed by Google?

[+] onion2k|3 years ago|reply
Because it's a new chat app.
[+] wgx|3 years ago|reply
It uses Google’s Material Design UI kit, pretty much out of the box with no tweaks. Hence looking very “Googley”.
[+] o_m|3 years ago|reply
The components are made with MUI, which is a component library based on Material design, originally created by Google.
[+] anon115|3 years ago|reply
its interesting people are talking to each other and the conversation everyones taking part in the people cool and chill i dunno how to explain it, it the anonimity make people candid because i like it?
[+] DeathArrow|3 years ago|reply
If I would try something like that, I would use a spy camera and image recognition.
[+] deknos|3 years ago|reply
i just wish, magic wormhole also would adopt open stun/turn relays like this :(
[+] anon115|3 years ago|reply
can i use this to sell drugs?
[+] geysersam|3 years ago|reply
Yes, any medium of communication can be used to sell drugs. There's a theorem fo that.
[+] SquidJack|3 years ago|reply
I can access anyone room just simply changing the MD5 hash url Random Password protection for room may be the best feature
[+] peddling-brink|3 years ago|reply
That’s a UUID. The UUID becomes the password.

There are significant downsides to this plan depending on your threat model.