bug#68894: Prosody guix service required fixes.

["email@msavoritias.me" <email@msavoritias.me>]

[-- Attachment #1: Type: text/plain, Size: 4073 bytes --]

On 2/2/24 6:59 PM, Clément Lassieur wrote:
> On Fri, Feb 02 2024, email@msavoritias.me wrote:
>
>> Tried to write a system declaration that includes a prosody server.
>>
>> This bug aims to collect some bugs that were found and some features 
>> that were needed during writing.
>>
>> 1. The opaque-prosody-configuration as used in this example
>> https://guix.gnu.org/en/manual/devel/en/guix.html#index-prosody_002ecfg_002elua 
>>
>>
>> is broken. A workaround for now is adding raw-content as a field 
>> inside prosody-configuration.
> Indeed it seems like it's never worked.  The issue is: how do we know
> the pid-file if the user is using the raw config.  Sounds like we need a
> service, in that case, that works without pid-file.
>
>> 2. Prosody Includes a plugin installer now 
>> https://prosody.im/doc/installing_modules#using-the-installer
>>
>> so the plugin-directory here 
>> https://guix.gnu.org/en/manual/devel/en/guix.html#index-plugin_002dpaths 
>> needs to be changed to wrap the
>> module installer instead. since its easier to do that than manually 
>> copying modules.
>>
>> This is for modules that are not part of guix yet. Ideally imo an 
>> xmpp package file would be ideal to host any module that are packaged 
>> plus all
>> related software.
>>
>> 3. The modules enabled by default is outdated 
>> https://guix.gnu.org/en/manual/devel/en/guix.html#index-modules_002denabled 
>>
>>
>> A simple example vcard is deprecated now. also not sure if register 
>> should be default now since we have invites.
>>
>> 4. Security should be the default at this point
>>
>> https://guix.gnu.org/en/manual/devel/en/guix.html#index-c2s_002drequire_002dencryption_003f 
>>
>>
>> https://guix.gnu.org/en/manual/devel/en/guix.html#index-s2s_002drequire_002dencryption_003f 
>>
>>
>> https://guix.gnu.org/en/manual/devel/en/guix.html#index-s2s_002dsecure_002dauth_003f 
>>
>>
>> should be turned to true by default. all are already true by default 
>> upstream https://prosody.im/doc/s2s#security
>>
>> 5. The internal authentication here 
>> https://guix.gnu.org/en/manual/devel/en/guix.html#index-authentication
>>
>> should be internal_hashed as per default. 
>> https://prosody.im/doc/authentication it should never be plain.
>>
>> 6. Also a field for http_file_share is mandatory nowadays. see 
>> https://prosody.im/doc/modules/mod_http_file_share
>>
>> 7. room creation should be local for safety reasons
>> https://guix.gnu.org/en/manual/devel/en/guix.html#index-restrict_002droom_002dcreation 
>>
>>
>> nobody allows non local anymore.
>>
>> I plan to get to do this btw after i am done with the joinjabber
>> server at some point. 😄
> Cool, I'd be happy to review.  Thanks for this email.  It's a long time
> I haven't been using Prosody and unfortunately this Guile wrapper is a
> maintenance burden.  Even more so now that XMPP is less and less used.
>
> I wonder if it would be better to just support a minimal raw config.
>
> Clément

We could simplify it by a lot i think either way. Some ways could be:

1. Remove the opaque-configuration since it never worked for raw content 
which does already.

2. Remove the ssl config section here 
https://guix.gnu.org/en/manual/devel/en/guix.html#index-ssl

nobody should be touching these settings either way.


Personally I would prefer to have a scheme config but could go either 
way. I use xmpp as my only-full time messaging and own the xmpp guix room.

This prosody service is going to be used for joinjabber which you can 
see here btw https://codeberg.org/joinjabber/Infra

I also have talked about a guix self hosted xmpp server for a guix room 
so prosody would be used for that.

My thinking is that yeah the xmpp support in guix is not great and 
should be better. To that end in the short term I would be interested in 
updating/maintaining/adding xmpp software/services to guix.

Longer term as i wrote maybe also putting all xmpp stuff in a single 
file. but that can come later 😄 An xmpp team would also be something 
that could be done at some point.


Regards,

MSavoritias

[-- Attachment #2: Type: text/html, Size: 7106 bytes --]