search

ergochat / ergo

A modern IRC server (daemon/ircd) written in Go.
https://ergo.chat/
MIT License
2.26k stars 178 forks source link

programmable MOTD #1404

Open slingamn opened 3 years ago

slingamn commented 3 years ago

Suggestion from @kylef to show different MOTDs to different users, e.g., based on whether they're registered.

The performance implications of this seem pretty manageable. Right now we preread the actual MOTD file, but we synthesize new serialized IRC lines for it on every connection, e.g., if you have server-time you'll get them with a time tag, so this doesn't necessarily make things that much slower.

Questions: what kind of templating do we want to allow? What are the use cases?

kylef commented 3 years ago

The use-case was predominately to show unauthenticated users encouragement to register, f.e: 

372 kylef :- This server supports user presistence, thus it is
372 kylef :- encouraged that you register and authenticate with SASL.
372 kylef :- 
372 kylef :- To register with the server, you can use the following:
372 kylef :- 
372 kylef :-     /msg NickServ <password> [email]
372 kylef :- 
372 kylef :- - You may use multiple clients at the same time with your
372 kylef :-   account.
372 kylef :- - Disconnecting keeps you in channels, you may receive
372 kylef :-   the history upon reconnect.
372 kylef :- 
372 kylef :- There is no need to use a bouncer like ZNC or IRC Cloud
372 kylef :- with this server.
376 kylef :End of MOTD command

This MOTD can be useful for anonymous users to help convince them to register, but once you've registered the message becomes irrelevant as you are no longer in the target audience for the message.

kylef commented 3 years ago

This is potentially orthogonal to this issue, there may be a desire to internationalise the MOTD and be able to support multiple locales.

slingamn commented 3 years ago

One option would be a config boolean like enable-registration-faq; when set, it would (only for unregistered users) append a standard FAQ about registration and always-on to the MOTD. This would then get translated in Crowdin alongside other server messages. Like them, it would respect the draft/languages CAP and the languages.default config at runtime.

We could separately implement translation for the (operator-configurable, but static) MOTD by allowing, e.g., languages/ro-RO-motd.txt in the languages directory.