.pre-commit-config.yaml: replace ci.skip configuration with ci.autoupdate_schedule: quaterly

TODO: I am not happy especially with the end, this will require rewrite with better time.

.pre-commit-config.yaml

@@ -5,8 +5,11 @@
 # See https://pre-commit.com for more information
 # See https://pre-commit.ci for more information
 ci:
-  # Attempts to use networking and fails at name resolution
-  skip: [bundler-audit]
+  # I don't need so many duplicated notifications on the same thing as I keep
+  # autoupdating manually too. Besides it just creates extra branch I never
+  # touch.
+  # https://github.com/pre-commit-ci/issues/issues/83
+  autoupdate_schedule: quarterly
 
 repos:
   - repo: https://github.com/pre-commit/pre-commit-hooks
@@ -31,20 +34,13 @@ repos:
         args: [--update-only, --notitle]
 
   - repo: https://github.com/python-jsonschema/check-jsonschema
-    rev: 0.23.0
+    rev: 0.23.1
     hooks:
       - id: check-dependabot
       - id: check-github-actions
       - id: check-github-workflows
       - id: check-gitlab-ci
 
-  - repo: https://github.com/jumanjihouse/pre-commit-hooks
-    rev: 3.0.0
-    hooks:
-      - id: bundler-audit
-      # https://github.com/jumanjihouse/pre-commit-hooks/issues/111
-      #- id: check-mailmap
-
   - repo: https://github.com/fsfe/reuse-tool
     rev: v1.1.2
     hooks:

Gemfile.lock

@@ -1,7 +1,7 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    activesupport (7.0.4.3)
+    activesupport (7.0.5)
       concurrent-ruby (~> 1.0, >= 1.0.2)
       i18n (>= 1.6, < 2)
       minitest (>= 5.1)
@@ -86,7 +86,7 @@ GEM
       activesupport (>= 2)
       nokogiri (>= 1.4)
     http_parser.rb (0.8.0)
-    i18n (1.13.0)
+    i18n (1.14.1)
       concurrent-ruby (~> 1.0)
     jekyll (3.9.3)
       addressable (~> 2.4)
@@ -210,7 +210,7 @@ GEM
       jekyll-feed (~> 0.9)
       jekyll-seo-tag (~> 2.1)
     minitest (5.18.0)
-    nokogiri (1.15.1-x86_64-linux)
+    nokogiri (1.15.2-x86_64-linux)
       racc (~> 1.4)
     octokit (4.25.1)
       faraday (>= 1, < 3)

lfs-media

@@ -1 +1 @@
-Subproject commit ffc674166b96f5b66b02b98f6f05c42f5c00fc71
+Subproject commit 4e9ec84cde789b756992b30b880b9d3cd8e4b417

pages/discuss.markdown

@@ -52,6 +52,10 @@ I do hope to be able to grow this list in the future.
 [twitch]: https://twitch.tv/
 [xmpp]: https://xmpp.org/
 
+**_NOTICE ON LOG AVAILABILITY!_** The logging and history visiblity varies by protocol and thus
+users joining in the future could see messages up to one year or longer in the
+past.
+
 ---
 
 <!-- START doctoc generated TOC please keep comment here to allow auto update -->

pages/matrix.markdown

@@ -45,6 +45,7 @@ links._
   - [How about DAG splits?](#how-about-dag-splits)
 - [Can I have a non-federated room?](#can-i-have-a-non-federated-room)
 - [What exactly is room upgrading?](#what-exactly-is-room-upgrading)
+- [How should I configure my Matrix room?](#how-should-i-configure-my-matrix-room)
 - [What are these idlekicks for inactivity, why are they for?](#what-are-these-idlekicks-for-inactivity-why-are-they-for)
   - [But the relaybots look so ugly](#but-the-relaybots-look-so-ugly)
 - [I am told that I should Matrixify my IRC channel, what does that mean?](#i-am-told-that-i-should-matrixify-my-irc-channel-what-does-that-mean)
@@ -241,6 +242,59 @@ See also [Matrix Specification on room versions](https://spec.matrix.org/latest/
 or `CTRL-F` this page for `/upgraderoom {{site.matrixLatestRoomVersion}}`
 (Element Web command to perform the upgrade).
 
+### How should I configure my Matrix room?
+
+I think there are three important questions that will each require
+consideration:
+
+- Do you want to encrypt the room?
+  - Is the room public? If so, encryption will just cause strange issues for
+    you to troubleshoot and hinder the purpouse of the channel (which you
+    should also consider).
+  - Do you want to use bridges or integrations? Unless you or someone close to
+    you is selfhosting those, they are untrusted and will defeat the point of
+    encryption, so don't encrypt.
+  - Does the room only contain trustworthy participants? Encryption may be
+    your friend.
+- Who can see the room history?
+  - If you want everyone to be able to read it, choose everyone or
+    `world_readable`.
+  - If you want everyone who has joined the room (and also crawler bots that
+    publish the history further), choose members-only or `shared`.
+  - If you want users to see the history since they were invited to the room,
+    select `invited`
+  - Otherwise select `joined` to have users only see history since they
+    joined.
+- Who can join the room? This is self-explanatory so probably everyone or
+  invited users.
+  - However my favourite rules are `knock` so that users have to ask for permission to
+    join and `knock_restricted` so users in trusted rooms can join directly
+    without knocking.
+
+If you choose to make your room public as in joinable by anyone and history
+viewable by members joining in the future, _please communicate that in the room
+topic_.
+
+> Some projects may wish to log their channels publicly, if you do so the logging should be authorised by the channel owners and users in the channel should be notified (through for instance the topic, entry message, or similar) that public logging is taking place. Channel operators should consider ways for users to make unlogged comments and a process for requesting the removal of certain logs.
+
+- [Libera.Chat policies on public logging](https://libera.chat/policies/#public-logging) which I consider as good advice regarldess of being written for IRC rather than Matrix.
+
+Sample events for `/devtools`
+
+```json5
+// m.room.join_rules
+{
+  join_rule: "knock",
+}
+```
+
+```json5
+// m.room.history_visibility
+{
+  history_visibility: "invited",
+}
+```
+
 ### What are these idlekicks for inactivity, why are they for?
 
 Some Matrix rooms decide to connect their channel to IRC maintaining the same users on both sides, which can be heavy for the IRC network depending on bridge type of which there are three "major" variants: