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

Features

  • Small codebase
  • Messages expire after 30 days
  • Panic button to delete all messages in a room
  • WebSocket for communication
  • Docker support

Technical details

  • AES-256-GCM for client-side encryption
  • Key is not sent to server

all 11 comments

sorted by: hot top controversial new old
[–] 8 points 1 month ago (1 child)

Cloudfare doesn't let me through. 🙄

  • source
  • hideshow 2 child comments
  • [–] [S] 12 points 1 month ago (2 children)

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

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 1 month ago*

    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)?

  • source
  • parent
  • [–] 5 points 1 month ago (1 child)

    How does the anonymity work?

  • source
  • hideshow 2 child comments
  • [–] 1 point 1 month ago (1 child)

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

  • source
  • hideshow 2 child comments
  • [–] [S] 1 point 1 month ago

    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.

  • source
  • parent
  • [–] [B] 1 point 1 month ago

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

  • source
  • [–] 1 point 1 month ago

    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.
  • source