1. Rooms:
   • id - unique room identifier
   • creator - user that created the room (and is an admin for it)
   • is_public - is the room for everyone or requires an invitation
   • alias - human readable room name (especially for public rooms) - should be unique
   • created_timestamp

Implemented in D351

This is already implemented.

Are we going to write LDAP authentication (which is not so simple considering multi-domain and username canonification) or we should use e.g. chwala API connection to authenticate the user?

Ok, have added some more info to the README.

(.. and perhaps this should all be added to the README.md to help others?)

That only means live reloading won't work, so not critical .. but also nicer to have.

Removed Kolab's nodejs and installed Node.js v6. Now it works. There's only one error now:

[error] backend port not found: :inotifywait

Aha. Hopefully you can install node.js from another source, then? Node.js is only required for development, so we shouldn't need to bump requirements in Winterfell as that only needs to contain runtime requirements AFAIK

Ouch. Indeed. As I had problems with installing npm on Kolab:Winterfell host (see T1967) I installed npm manually, but it looks like the version I installed does not support Node.js 0.12.8 which comes with Kolab.

So, this is the first project where we're gonna use postgres in Kolab?

Do we really need node/npm?

Already supported in Phoenix by default. See: http://www.phoenixframework.org/docs/configuration-for-ssl

Other ideas for this:

It would be nice to have a simple Makefile in the project's root that has entries like i18n so one can do make i18n and have the various mix commands run for you. I did similar for guam/egara to wrap the rebar commands, something similar here would be quite nice to avoid having to remember all the "right" steps for things like i18n generation.

To internationalize your Phoenix application, replace all the strings in your templates with the following function calls: