What should be the scope of Cypht?: Minimalistic? kitchen sink? Something in the middle?

[marclaporte]

In #1009, @jonocodes asks:

also please point me to "minimalist" values of the project so I can understand it better.

Thank you for this very important question.

I don't know of a foundational document, but here are examples of what I have seen since I started getting involved:

• "Pages are comprised of only 3 HTTP requests totaling ~50KB (gzipped)"
• "With standard browser caching, pages tend to transfer 10 to 20 KB"
• "On the server, page request processing peaks at around 4-5MB of memory."
• "There is a build process that pre-calculates module assignments and combines and compresses page assets, making the production version of your site as fast as possible."
• "The HTML5 Page structure is semantic and simple"

Source: https://www.cypht.org/features.html

Some feedback from @dumblob (not active at the moment, but IMO has been the best overall contributor to the list of issues: https://github.com/cypht-org/cypht/issues):

• "Before anyone will dive into to the source I wonder whether ~3.7k SLOC library is worth including?"
• "or at least in the sense of the library size."

Source: #543

• "Because Cypht is lightweight not just by itself, but more importantly bandwidth-wise on client, I'd say the next most important parameter really is size."
• "in this case it's mainly the ~40k end users on low bandwidth connections - Cypht currently sends maybe about 140k JS on first connection"

Source: #216

• "so that it doesn't bloat the user interface"
• "but that takes more time and would be more bloated in implementation"

Source: #13

• "Overall it feels kind of bulky"
• "As I noted above, I actually don't think it's a good fit - it does much more than Cypht needs and is unnecessarily bulky."

Source: #351

Cypht is a do-ocracy so it's up to the active contributors to decide where the project is headed. What is in vs out of scope of Cypht? Ex.: #382. I am more on the side of more features: https://tiki.org/FLOSS-Web-Application-with-the-most-built-in-features and whatever is out of scope for Cypht, we'll just put in Tiki. We can move/copy code back and forth given it's the same license: #333. So people can use Cypht, and the day they want more features, they will have an easy migration. Ex.:

• https://doc.tiki.org/Email-filters
• https://doc.tiki.org/Email-bounce-handling
• https://doc.tiki.org/Email-folders-Tracker-Field
• https://doc.tiki.org/CardDAV
• https://doc.tiki.org/CalDAV
• https://doc.tiki.org/Calendar-Invitations-by-email
• https://doc.tiki.org/Disposable-email-detection now for registration but could easily be used for webmail

See also: https://wikisuite.org/Webmail-and-groupware-comparison

What makes Cypht unique in the ecosystem? Where do we want it to go?

I see a lot of potential for Cypht as a "pluggable webmail" for PHP projects. Cypht is already the most popular webmail here: https://packagist.org/?query=webmail. So whatever we do for Tiki, we'll make it easy for other projects to do as well. More projects leveraging Cypht will lead to more innovation.

I think the "aggregate all your emails" aspect is fantastic. So this is something we should continue to improve. The main lacking feature is #676.

What do YOU think should be the future of Cypht? :-)

[marclaporte]

I found another:

In 2019, Jason described Cypht as a "Lightweight Open Source webmail written in PHP and JavaScript"

Source: 2a42855

[nekohayo]

Depends on whether you are making a product with a defined UX, or a platform ingredient only meant to be used for expert integration.

Also depends on what you mean by minimalism. The UI & UX? The configurability? Or just the size of the codebase (irrelevant, in my opinion).

If talking about the UI and configurability, I would say that trying to stick to a designed solution with a restrained scope, and automating as much complexity as possible, would be the more sustainable approach compared to going with extreme configurability. In comparison, the maximalist "kitchen sink" approach would paint you into an expensive-to-maintain corner that you can never back away from because of XKCD 1172.

Further reading for those unfamiliar with this logic:

• https://ometer.com/preferences.html
• https://www.joelonsoftware.com/2000/04/12/choices/
• https://www.invisionapp.com/inside-design/40-40-20-design-process/

[jonocodes]

Thanks for the historical discussions and commits. It helps with the context of the early project goals.

I am just sharing my perspective on these things to help give context on my motives.

Clearly minimalism can be applied to many aspects of a project and there are lots of philosophies about what to do where.

I'll add a kind of minimalism that I like. You mentioned having simple easy to follow code. This I appreciate. For me, developer experience is key - especially if you want to retain and attract new contributors. This means code is easy to follow, well documented, easy to spin up.

One way of simplifying the code is to write less of it. In open source most common problems are solved - and often in many different ways. If I need a templating system for example it can be temping to make my own because it seems simple enough, but there are dozens of projects who have solved this thoroughly. I don't need to become an expert in the domain, or need to design my own system, or figure out corner cases, or even write tests for it. So I don't bother reinventing the wheel. I just look through a few of the most active templating libraries and pick one. If I don't like it in the future I can swap it out or custom code one if needed. But it means I can start using the feature without having to put in all the work upfront. And move on to focusing on the features that are unique to my project.

When a new dev enters the project they can follow the existing community and docs for that templating system. And if it's a common library they may have even used it before.

Much of the referenced discussions focus on front end of features. In terms of bandwidth use, having a lightweight frontend is great. I think this is particularly good for shoddy mobile connections.

However, unlike frontend payloads, including backend libraries or increasing the docker image is not itself correlated to degraded performance.

But getting back to minimizing the frontend, it's often not worth it if it causes compromises in functionality. If it means using a bit more bandwidth to get a good mobile layout or mobile friendly widgets, I would favor those first. Of course you have to find a good middle ground, but if the app is not intuitive you don't need to save the users bandwidth because they will leave the project anyway.

[TheDigitalOrchard]

I haven't read this full discussion above, but I'll share my reason for jumping into the Cypht ship...

I was looking for a way to integrate email INTO my existing applications. Rather than build everything myself, I began to explore open-source PHP-based options, and found Cypht. The project has a very friendly feel about it, so I've enjoyed my time here contributing what I can.

My needs include multi-user support, where a single installation (of Cypht) can be used in a multi-user environment where a given user is already authenticated by the larger system and automatically "logged in" to Cypht when they access the app. The bootstrapping logic via environment variables and front controller already mostly satisfy this requirement, so I'm hopeful.

My hope is that Cypht maintains a clean, low-opinionated visual design, customizable by installing a modular "theme" package. I don't want to see the user interface be too bloated or highly opinionated. (I've been following the @runbox project where they are building "the world's fastest" webmail client, and I'm not happy with the results of what I've been seeing. Way too opinionated.)

Thanks for your hard work here.

[marclaporte]

@jonocodes @TheDigitalOrchard @dumblob @nekohayo

Let's meet @jasonmunro and ask him:
https://github.com/cypht-org/cypht/wiki/AMA-Jason-Munro

[marclaporte]

So Jason and others expressed their thoughts during https://github.com/cypht-org/cypht/wiki/AMA-Jason-Munro (recording is available)