| 2023-10-30 00:02:41 +0100 | ectospasm | (~ectospasm@user/ectospasm) |
| 2023-10-30 00:46:59 +0100 | tremon | (~tremon@83.80.159.219) (Quit: getting boxed in) |
| 2023-10-30 03:13:11 +0100 | hightower2 | (~hightower@141-136-253-109.dsl.iskon.hr) (Read error: Connection reset by peer) |
| 2023-10-30 03:14:56 +0100 | hightower2 | (~hightower@141-136-253-109.dsl.iskon.hr) |
| 2023-10-30 04:07:21 +0100 | td_ | (~td@i53870907.versanet.de) (Ping timeout: 260 seconds) |
| 2023-10-30 04:09:00 +0100 | td_ | (~td@i5387092F.versanet.de) |
| 2023-10-30 07:29:32 +0100 | chomwitt | (~chomwitt@2a02:587:7a01:8f00:1ac0:4dff:fedb:a3f1) |
| 2023-10-30 08:44:29 +0100 | hightower3 | (~hightower@141-136-161-29.dsl.iskon.hr) |
| 2023-10-30 08:46:47 +0100 | <haskellbridge> | <Solid> Let's keep this channel at least vaguely on-topic, shall we? Something like this warsants a ban for spam next time, I think. |
| 2023-10-30 08:47:20 +0100 | hightower2 | (~hightower@141-136-253-109.dsl.iskon.hr) (Ping timeout: 272 seconds) |
| 2023-10-30 08:48:01 +0100 | <haskellbridge> | <Solid> liskin: Well, same idea, different execution. Something that seems to be quite common when comparing our setups, if I remember the last ZuriHac well enough :) |
| 2023-10-30 09:34:49 +0100 | derpyxdhs | (~Thunderbi@user/derpyxdhs) |
| 2023-10-30 09:47:41 +0100 | derpyxdhs | (~Thunderbi@user/derpyxdhs) (Quit: derpyxdhs) |
| 2023-10-30 10:35:47 +0100 | <liskin> | Yeah, although I probably remember even less than you (there was one additional ZuriHac for me to rewrite my memories) |
| 2023-10-30 11:02:38 +0100 | <haskellbridge> | <Solid> Let's keep this channel at least vaguely on-topic, shall we? Something like this warrants a ban for spam next time, I think. |
| 2023-10-30 11:03:02 +0100 | <haskellbridge> | <Solid> Still bummed I couldn't attend that :/ Hopefully next year! |
| 2023-10-30 12:03:38 +0100 | srk_ | (~sorki@user/srk) |
| 2023-10-30 12:06:59 +0100 | srk | (~sorki@user/srk) (Ping timeout: 255 seconds) |
| 2023-10-30 12:06:59 +0100 | srk_ | srk |
| 2023-10-30 12:19:30 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:dad:ed4f:4ccc:4064) (Ping timeout: 272 seconds) |
| 2023-10-30 12:20:22 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) |
| 2023-10-30 12:26:39 +0100 | cfricke | (~cfricke@user/cfricke) |
| 2023-10-30 12:31:56 +0100 | srk_ | (~sorki@user/srk) |
| 2023-10-30 12:34:21 +0100 | srk | (~sorki@user/srk) (Ping timeout: 255 seconds) |
| 2023-10-30 12:34:46 +0100 | srk_ | srk |
| 2023-10-30 13:40:12 +0100 | chomwitt | (~chomwitt@2a02:587:7a01:8f00:1ac0:4dff:fedb:a3f1) (Ping timeout: 240 seconds) |
| 2023-10-30 14:02:26 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) (Ping timeout: 246 seconds) |
| 2023-10-30 14:05:17 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) |
| 2023-10-30 14:08:10 +0100 | chomwitt | (~chomwitt@ppp-94-67-189-112.home.otenet.gr) |
| 2023-10-30 15:05:34 +0100 | <liskin> | Yeah, I'm starting to think I might be able to go again next year |
| 2023-10-30 15:06:13 +0100 | <liskin> | Need to book accomodation earlier though, sleeping in a damp cellar wasn't the best |
| 2023-10-30 15:10:53 +0100 | <Solid> | uff |
| 2023-10-30 15:48:12 +0100 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 248 seconds) |
| 2023-10-30 16:22:41 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) (Ping timeout: 258 seconds) |
| 2023-10-30 16:36:00 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) |
| 2023-10-30 16:40:29 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) (Ping timeout: 245 seconds) |
| 2023-10-30 16:54:10 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) |
| 2023-10-30 16:55:30 +0100 | <haskellbridge> | <liskin> lol, I can't even mark rooms as read in Matrix |
| 2023-10-30 16:57:07 +0100 | <haskellbridge> | <liskin> This is beyond ridiculous. How can they keep failing at doing the most basic things IRC had for decades :-( |
| 2023-10-30 16:58:10 +0100 | <geekosaur> | which client? |
| 2023-10-30 16:58:45 +0100 | <geekosaur> | afaict the way you do it in element android is to press the X on "jump to unread" |
| 2023-10-30 16:59:13 +0100 | <geekosaur> | which… not exactly intuitive |
| 2023-10-30 16:59:32 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) (Ping timeout: 246 seconds) |
| 2023-10-30 16:59:45 +0100 | <liskin> | both nheko and element |
| 2023-10-30 17:00:00 +0100 | <liskin> | element has a context menu entry for it |
| 2023-10-30 17:00:18 +0100 | <geekosaur> | interesting, those normally do it "live" |
| 2023-10-30 17:00:20 +0100 | <liskin> | and it does absolutely nothing, because there's probably some state somewhere that is messed up or something |
| 2023-10-30 17:10:01 +0100 | <haskellbridge> | <Tranquil Ity> Usually opening and closing a room and spamming escape works |
| 2023-10-30 17:10:30 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) |
| 2023-10-30 17:11:31 +0100 | <liskin> | Yeah, that has been my experience too. Until today. |
| 2023-10-30 17:19:47 +0100 | <haskellbridge> | <Tranquil Ity> In any case it.s almost always a bug in the client rather than an issue with the protocol. In addition, if you are on a slow homeserver (such as matrix.org), there might be a delay depending on how well the client deals with unresponsive servers as clearing notifications seems to involve a server round trip. |
| 2023-10-30 17:20:37 +0100 | <geekosaur> | yes, they're sent to the server and then forwarded to other clients using the account |
| 2023-10-30 17:20:54 +0100 | <haskellbridge> | <Tranquil Ity> In any case it.s almost always a bug in the client rather than an issue with the protocol. In addition, if you are on a slow and/or buggy homeserver (such as matrix.org), there might be a delay depending on how well the client deals with unresponsive servers as clearing notifications seems to involve a server round trip. |
| 2023-10-30 17:21:29 +0100 | <haskellbridge> | <Tranquil Ity> Yep, that seems to be what the spec suggests. Send a read event, then sync. |
| 2023-10-30 17:21:36 +0100 | <geekosaur> | I've seen, for example, someone highlighting me, the phone pops up a notification, then the desktop client marks it read, then the notification disappears once the phone receives it |
| 2023-10-30 17:23:05 +0100 | <haskellbridge> | <Tranquil Ity> Yep I.ve seen that as well |
| 2023-10-30 17:23:06 +0100 | <haskellbridge> | <Tranquil Ity> I believe there.s some account data or maybe to-device shared on what.s the active client between clients that support it, as it doesn.t happen that often |
| 2023-10-30 17:24:31 +0100 | <haskellbridge> | <Tranquil Ity> Negotiating which client will be used to deliver a notif, and whether multiple will deliver it, certainly sounds like a pretty difficult problem |
| 2023-10-30 17:25:21 +0100 | <geekosaur> | afaict all of them receive it and the first one to mark it read clears it for the others |
| 2023-10-30 17:27:02 +0100 | <haskellbridge> | <Tranquil Ity> That is possible |
| 2023-10-30 17:27:03 +0100 | <haskellbridge> | <Tranquil Ity> Maybe might be worth it to suggest an MSC for negotiating which clients will silence their notifications |
| 2023-10-30 17:27:04 +0100 | <haskellbridge> | <Tranquil Ity> I haven.t looked too deep into it, maybe I should |
| 2023-10-30 17:30:39 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) (Ping timeout: 240 seconds) |
| 2023-10-30 17:33:40 +0100 | <haskellbridge> | <Tranquil Ity> Right now my priority is figuring out why `rotation_period_msgs` is not working as it.s supposed to in element, and whether that is a security issue heh. |
| 2023-10-30 17:36:44 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) |
| 2023-10-30 18:55:11 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) (Ping timeout: 260 seconds) |
| 2023-10-30 19:06:57 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) |
| 2023-10-30 19:13:23 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) (Ping timeout: 260 seconds) |
| 2023-10-30 19:25:32 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) |
| 2023-10-30 19:31:35 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) (Ping timeout: 255 seconds) |
| 2023-10-30 19:32:25 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) |
| 2023-10-30 19:46:00 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) (Ping timeout: 272 seconds) |
| 2023-10-30 19:58:18 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) |
| 2023-10-30 20:03:33 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) (Ping timeout: 260 seconds) |
| 2023-10-30 20:05:05 +0100 | justache | justHaunted |
| 2023-10-30 20:14:52 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) |
| 2023-10-30 20:20:44 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) (Ping timeout: 258 seconds) |
| 2023-10-30 20:33:03 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) |
| 2023-10-30 20:39:08 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) (Ping timeout: 258 seconds) |
| 2023-10-30 20:47:39 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) |
| 2023-10-30 20:53:43 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) (Ping timeout: 260 seconds) |
| 2023-10-30 20:56:41 +0100 | defjam | (~defjam@2a02:c7e:2807:b900:ac13:d447:79b2:3f03) |
| 2023-10-30 23:30:00 +0100 | chomwitt | (~chomwitt@ppp-94-67-189-112.home.otenet.gr) (Ping timeout: 255 seconds) |