====== Chattaur - idea for a centralized AND p2p chat application ======
Centaur is half man half horse. Chattaur is half decentralized, half centralized communication and file sharing.
===== Goals =====
===== How it works =====
==== P2P ==== I don't understand how p2p works yet in terms of libp2p or ygdrassil or how dhts work without trackers, but via me learning how this works. If Alice's phone sees Bob's phone, they will communicate over local ad hoc wireless / bluetooth / ultrasonic / ir / usb cable. If Jane's phone has recently or currently can see Bob's phone, Alice can send a message to Bob via that phone, which will be relayed up to 7 times (seven degrees of separation etc) before being dropped OR asked to upload to central server relay.
==== Central server relay ==== Central servers can be found at a simple web address. chattaur.example.com. They accept POSTed x-www-url-form-encoded data with few fields to resist metadata data collection. server itself cannot see the message contents (e2ee) nor message recipient(s), it only knows that some IP gave it some message to hold for someone else later (like a dead drop). There is metadata on whether to replicate this message to other federated central servers. The server will automatically replicate messages among federated servers as part of distributed consensus, so if central server goes down, another server can get it.
Messages go in as unread. Clients can request unread messages, all time for all servers, or only from X time for X servers, with a client side limit of how many messages to get, and a max size of messages.
Clients then take these encrypted messages and attempt to decrypt them, decrypted ones are kept, undecryptable ones are discarded to /dev/null. If a message is decrypted, the client marks the message as read and transmits proof of this via a per-message-decryption-key that corresponds to 'this client has read this message'. The server then replicates that the message has been marked read, then deletes or archives or just lets the message sit based on server policy.
==== Message encryption ==== Messages are encrypted with OMEMO or Signal Protocol so even if transmitted over non TLS cleartext, they resist mitming and have perfect forward secrecy.
Messages have several keys
==== Existing software ==== Signal - centralized, technically open source but very hard to deploy your own server, won't federate Matrix - foss, federated, my personal fav. scary and complicated to self host though whatsapp - facebook proprietary locked down
chat over torrent? surely not retroshare / tox - never used smtp - am i reinventing smtp? deltachat does chat over email but leaks metadata a ton
==== Web standards ==== This software needs to be simple, simple to develop, simple to build, simple to deploy, simple to run, simple to use. Complexity needs to be kept to the minimum required to support users chatting over mobile devices and computers with e2ee and able to run their own federating servers without having to know how to configure anything. anything from an i686 desktop to a raspberry pi zero w to a t2.micro on aws should be able to run a server capable of relaying messages for users.
==== proglangs ==== For my implemenations, must be memory safe. I'm not a C wizard, so C is barred, full stop. Native level stuff can be assembler if we go down the nonmemsafe road. Systems like rust are welcome. JIT like F# is awesome. JS is someone else's client/server to implement, too breaky for me.
==== UI UX ==== terminal users are the least i care about from ux. they will find a way to write a script to call apis or POSTs directly, good for them.
my target user is someone who is used to smartphone messages android app circa 2010. you open it up, you have conversation view, you have threaded convos. you send messages, they send messages, you send files, images, etc. maybe fancy galleries and locations and signal style stuff can come later.
desktop clients must be native, must be. Images will be displayed inline, files will be offered up for download. Will support single window with chat list or msn messenger style chats if needed optionally.
==== Device compatibility ====
The protocol(s) this chat app uses need to hide the complexity from clients and simple enough that even humans hand crafting messages in postman can do it without massive pain. http or smtp doing headers with encrypted data could be a good starting point idk.
i have little idea how to start with this and no time, but if i'm rich someday i'm gonna make this app
==== Protocols ==== Looks like I want to do OMEMO. should I just do xmpp? Seems very complicated.
maybe use matrix idk.
smtp seems to use mail transfer agents aka mail relay.
<WRAP center round help 60%> How to do email but with metadata collection resistance and p2p mesh for intra-last-mile comms? </WRAP>