We need to have the easiest possible way for users to get their own self-hosted XMPP. I see three main usage scenarios: 1. Home usage for family and friends. This assumes more relaxed security constrains like an ability to see all users on a server and start chatting without authorization. 2. A small organization/company and for this you may need things like LDAP, password policy, invites,monitoring. 3. Public server with open registration that needs for more restrictions like spam reporting, RBL or throttling.
Mixing of the usage scenarios may create problems. I think that by default the Prosody should assume the home usage and be as much easy to install as possible. You created the Snikket to address the problem to create a ready to use XMPP server for home usage. This is a great product and the first my plea is to port some features into the vanilla Prosody build. For example the csi_simple and http_share may be also added to the Prosody's default bundle. It would be great to officially support other scenarios and have some ready to use configurations or builds. For the public Prosody server I found that Jabber.fr graciously published their config https://jabberfr.org/prosody.cfg.lua. It worth to at least mention it in a documentation. I saw recommendations to use the Prosody for personal usage, the Openfire for a small company and the ejabberd for a public server. This kind of makes sense but of course the Prosody successfully used in all the scenarios. Also, as far I understood, the Metronome fork of Prosody is specifically intended for public servers. It has things like Password Reset API that makes a little sense for home users. For most users VPS or minicomputer like RPi or BananaPi may be too expensive. The simplest way is to install the Prosody right on a WiFi router as the cheapest hardware that everyone have. This have obvious drawbacks but still may be preferable for many users especially in developed countries. And I'm specifically working on the simplifying self-hosting on OpenWrt. The OpenWrt has an outdated Prosody version v0.11. I asked its maintainer for an upgrade but didn't receive any reply and he has no activity in a while. Can you make the OpenWrt officially supported and take a maintainership over the package? https://github.com/openwrt/packages/blob/master/net/prosody/ I'll try to send an upgrade PR myself but anyway no one can really review it. In general, I wish to make the Prosody easy to install and configure for a regular user. And one of the problems is that a user may not know or afraid to use terminal and SSH. So ideally the Prosody needs to have zero configuration and some GUI. This is needed not only for OpenWrt but also for a Debian-based FreedomBox self-hosting solution. Now let's check if we can achieve this. The prosody.cfg.lua itself is good but can be improved with more defaults and samples. I see that mod_mam and mod_turn_external are installed but not enabled by default. They are useful and should be enabled by default it with a config sample. For the mod_turn_external there are some config options added but commented out like turn_external_host. The TURN server can't have a default value, but maybe the STUN server we may pre-configure to a some public server like the stun.cloudflare.com:3478. Given the typical usage scenario it may be quite often that the TURN is also installed on the same host. So maybe the TURN default value can be changed to localhost? To the list of modules we need to add the mod_vjud to search for users. This is an essential functionality and config option needs to be added with vjud_mode="all". The storage by default can be set to SQLite3. The libsqlite is less than 1mb and today is pre-installed on many platforms, even many routers like Turris. The logging by default is configured like this: log = { info = "prosody.log"; -- Change 'info' to 'debug' for verbose logging error = "prosody.err"; -- "*syslog"; -- Uncomment this for logging to syslog -- "*console"; -- Log to the console, useful for debugging when running in the foreground } This creates two (!) log files that will eat a disk space. Instead logs should be written to syslog or just to console. Now the logs be processed by the systemd-journald or procd/logd on OpenWrt. The console logging is easier but it needs to use the syslog prefix to indicate a loglevel i.e. <3> for info. The Arch AUR package of Prosody removes the file logging and enables the syslog instead. But it will send all messages including debug so the default logging needs to be LIMITTED: log = { { levels = { min = "info" }, to="syslog" }; } Tools like journalctl, lnav and GUI (Luci) allows to much easier check logs that with a plain file. The certificates by default are loaded from /etc/prosody/certs/. We may simplify things if scan the /etc/ssl/private folder. This is a default place where the acme.sh on OpenWrt saves generated certs. The Prosody may upload all the found certs and then lookup by SNI which is needed for a TLS client. Then we won't need to specify a cert for each virtual host. It's not so easy to implement as it sounds, so I'll create a separate detailed ticket on this later. On my PC with Ubuntu I configured a local Prosody with a self-signed cert generated by the prosodyctl. I had to edit the /var/lib/prosody/localhost.cnf and add subdomains for components like: otherName.2 = 1.3.6.1.5.5.7.8.7;IA5STRING:chat.localhost otherName.3 = 1.3.6.1.5.5.7.8.7;IA5STRING:share.localhost otherName.4 = 1.3.6.1.5.5.7.8.7;IA5STRING:proxy.localhost otherName.5 = 1.3.6.1.5.5.7.8.7;IA5STRING:pubsub.localhost otherName.6 = 1.3.6.1.5.5.7.8.7;IA5STRING:users.localhost So maybe you can add subdomains by default to the https://hg.prosody.im/trunk/file/tip/certs/localhost.cnf The ssl block with a path to cert also was needed to make this all working: ssl = { key = "/var/lib/prosody/localhost.key"; certificate = "/var/lib/prosody/localhost.crt"; protocol = "tlsv1_1+"; } It would be great to add it (even commented) to the prosody.cfg.lua. VirtualHost is the main point where a user needs to make a manual configuration. The default is just "localhost" and there is example.com in the conf.avail. You can make the Prosody running without specifying the domain. Is it possible to make some kind of "default" vhost? It will accept any domain or use that returned by hostname command. The vhost config needs to have all components already configured and ready to use e.g.: Component "chat.example.com" "muc" Component "share.example.com" "http_file_share" Component "pubsub.example.com" "pubsub" Component "proxy.example.com" "proxy65" Component "users.example.com" "vjud" Is it required to specify the main domain example.com? Can we just use something like "chat." and append the main vhost domain? The subdomain names are not standardized and differs by manuals and servers. E.g. for muc the Snikket uses "groups", other uses "conference", "muc", "chatrooms" etc. I think the "chat" is simple and obvious, and it would be better to use it. But the "conference" looks like used more often. Similarly, the "share" would be better than "upload" (and download?), "users" is better than "search". This will make all manuals and tutorials more compatible. The component names also may confuse. The "File Transfer Proxy" is easier to understand than "SOCKS5 bytestream proxy". This may look like a minor thing for you but not for newcomers. They are also frustrated why they need to create the subdomains in their DNS. Is it possible to avoid this? Ideally the XMPP should work without a DNS at all by just an IP. Last problem is user creation that needs for a GUI. A user can be created from a command line or by an admin user via adhoc from a client. But the admin user itself needs to be created and added to admins in the config. To avoid editing of the config we may create the admin user on installation. It may have a predefined password or a random printed to logs (but they may be cleaned) or a file. The OpenWrt's Luci admin panel allows to see logs and a file. Then a user can see the password and login to create own user account and other needed users. The problem remains that the user can't assign itself as an admin unless edits the config. Is it possible to make a user an admin with adhocs? Also, the admin user needs for domain part e.g. [email protected]. We may enable registration to make the first registered user receive the admin right and disable regs. We'll need to implement the default vhost first to be able to connect. I thought to create a Luci app for Prosody to edit vhosts and add users. This will be hacky but possible and still I don't see a reason to do that. The Prosody already have a web GUI with mod_admin_web that just renders adhocs in HTML. I think that this is great tool and even can be hosted on external site with more advanced UI. As a POC I started the admin panel in a separate repo https://github.com/yurt-page/xmpp_admin_web Basically if we can solve the problem with creation of a first admin user then just adhocs will solve all other problems. Some adhocs may be difficult to add like a command to create vhost and configure it. I hope that step by step we may achieve the simplification and Prosody instances will grow exponentially. As a side note there are no so many of video tutorials. And half of them is configuring the Proxmox and PsotgreSQL. If anyone from the community can make a good tutorials that would be just great. Thank you, Sergey -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prosody-dev/83944b9f-dcbd-4da7-a222-b5b98459f60cn%40googlegroups.com.
