• (desktop) QmlCfg refers to stuff in resources/common/CommonConfig.qml, these things should not have different names

current api levels are at 28, this is rather exclusive. we know we can't go below 21, but the minimum possible api level is unknown. the symbols missing from 21 are __chk_poll and getrandom.

The bug that just won't die - now we're running into issues because we might end up reusing a (key,nonce) pair due to network outages. This happens because when we mark the pending message as used, we end up having no unused keys in the store.
Should be fairly easy to fix without even touching chainmail, but at this point I'm noticing enough footguns in that API that I'm likely to change it as well.

We have been following a heuristic to decide which functionality belongs in heraldcore, but I think it's worth discussing what exactly each sub-project is for. My understanding was that herald_common was mostly to keep type definitions in sync between the client and server, but there seem to be a number of types (such as the message status enums) that are only of interest to the client.

Should we create a page on the wiki documenting project scope?

Right now you could destroy someone's entire interaction with our system by sending them a message that fails to parse. If that happens, we should probably ignore it rather than forcing people to delete their accounts.

proposed flow:

connection init:

device sends "registration" or "login"

login:

device sends server global id it wants to login with
server sends 32 random bytes `bs`
device signs random bytes with key of said global id

registration:

device sends userid it wants to register with
if userid is free:
    server replies "OK"
    device sends public key
    server sends random bytes
    device signs bytes
otherwise:
   server replies "TAKEN"
   GOTO registration

Mobile adds desktop:

desktop: generate keypair, render public key to QR code
mobile: read QR code, sign public key, send signature to server

Desktop adds mobile:

desktop: generate keypair, sign public key, render keypair and signature to QR code
mobile: read QR code, check signature, write keys to disk, register with server

I expect we'll end up using these crates for QR-code stuff:

1. encoding: https://crates.io/crates/qrcodegen
2. decoding: https://crates.io/crates/quirs

The bug can be observed in commits after 7c57ebd. It is likely not a performance issue, as removing the heftier parts of the deleteContact function in ContactClickedPopup.mjs did not solve any issues.

Put your opinions below:

fuzzy search on contacts : substring is fine.

Messages : yes, and robust ☕️

This is a general issue for UI tasks which anyone can grab and implement.

• Configuration Menu
  Description : Add a gear icon button on the first toolbar in the contacts pane. Upon clicking this icon should launch a configuration popup with options for.

  • Name
  • Profile Picture (Optional)
  • UserID (Temporary placeholder)

• Chat View

  • Should render name and avatar of contact at the top of message view
  • Should Display splash if no user is currently selected
  • Should display splash screen if currently selected contact is deleted
  • Emoji, Attatchment, and Audio message buttons by the text entry area. *

*moved to sprint 2 electric boogaloo

• Side Bar

  • Search button
  • Render username when it changes

• Contact Chat Selection
  Description : Clicking on a contact in the contact section should open a chatview with the relevant conversationID or UserID.

• Visual Scaling Improvements

  • Currently there is no minimum window size
  • we would like the contactsView to take up the entire screen when below a certain threshold screenwidth.
  • Padding at the top of all the messages that doesn't look horrible
  • Scroll bar should be fixed size for each window size

• Refactors

  • Refactor all colors to global properties of the window which can be set in a config if necessary.
  • Refactor all anchors such that they only reference the anchor object once instead of serially.

• Polish

  • Color hashing from the global color scheme for contacts
  • Chatview polish. put the chatbar in a rectangle.
  • Animated (tasteful) transitions.

for alpha

• add contact flow sanity (also show in search view?)
• UI for opting into showing metadata to other user
• identity switcher
• "find user," search, etc--all the second-order contacts stuff

bryce's job

• registration/login screen
• default desktop right pane before any conversation is selected

not for alpha

• threading
• better recent view
• group search goes in header, not group pane
• link to message from another message
• link to channel from other channel (or dashboard)
• quote icon (once we have threading?)

low-pri teams features

• arbitrary channel categorization
• dashboard view (more complex)
• pinned messages?

possible redesign needs around teams:

• how do I see all messages related to a particular team at a glance?
• how do I ignore one team but track another really closely?
  (some combo of tags, filtering convo list, teams "contexts"?)

for example:

• limit number of kdf iterations for out of order message delivery
• limit max message size
• patch serde_cbor to limit maximum memory allocation

I'm not sure how best to pick these limits, so for now I'm going to leave TODO's in the code that reference this issue.

(probably partial) list of places in the code where this needs to be fixed:

• read_cbor
• send_cbor
• serde_cbor internals?
• unsent message storage
• registration loop
• login loop

Desired behavior: upon renaming a contact, the name at the top of the chatview, in the chatbar should change iff you are in chatting with the renamed contact.

Current behavior: The name in the chatbar changes temporarily to the new name of any contact that has had its name edited.

we should move some files into common qml so that mobile development is not redundant.

1. CommonConfig: should essentially be rewritten and moved into the libherald project. We should have more colors that are easy to override: see kirigami config.
2. Avatar: we should split this into avatar and avatar label/ label types.
3. integrate the units types from Kirigami. use these everywhere instead of DIP.
4. ChatBubble: parameterize and move it into common.

This would decrease both the reliability and bandwidth load on the server. GC strategy for blocks can be slower than for keys, so that'll help as well.

This Issue is for problems related to code cleanliness and sanitization. Currently we have no automated linter or checker for QML sanity. So we will just play it by eye. We should try to keep

• Main.qml
  Paul: no complaints

• ChatView.qml and Subcomponents
  Paul: thinking of complaints

• SideBar.qml and Subcomponents
  Paul: long declarative non visual components such as pop ups should be moved to separate files.

Mobile UI

Implementing the mobile ui from the existing wire frames and testing it on IOS simulator and android simulator. This should be done with platform switches in QT, and requires decoupling and rewriting a lot of the UI. this is almost an entirely separate project. Here is my suggested plan of attack.

1. Put all qml in its own directory, put that folder under a platform switch.
2. Make a new mobile ui QML platform directory, salvage as much of the desktop into that UI as possible.
3. Build the stack view from scratch.

it's currently ugly and terrible. mainline implementation is less ugly than the stupid bin, but it's a ways behind.

There are a lot of open questions re how best to handle encrypted group chat. The basic issue is a tradeoff in simplicity vs efficiency. I'm going to outline a couple proposals below:

Client-side fanout

There are a couple variants on this, and I'm not happy about any of them.
The basic idea is that group chats are a client-side detail, the server is only there for pki + offline delivery.
This will reliably be terrible for large groups, and makes even pairwise conversations awkward because our multi-device plans don't involve shared keys between devices, so actually all chats are group chats.

There are partial solutions here, such as generating a new key to encrypt your plaintext, then allowing the server to fanout the plaintext to everyone you want to send to while you reencrypt the key individually for each of them, but this is awkward and terrible. Let's not do it.

Sender keys

Sender keys are a decent solution to this - for every group chat, each device is associated with its own ratchet, known to all other members of the group. This means you can have full server-side fanout, saving the client CPU time and bandwidth. But, to maintain forward security, this requires additional key-generation by every device every time any conversation is updated, which is far from ideal. Also, doing this in a naive way would be vulnerable to spoofing attacks - if Alice, Bob, and Carol are all in a group together, they all know Bob's symmetric key for that group, so Alice could pretend to send messages as Bob.

Blockchain

Each channel is associated with its own blockchain. Hear me out, this is less stupid than it sounds. Each blockchain starts with some root shared-secret, and proceeds by proof-of-knowledge (I'll explain more below). Each block in this chain consists of:

a) A random N-byte nonce (where N is probably 32, but could be as low as 8)
b) The H-byte hash of a previous block, B (where H is probably 32 and shouldn't be lower than 16)
c) The generation of the current block, equal to B.c
d) The current length of the chain, equal to B.d + 1
e) A signature by a member of the group of (a, b, c, d)
f) Ciphertext of the intended message, encrypted in aead-fashion, where the associated data is (a,b,c,d) and the key is generated by kdf(a, B.b).

Every so often the chain restarts from a new random key that is sent via client-side fanout to preserve the self-healing properties of double ratchet. This also increments the generation of the new block, and contains the hash of a block in the previous generation.
Devices prefer to add new messages to the longest chain they currently know of, where any chain in a newer generation is longer than a chain in a previous generation.
Eventually blocks should be deleted, though exactly when to do this is not clear. It's probably safe to do so once every device has ack'd a downstream block, but that's not super clear to me.
It should definitely be safe to delete all blocks in generation g after everyone has ack'd a block in generation g+1.

We need them to be distinct from userid's in order to associate ratchet keys with (sender, conversation) pairs. This is probably going to change a bunch of things involving the DB, and then a few message types.

Baeo, assigning this to you since AFAIK client-side DB stuff is your wheelhouse. Reassign it if this isn't true.

basic premise:
users have associated public signing and KEM keys

the basic API of KEM is that you can, from a public key p, create a random shared secret, ss, alongside a ciphertext cs, which when combined with a secret key s can reconstruct the shared secret.

message format:

• random new ciphertext cs from KEM public key
• message encrypted using AES+padding or a stream cipher (I don't know enough to know which of these makes more sense)
• message metadata for the server

proposed KEM: ntruhps4096821
proposed sig: falcon-1024

what queries can the user make? some obvious ones:

• FetchKey(of: UserId, dev: DeviceId)
• ValidKeys(of: UserId)
• AllKeys(of: UserId)

Responses to these are fairly obvious, but I want to have a written spec in addition to the code.

Given the chainmail security model, it's pretty important that every device eventually receive every message that was sent to it. In order to do this, the server probably shouldn't delete messages until it's sure the client has received the message. Since file system writes can fail, I think we're going to want an ack on top of TCP after all.

steps to reproduce.

1. add two contacts
2. send two messages to each
3. swap between the conversations

all messages will disappear, and then reappear upon scrolling any amount. this is not desired behavior.

Currently, heraldcore uses the appropriate data directories on desktop platforms in the platform_dirs module.

There are implementations for Android and iOS, but they are placeholders and currently just use whatever $PWD Android and iOS happen to pass them. I believe there are well-defined (or at least, strongly suggested) application specific data directories on these platforms, but have not looked into exactly what they are.

• Message preview object should update replyIds
• Pairwise conversations should have the same pfp as the contact

User settings:

• Display name: syncs to all contacts
• Profile picture: syncs to all contacts
• Color: syncs to all contacts

Conversation settings (all sync to everyone in convo at time of change):

• Color
• Group name
• Group icon
• Expiration period
• Members added/removed/left

we should at least have an LRU cache for FS operations

Running list of features we want now or eventually or maybe (everyone shld add stuff)

Wants:

• Reacts of any emoji
• Color schemes
• Markdown in texts
• Read receipts

Maybe:

• Typing indicators
• Reminders
• Polls
• LaTeX in texts

this list is not complete

Things to do:
Contacts

• adding a new contact should be a new view of the right pane
• renaming contacts should probably also be a different popup
• bulk selection/deletion of contacts

Messages

• add replies
• message deletion
• open a view with extra information abt messages (time read, time sent)

Things that are borked:

• Reply button hitbox should be adjusted
• when a contact is deleted if a contact is being viewed the conversation_id should be set to that viewed contact immediately
• contacts search doesn't work until restart
• splash screen should not instantiate if contact deleted is not one currently being viewed

Panicking across ffi is undefined behavior. Since we almost certainly won't succeed in proving the code won't panic, we should just catch it.

Possible directions (not mutually exclusive):

• Expose NodeJS bindings (via neon): This is preferable to WebAssembly for a number of reasons. neon is fairly mature and makes heraldcore functionality drivable from Node.
• Expose Python bindings (via PyO3): We know from experience that this is easy, if a bit rough.
• Make heraldcore's public Rust API more ergonomic: This is something that we should do anyway.
• Manually expose C-API: This will be painful to do safely given how complex the data is (we can say this from experience), unless we lean heavily on serializing data structures to cross the FFI boundary.
• Expose C++ and JNI bindings (via rust_swig): I'm not sure how mature or robust rust_swing is, so this may not be the correct approach. jni-rs may be a better solution for JVM languages.
• Expose Lua bindings (via rlua). It's unclear how many people would use this.
• Use socket-based RPC like neovim. This is almost certainly something we want eventually, much easier to do safely than many of the other approaches, and something we have fairly extensive experience with.

I'm inclined to make this a UI detail rather than a persistent feature of a linear message history. If you have secrets worth hiding, then not having a record of having turned them on or off seems correct.

If we go this route, this can stay confined to libherald, if we don't and make them persistent, then there are a number of questions I would like to have answered about how these are going to be handled (e.g., are these events searchable in the global message search).

• s/ChatView/ConversationView
• s/ConversationView/ConversationsHome
• ChatViewHeader has an icon button id "drawerButton," but the button is actually a back arrow, not a drawer button
• CVFloatingButton: let's call this the "compose" button (named for what it does, not how it looks, in case the latter changes)
• can we call "configButton" instances "optionsButton" instead? (or if anyone likes config better I'll change the svg file to match) (I'm used to using "config" for dev stuff and "options" for user-visible stuff)

random other notes:

• opinion: if an alias is defined somewhere in the same file, the alias being a weird abbreviation seems totally fine (e.g. CVJS within ConversationView files)

Should make it essentially impossible for Eve to infer metadata without breaking TLS.

See #47. Again, I want clarity about whether these are persistent features of the linear message history, and whether or not they expire like normal messages

Probably worth doing eventually, though extremely low priority