Open Mikaela opened 3 years ago
Suggestion from IRC I sent upstream: https://github.com/ergochat/ergo/issues/1693
I guess this is the most privacy friendly and least logging that we can have with history still enabled. If history is disabled entirely, mobile users and webchatters kind of break and always-on becomes useless.
history:
enabled: true
# how many channel-specific events (messages, joins, parts) should be tracked per channel?
channel-length: 2048
# how many direct messages and notices should be tracked per user?
client-length: 256
# how long should we try to preserve messages?
autoresize-window: 3d
autoreplay-on-join: 0
# maximum number of CHATHISTORY messages that can be
# requested at once (0 disables support for CHATHISTORY)
chathistory-maxmessages: 100
# maximum number of messages that can be replayed at once during znc emulation
# (znc.in/playback, or automatic replay on initial reattach to a persistent client):
znc-maxmessages: 2048
restrictions:
# if this is set, messages older than this cannot be retrieved by anyone
# (and will eventually be deleted from persistent storage, if that's enabled)
expire-time: 1w
# if this is set, logged-in users cannot retrieve messages older than their
# account registration date, and logged-out users cannot retrieve messages
# older than their sign-on time (modulo grace-period, see below):
enforce-registration-date: false
# but if this is set, you can retrieve messages that are up to `grace-period`
# older than the above cutoff time. this is recommended to allow logged-out
# users to do session resumption / query history after disconnections.
grace-period: 1h
persistent:
enabled: true
unregistered-channels: false
registered-channels: "opt-in"
direct-messages: "opt-in"
retention:
allow-individual-delete: true
enable-account-indexing: true
tagmsg-storage:
default: false
whitelist:
- "+draft/react"
- "react"
Upstream syncing changed the previous comment/config a bit
- # if this is set, logged-in users cannot retrieve messages older than their
- # account registration date, and logged-out users cannot retrieve messages
- # older than their sign-on time (modulo grace-period, see below):
- enforce-registration-date: false
-
- # but if this is set, you can retrieve messages that are up to `grace-period`
- # older than the above cutoff time. this is recommended to allow logged-out
- # users to do session resumption / query history after disconnections.
+ # this restricts access to channel history (it can be overridden by channel
+ # owners). options are: 'none' (no restrictions), 'registration-time'
+ # (logged-in users cannot retrieve messages older than their account
+ # registration date, and anonymous users cannot retrieve messages older than
+ # their sign-on time, modulo the grace-period described below), and
+ # 'join-time' (users cannot retrieve messages older than the time they
+ # joined the channel, so only always-on clients can view history).
+ query-cutoff: 'none'
+
+ # if query-cutoff is set to 'registration-time', this allows retrieval
+ # of messages that are up to 'grace-period' older than the above cutoff.
+ # if you use 'registration-time', this is recommended to allow logged-out
+ # users to query history after disconnections.
👍🏻
We need to for server-side history. Testnet situation:
Persistence means that the messages are stored in mariadb and survive IRCd restart, otherwise they would only be stored in memory and could cause message loss for clients that aren't always connected and receive messages during IRCd restart (either planned or unplanned).
The feature can be disabled so that no conversations are logged, but then we lose the benefit of always-on/integrated bouncer and webchat users won't be able to see anything said before they connected etc.
I don't consider this as a dealbreaker though, because Ergo is still easier to maintain than the old Charybdis (upstream dead) and Atheme combination.
Are we tied by this promise or can we discuss with our users whether changing this part is acceptable?
This will always remain true.
Technically this can be overridden by local legislation of a membership country to a lower age and I would like to add or youth organization of party (Young Pirates)?
Will become username/nickname (same thing to Ergo)
(We don't have this configured on the Ergo testnet, see internal ticket #1)
Becomes plural as we will allow connecting to the same nickname from multiple IRC clients
or by you through use of
SETNAME
commandno change there
I guess this means that the user must appear on the channel in order to see and participate into discussions or their nickname is attached? Oh and vhosts that now become a manual task by opers upon request?
Do we actually store this and has this actually happened?
Yes
Here at least the last point changes, as we will gain new modes founder (+q), protected (+a) and halfop (+h), but I suppose it fits under "etc" and there is additional point of storing messages and nicknames for a week (see above unless changed).
In order to aid the migration, in production we have disabled nicknames and channels from expiring automatically as Ergo doesn't support it considering it as a misfeature. Upon user unregistration or request to do so all other information than nickname will still be removed however (nickname is persistent unique identifier and cannot be reregistered, this is a privacy/security feature as messages cannot be delivered to the wrong person should another person reuse the nickname and it will avoid inheriting old permissions). And the message sender and content is stored for a week unless configuration changed as noted above.
NickServ's INFO stays the same, while the output is changed a bit and integrates LISTCHANS which is removed, consent withdrawal becomes NickServ's UNREGISTER function. And withdrawal is possibly 7 days again.
What about people who connect to PirateIRC through relayed Telegram/Discord or bridged Matrix? Responsibility of the relay/bridge maintainer?
I imagine opening this issue will notify you too.