E2EE Design Plan

That is an extremely broad question, but I guess I could partially answer it. I think E2EE channels, especially DM channels, largely won't affect the development speed of future feature implementations too much, as long as those features don't include the server being able to know the content of messages. Say for example Fluxer's markdown implementation adds new features, then E2EE isn't gonna slow anything down because it only applies once the messages have been decrypted. It would definitely increase development complexity though, since the limitations of E2EE channels (unscalability of the algorithm after a few hundreds of members) have to be taken into account when developing features. For example, if you had secret channels in communities, how would permissions be affected? What if you give to a role the permission to see that channel, but that role has more members than what the secret channel can accept? In this specific case you have to inform the user that that's not possible because the role has too many members. Now what if you do the same thing with a role that has just enough members to receive that permission, but then you add a member to that role? That's also not possible. So it means that to implement secret channels in communities, you'd have to, at minimum, add a piece of code in the "add role" and "update permissions" functionalities of the application to have additional non-happy paths. But, it's also important to highlight the fact that E2EE is not the focus of Fluxer in the first place. Most features pertain not to privacy of small groups, but to public communities: stuff like slash commands, forums, creator monetization etc. are pretty much completely separate concerns, and they likely won't have anything to do with E2EE channels inherently. (Though I may be wrong on that.) As for an estimation, well... I've never been able to estimate something I've never developed before, so someone else might be able to answer that... But I can't x')