Privacy policy update for Ergo

[Mikaela]

When you provide information to PirateIRC that information will not be used for any purposes other than those described on this page.

👍🏻

The network does not log your conversations etc and we never will.

We need to for server-side history. Testnet situation:

• registered channel messages are opt-out of persistent history for 1 week
• registered direct messages are opt-out of persistent history for 1 week
• users are allowed to delete their own messages
• account indexing is enabled

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?

We have no intention or desire to try and profit from your use of the network.

This will always remain true.

If you an EU citizen under 16 years of age please do not register with NickServ without sponsorship of a Party.

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)?

By connecting to PirateIRC you consent that the following information may be collected when you connect or register with NickServ:

• Username

Will become username/nickname (same thing to Ergo)

• Email address

(We don't have this configured on the Ergo testnet, see internal ticket #1)

• Last/current IP address

Becomes plural as we will allow connecting to the same nickname from multiple IRC clients

• Your "real name" as provided by your IRC client

or by you through use of SETNAME command

• Registration date

no change there

• Public group/party affiliation

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?

• Details of your parental consent if your membership is sponsored by a Party

Do we actually store this and has this actually happened?

• Elevated or reduced permissions assigned to you by other users on the network

Yes

We collect this information in order to operate the network and provide essential services. Your information may be used for the following functions:

• To allow you to authenticate with your PirateIRC account or reset the associated password.
• To allow network operators to contact you regarding issues related to PirateIRC.
• To allow network operators to maintain the security of the network.
• To allow channel operators to customise elevated access within their channels (Operator, Voice etc) or restrict you from participating in their discussions. (Bans, Mutes etc)

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).

User information associated with NickServ accounts will be removed after 120 days of inactivity or when you withdraw your consent. Network operators may place a hold on this automated removal by request or if they believe that doing so is essential to maintain network security. In the event that a hold is placed you will be informed via your provided email address how long the hold will be in place and why it was initiated. If you do not register with NickServ this data is removed when you disconnect from PirateIRC.

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.

At any time an authenticated user may use Nickserv's INFO and LISTCHANS functions to display all relevant personal information held by the network. To withdraw consent you may use Nickserv's DROP function. In the event that you have not yet created an account you have assumed to have withdrawn your consent by disconnecting from the network.

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?

Please direct all related requests and questions to Fletcher Boyd (PGP: 5BAE 331E 9B57 3709 6E6A 19ED 85B8 D7B6 60D5 D803)

I imagine opening this issue will notify you too.

[Mikaela]

Suggestion from IRC I sent upstream: ergochat/ergo#1693

[Mikaela]

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"

[Mikaela]

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.