An end-to-end encrypted anonymous webchat
from nemesis3469@lemmy.world to privacy@lemmy.ml on 30 Jun 21:10
https://lemmy.world/post/48864912

Source code and details: git.anarchists.space/NanoChat/Server

Features

Technical details

#privacy

threaded - newest

voxel@feddit.org on 30 Jun 21:42 next collapse

Cloudfare doesn’t let me through. 🙄

nemesis3469@lemmy.world on 30 Jun 22:12 collapse

We were under attack from a Singaporean botnet for two weeks, so I had to put our Forgejo instance behind Cloudflare because of that 🥲

nutbutter@discuss.tchncs.de on 01 Jul 00:59 next collapse

Do peojects like Anubis fail in such cases?

nemesis3469@lemmy.world on 01 Jul 01:01 collapse

Anubis is for blocking AI crawlers, not DDoS attacks

airikr@lemmy.ml on 04 Jul 10:24 collapse

I literally hate people who only wants to destroy or weaken good things 😒 But why don’t you use Codeberg? Is it because of downs every now and then because of the same reason (DDoS attacks from idiots)?

solrize@lemmy.ml on 01 Jul 00:06 next collapse

How does the anonymity work?

nemesis3469@lemmy.world on 01 Jul 00:41 collapse

There are no user identities (not even cryptographic ones), and room encryption key is stored in URL which is never sent to server. Anyone can choose any nickname and you can access official instance (nanochat.anarchists.space) through Tor.

dreamy@lemmy.blahaj.zone on 01 Jul 08:59 next collapse

OnionShare already has a chat feature that works pretty well. What does this add?

nemesis3469@lemmy.world on 01 Jul 11:57 collapse

Codebase is small and easy to audit. The panic button wipes all chat history in a room and blocks future messages. OnionShare fully depends on Tor’s built-in encryption for message security while NanoChat has its own encryption, which means you can host it on different anonymity networks.

thatsnomayo@lemmy.ml on 01 Jul 12:53 next collapse

Thanks for sharing I recommend Cheogram web which is in beta but will reach the full feature set of the app in due time

armrecords@lemmy.ca on 04 Jul 04:47 collapse

A few ideas that could further strengthen the design:

  • Consider deriving separate keys from a master secret using HKDF (e.g. encryption key, authentication key, attachment key) instead of relying on a single key for everything.
  • Room IDs alone could leak metadata if discovered. An HMAC-based room authentication scheme could help without requiring the server to know any encryption keys.
  • Adding replay protection with counters/nonces and periodic key rotation would make the protocol more resilient.
  • For public deployments, some abuse protection (rate limiting, room creation limits, optional proof-of-work) would help prevent DoS attacks.