# Brainstorm

## What is wrongthink?

Wrongthink is meant to be a real time chat application, with features similar to discord (a clone basically). It's a self hosted web application with the back end implementation in c++ with support for different clients.

## Features
- Simple, clearly defined, open protocol
- No registration, no bloat, no centralised servers
- support a large number of concurrent connections
- anonymous users + normal user accounts
- master server registration/listing
- communities
- public channels listing on main page
- private chats
- E2EE
- file sharing via webtorrent & direct uploads
- Allow users to create chat rooms/channels
- voice chat via webrtc mesh
- option for full p2p ring based group chats with webrtc
- retrieve user stats + user data currently stored on the server
- all features modular & configurable
- message pruning / ephemeral chats

## Architecture


## Sign Up List

*Username and your level of technical skill (if you want to share)*

- **cdcode** - compsci (((degree))), employed as devops engineer / backend dev for a year. Know a lot about linux, am quite good at writing C and know a small to medium amount of C++.
- **ophiuchus2** - compsci, employed as an embedded linux software engineer (working on c++ applications). Automotive - telematics, radars, general ECU software, mostly c on 32 bit microcontrollers, some c++ on embedded linux. Consumer tech - c++ on embedded linux.
- **big_dinner** - last year of uni, fell for the hasklel meme (minimal experience in low-level C/C++ stuff), will help where possible

## Ideas

### cdcode's ideas

#### What I think the main aims should be
1) Implementation simplicity. Anyone should be able to create a basic client that can connect to any server within a week.
2) Efficiency. Server should be able to handle thousands of connected clients at once on a cheap vps. The client should also be lightweight and responsive. Having a bloatmaxxed electron client for the normies is fine but we should create (or endorse) a minimal GTK (?) client too.
3) Easy to understand. Keep meme tech and buzzwords to a minimum. Should be mostly client-server based and have a simple architecture that's easy to explain. People should feel like they understand how the software works and therefore can trust it.
3a) Make security and privacy completely visible to the user. Ideally there should be a tab/window that gives details of all the data the user is sharing with the server, what type of encryption is currently being used etc.
4) Focus on security and privacy, but only up to a reasonable level. Obviously we should aim to make the system as secure as possible but aiming to make it completely fed-proof just isn't realistic. The system should provide complete anonymity and privacy from other citizens connected to a server but we shouldn't claim that your privacy is going to be fully protected from the server owner / government.
5) Keep as little data on the server as possible. No IPs or client info in logs.
6) Configuration so that server owners can enable only the features they want. Perhaps even going as far as having an option to disable everything apart from plaintext chat. People should be able to host anything from simple IRC style text-only servers to full featured servers with rich text, image sending, file sharing, voice chat etc.

#### Message Expiration

This is entirely a personal opinion but I hate how most chat services try and store your messages until the end of time. Both for privacy reasons and because I think it's quite "anti-human". Our brains forget things all the time (and that's a good thing), it is very unnatural to be able to go back and read conversations from 10 years ago exactly as they happened, or to dig out some dirt on someone by finding something they said 15 years ago. People should be able to freely express what's on their mind at the time without it being permanently stored by a computer for all eternity.

I think that the server should try and delete messages as soon as possible. Perhaps the server should have a configurable holding period (e.g. 7 days) for which a message is stored. During this period clients can connect and retrieve the message, or it will get pushed to apps etc. Then after it gets deleted forever.

I think this would give a good balance. It wouldn't be like IRC where you can only retrieve messages when you're online, you would instead have a time window to retrieve them. The main benefit of course if that then the server only stores 7 days worth of history. If a fed seizes a drive from most other chat servers he will have everything you've ever said. With this approach he'd only get 7 days worth.

Clients will obviously locally save all messages they receive so this wouldn't affect them. So long as you connect to the server at least every 7 days you could keep an unlimited chat history locally if you so wanted.

(I think it would be good to build message pruning into the clients too though. People should be able to configure their client to say autodelete any messages older than 60 days to keep them from sitting around on their own drives).

### big_dinner

still thinkin

### ophiuchus

* use a pub/priv keypair as an identity system similar to ethereum
* this would eliminate the need to maintain a database of users on a particular server
* this would also allow messages to be signed by the user's id
* use a DHT to keep track of users / server id's & ip addresses
* when a user connects to a particular server, that server would register the user on the DHT
* would allow a global registry of searchable users / servers
* servers could register a name / ip address to remove the dependency on DNS
* (eventually) implement the signal encryption protocol for E2EE

## FAQ

### why use [gRPC](https://grpc.io/)?

The largest risk from using gRPC would be if google decides to chimp out and go full 1984, the only thing they could really do is delete the repo which wouldn't really affect us because we could just fork it to a private git server. grpc is really just an application layer protocol on top of http/2, there's no dependency on the google infrastructure. what i can tell from looking at the repo is it seems like it was a pet project by some backend team at google that just decided to go open source. the grpc implementation includes a custom http server which is optimized for performance, so everything (besides the database) is contained in a single application, which imo is pretty light weight compared to some other web stacks out there.

grpc uses protocol buffers as the message container, protocol buffers use a binary format which is much more efficient than json. again, i think this will give use huge performance gains when you have a public chat room with thousands of participants.

another problem with text based protocols (like json over websockets) is they make transfer of binary data more complicated. you have to use something like base64 encoding which increases the size of the data, and adds extra computation for encoding/decoding.

grpc is also a protocol that has already been developed & tested, saving us months of development time, and is very close to something i would design from scratch to meet our requirements. all we really need to do is define the rpc protocol in .proto files & developers can generate client or server interfaces in any language grpc supports, eliminating the need to develop client libraries in different programming languages.

### why is matrix bad?

the matrix protocol is bloated & over engineered, python was a poor choice for implementation as well.

this is an example of a matrix room event, taken from: https://matrix.org/docs/spec/client_server/r0.6.1#m-room-message

all of that data is transmitted, in addition to http request/response headers. this is insane, on top of that clients have to do some strange http long pull request to simulate real time communications, because http is not meant to be a real time protocol. my understanding is that matrix clients will send an http request, and the server just basically hangs until new data is available.

imagine you have a public chat room with 10000 users, all quickly sending 3-6 word messages, 90+% of the data transmitted to and from the matrix server is garbage, imagine having to pay a hosting provider for this.

the matrix protocol doesn't seem to work well with anonymous users, a lot of the normal matrix features require authentication. i want an application that supports anonymous public chat rooms.