State of the project

[kra-mo]

I am going to be stepping away from development for the foreseeable future, so for whomever takes up the work, I want to document the current state of the project. Feel free to open individual issues or edit this one or whatever :)

Project structure

This client is split into two. openemail/core is meant to be a standalone pure Python project without a dependency on PyGObject or the rest of the code. This should be split out into a library like PyMailHTTPS or similar. The only reason I haven't yet is because it was easier to iterate on it this way, but I'm sure it'd also be fine with a monorepo or submodules or something :) The rest is a PyGObject application with openemail/gtk being roughly view and openemail/ (wrapping much of openemail/core) viewmodel.

Me and @jamiethecat definitely experimented with a lot of things in PyGObject while developing the app, so there may be some unconventional things here and there e.g. a custom subclass of GObject.Property (openemail/_property.py), feel free to get rid of these if you judge them stupid. They were mostly just for convenience.

What I Would Work On

Whether you think any of this is actually necessary, or whether it should be done the way I outlined is up to you. Nothing here is sorted by importance/priority either. I also can't promise to be 100% accurate.

It's also probably a good idea to build the app, look through the code and try to hack on it at least a bit before jumping into all you're about to read because it's a lot :)

Things to Do

• Use Secret directly instead of keyring. The latter was chosen only so that I could run the client on macOS. This would be a "good first issue".
• Editing messages. As far as I understand, this is technically just discarding and re-sending them with some metadata being kept, so this should also be easy and probably fun to do.
• Forwarding, when there is a clear definition for it in the protocol.
• Registration is only possible through open.email. The user should be able to pick an instance at the time of registration. See the other clients or e.g. the Mastodon mobile apps for reference.
• The "Automatically download attachments smaller than" setting from the Mac client (which I used as a baseline for the feature set of this app) is missing. I'm not sure we need this setting at all, I mean some serious UX direction would be good for the project in general, but as long as we have it there, we should here as well.
• client: Don’t split broadcasts #5 (really small PR) should be rebased and merged once it actually works. It was decided to not split broadcasts up so that they could be downloaded using any web browser or similar. But sending large attachments did not actually work on the open.email server maybe because of Cloudflare. This is something to fix on the server side before merging.
• Only notifications should be fetched periodically (or at least frequently). Syncing everything should only happen when needed (or just more rarely).
• Support for what the protocol calls "streams".
• Support for address expansions.

Things to Improve

• There is a draft PR open (window: Get rid of the main stack #38) to reuse as much widgets as possible across views for performance reasons. This is something I still think would be valuable and would help the app scale, although I'm not sure how salvageable that PR is specifically. Maybe just use it for inspiration.
• Is there a better way to handle when the offline banner shows up? I feel like the current heuristic isn't totally ideal, although it seems to work and is free to "poll". The banner in general was inspired by Fractal.
• core.model.Profile uses dataclasses.fields to introspect the types of its fields to avoid duplication. It would maybe be good to use something like annotationlib instead if possible because I think what I'm doing now is going away in the __future__(?) ;)
• core.model.Address didn't used to actually subclass str, just define __str__(). Because of this, there are a couple of places in the code where I'm still doing conversions between Addresses and strs. I tried getting rid of this before but it wasn't as straightforward as I thought, so maybe it's not possible? But it's something I'd investigate.
• I think the msg and message variable names are used fairly inconsistently across the code. I migrated away from message so that it wouldn't conflict with the module name, but some messages still exist I believe, though maybe not.

Things to Fix

• Deletion is broken. I don't know why, where, or how to fix it. But I changed the semantics of discard, delete, etc. quite a bit and now I'm not sure what works and what doesn't anymore. Local data sometimes doesn't seem to get deleted(?), a message may be discarded but not deleted locally... I'm not sure what's wrong. Maybe it's an easy fix? But it definitely can't be bisected because it broke while I was changing how it actually works so there is no good commit.
• For some reason, the status page is slightly misaligned between message pages/contacts.

Enhancements

• Would be convenient if there was a button to send a new message to someone on their profile page. Also a "good first issue".
• Multi-selection for messages. This would be a really nice one but it would require a slight rework of the message list UI and I'm not sure how it would work from a UX perspective. Probably a dedicated selection/edit mode.
• Would be cool if the numeric badges in the sidebar crossfaded.
• For drafts without a subject, something like "No Subject" should be shown. But we'd probably need better separation between model and viewmodel for this.
• AdwTaggedEntry didn't happen (yet), so we couldn't do pills for recipients like the Mac client. It would be nice to have this, as proud as I am about the current autocompletion :)