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

[marclaporte]

In https://github.com/cypht-org/cypht/issues/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: https://github.com/cypht-org/cypht/pull/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: https://github.com/cypht-org/cypht/issues/216

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

Source: https://github.com/cypht-org/cypht/issues/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: https://github.com/cypht-org/cypht/issues/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.: https://github.com/cypht-org/cypht/issues/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: https://github.com/cypht-org/cypht/issues/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 https://github.com/cypht-org/cypht/issues/676.

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