| 00:36:25 | | nicolas17 quits [Ping timeout: 260 seconds] |
| 00:40:34 | | nicolas17 joins |
| 00:41:32 | <nicolas17> | myself: I think he had to create a new array because the array format he was using before didn't support that capacity |
| 00:42:04 | <nicolas17> | so it was make new array -> move data from old to new array -> add old disks to the new array |
| 00:42:09 | <nicolas17> | and the whole thing took several days |
| 00:46:31 | | sralracer quits [Quit: Ooops, wrong browser tab.] |
| 01:02:26 | | etnguyen03 (etnguyen03) joins |
| 03:19:45 | | etnguyen03 quits [Remote host closed the connection] |
| 03:34:20 | | AK quits [Ping timeout: 260 seconds] |
| 03:47:16 | <imer> | "RFC 35140: HTTP Do-Not-Stab" https://www.5snb.club/posts/2023/do-not-stab/ via HN https://news.ycombinator.com/item?id=42232040 |
| 03:47:43 | | AK (AK) joins |
| 03:47:50 | | imer is still salty about DNT not being a thing |
| 03:50:17 | <@JAA> | DNT got rolled into GPC, didn't it? |
| 03:52:07 | <@JAA> | There was something silly about DNT not indicating a clear user preference, so a new standard had to be made. |
| 03:52:19 | <@JAA> | In the eyes of the law, that is. |
| 03:54:32 | <@JAA> | Lovely link, by the way. |
| 04:00:17 | <nicolas17> | wasn't it Microsoft that fucked up DNT by enabling it by default "to protect privacy", which made all websites ignore it? |
| 04:26:12 | | DogsRNice joins |
| 04:33:56 | <nicolas17> | I found this gem again https://ludic.mataroa.blog/blog/i-will-fucking-piledrive-you-if-you-mention-ai-again/ |
| 04:49:55 | <pabs> | pseudorizer: my draft branch for a WebExtension for zygolophodon I mentioned yesterday https://github.com/jwilk/zygolophodon/compare/master...pabs3:zygolophodon:webext |
| 04:52:25 | | DogsRNice quits [Read error: Connection reset by peer] |
| 05:01:26 | | BlueMaxima quits [Read error: Connection reset by peer] |
| 05:19:12 | <steering> | nicolas17: "if you continue to try { thisBullshit(); } you are going to catch (theseHands)" rofl, what a gem indeed |
| 05:29:58 | <kpcyrd> | nicolas17: too much text, would use an LLM to summarize it for me |
| 06:03:54 | | ^ quits [Remote host closed the connection] |
| 06:04:17 | | ^ (^) joins |
| 06:04:53 | | Gadelhas5628 quits [Quit: Ping timeout (120 seconds)] |
| 06:05:09 | | Gadelhas5628 joins |
| 06:05:39 | <immibis> | the actual technical solution is to turn off cookies. browsers already control whether cookies are accepted so why is it up to websites to not send things the browser is already allowed to ignore? |
| 06:06:01 | <immibis> | (real answer: GDPR is about who you send information to, not the technical means by which you collect it) |
| 06:06:20 | <immibis> | btw X-Do-Not-Track falls under the same game theory problems as <a ping> |
| 06:06:58 | <immibis> | the world runs on game theory |
| 06:08:12 | <steering> | immibis: congrats, you're now still trackable |
| 06:08:13 | <steering> | ;) |
| 06:09:46 | <steering> | turn off cookies, use tor browser, don't resize your browser window, etc |
| 06:19:43 | <immibis> | wait until you see TLS and TCP fingerprinting |
| 06:20:45 | <immibis> | "use tor browser without javascript" is about the closest you can practically be to untrackable, since you look like everyone else using tor browser on the same screen resolution (including TLS fingerprints, and TCP fingerprinting is noise since the exit node terminates it) |
| 06:21:06 | <immibis> | i did check that tor browser on linux sends a windows user-agent |
| 06:22:23 | <steering> | indeed |
| 06:23:13 | <steering> | although "without javascript" is basically just "don't use the web" (even the "darkweb") |
| 06:23:28 | <immibis> | i'd say "don't use the corporate web" |
| 06:24:03 | <immibis> | no tracking-filled mainly-for-profit site is going to work without javascript, but small sites will mostly work |
| 06:24:29 | <immibis> | client-side web apps won't work either, of course |
| 06:25:03 | <immibis> | tracking-for-profit sites might be 99% of page views but they're only 0.1% of sites |
| 06:25:23 | <steering> | ehhhhhhh |
| 06:25:37 | <steering> | JS isn't *only* used to tracking |
| 06:26:25 | <immibis> | when it's not, you're either talking about a web app, or the site likely works without it |
| 06:26:35 | <steering> | lol |
| 06:26:51 | <steering> | I dunno what sites you're going to but most "small sites" that use JS don't have fallback |
| 06:27:03 | <steering> | you're more likely to get that from a big site |
| 06:28:28 | <steering> | for small sites (i.e. personal or small group effort) it's either "doesn't use JS" (which probably means that site doesn't have a whole lot of content, honestly) or "does use JS and is horribly broken without it" in my experience |
| 06:30:34 | <steering> | then mid-size sites that probably use JS but work fine without it (the kinda stuff that uses everything premade, wordpress with 50 bajillion plugins, so "works without JS" is no extra effort from the publisher), then large sites that absolutely require JS primarily for tracking |
| 06:31:52 | <steering> | i was pleasantly surprised to discover that deviantart still works with noscript in 2024 :) of course, having to reload the entire page to see the next handful of images is not a great UX, especially if you were doing it over such a high-latency connection as tor |
| 06:46:28 | <immibis> | change one letter and it's a site about small fruit pies by a linux distribution by people who don't adore systemd |
| 06:46:37 | <immibis> | two letters* |
| 06:46:46 | <immibis> | no just one |
| 06:47:03 | <immibis> | ... change a different letter and it's a more well known distribution |
| 06:48:34 | <steering> | that's not even the meaning i primarily associate with tart, but true :P |
| 06:49:05 | <steering> | (sharp, biting) |
| 07:07:43 | | HackMii quits [Ping timeout: 276 seconds] |
| 07:19:11 | | Pedrosso2 joins |
| 07:19:52 | | ScenarioPlanet quits [Ping timeout: 255 seconds] |
| 07:19:52 | | Pedrosso quits [Ping timeout: 255 seconds] |
| 07:19:53 | | Pedrosso2 is now known as Pedrosso |
| 07:20:12 | | ScenarioPlanet (ScenarioPlanet) joins |
| 07:22:17 | | HackMii (hacktheplanet) joins |
| 07:29:44 | | Jens (JensRex) joins |
| 07:42:05 | | SootBector quits [Remote host closed the connection] |
| 07:42:29 | | SootBector (SootBector) joins |
| 08:16:43 | <that_lurker> | https://insinuator.net/2024/11/vulnerability-disclosure-authentication-bypass-in-vaultwarden-versions-1-32-5/ |
| 08:23:07 | <@JAA> | I like the 'we didn't really take a close look at it' bit. |
| 08:36:34 | | Gadelhas56283 joins |
| 08:40:00 | | Gadelhas5628 quits [Ping timeout: 252 seconds] |
| 08:40:00 | | Gadelhas56283 is now known as Gadelhas5628 |
| 09:31:47 | <steering> | wow |
| 09:32:05 | <steering> | hey guys its safe because its in rust! :) |
| 09:35:39 | <katia> | haha |
| 09:43:33 | <f_> | people don't seem to get that the fact that it's in rust doesn't mean you're basically immune to potencial vulnerabilities. |
| 09:43:43 | <f_> | *potential |
| 09:44:04 | <steering> | yes :) |
| 09:44:06 | <f_> | "But hey it's memory-safe!" |
| 09:45:49 | | jacksonchen666 (jacksonchen666) joins |
| 10:00:12 | <steering> | kinda weird that they've already released full details and it was only fixed last week |
| 10:00:53 | <steering> | (although I guess you better be keeping such a software updated anyway) |
| 10:01:56 | <@JAA> | The fixed version was released last Monday, the blog post is from Friday. |
| 10:03:15 | <@JAA> | The fixes were committed a week before the release, too. |
| 10:04:09 | <@JAA> | And the fix PR outright said what the problem was: https://github.com/dani-garcia/vaultwarden/pull/5176 |
| 10:09:34 | | Froxcey quits [Remote host closed the connection] |
| 10:10:29 | | Froxcey (Froxcey) joins |
| 10:12:46 | | IDK quits [Quit: Connection closed for inactivity] |
| 10:14:09 | | sralracer (sralracer) joins |
| 10:15:05 | | Froxcey quits [Ping timeout: 260 seconds] |
| 10:25:02 | | nyakase (nyakase) joins |
| 10:38:40 | | Froxcey (Froxcey) joins |
| 10:39:01 | <joepie91|m> | mixed feelings. I'm annoyed by the "Rust, so it must be safe" thing too, but at the same time the impact of memory safety shouldn't be underestimated either |
| 10:39:32 | <f_> | joepie91|m: I'm not saying it should be underestimated, just that it is too overestimated. |
| 10:39:49 | <f_> | Memory safety isn't the answer to everything. |
| 10:40:42 | <joepie91|m> | I don't think it's possible to make a single statement like that, tbh. it's overestimated by specific groups of people (the "is rust, therefore must be safe" crowd) but still underestimated by the programming world at large (which continues to insist that "manual memory management is fine") |
| 10:40:56 | <joepie91|m> | programmers aren't a homogeneous mass :p |
| 10:41:03 | <f_> | !kdinf joepie91 |
| 10:41:07 | <f_> | !kfind joepie91 |
| 10:41:07 | <eggdrop> | [karma] 'joepie91' not found. |
| 10:41:14 | <f_> | oh, sad. |
| 10:41:16 | <f_> | joepie91|m++ |
| 10:41:17 | <eggdrop> | [karma] 'joepie91|m' now has 1 karma! |
| 10:41:22 | <f_> | have your first karma |
| 10:41:33 | <joepie91|m> | oh did I get a tail again, damnit |
| 10:41:40 | <f_> | what tail? |
| 10:41:48 | <f_> | the |m ? |
| 10:41:51 | <joepie91|m> | I seem to have a |m on the IRC side |
| 10:41:54 | <joepie91|m> | yeah |
| 10:41:59 | <joepie91|m> | that's not supposed to be there |
| 10:42:08 | | joepie91|m grumbles at IRC bridge |
| 10:42:08 | <f_> | Matrix® bridge™ moment |
| 10:42:15 | <joepie91|m> | I could swear I turned that off |
| 10:42:27 | <joepie91|m> | oh well. |
| 10:42:28 | <f_> | Sometimes bridge seems to not save preferences. |
| 10:42:33 | <@JAA> | Very stateful, such wow :-) |
| 10:42:43 | <joepie91|m> | yeah I've noticed this before |
| 10:42:49 | <f_> | and many other issues.. some of which I fixed myself but didn't get accepted even a few months later. |
| 10:43:04 | <f_> | (though at first after about a month one of the maintainers was very nice) |
| 10:43:12 | | Froxcey quits [Ping timeout: 252 seconds] |
| 10:43:17 | <f_> | I don't like the bridge and I don't use it |
| 10:44:06 | <joepie91|m> | I don't like the bridge but I do still use it |
| 10:44:15 | <f_> | why? free bouncer? :p |
| 10:44:15 | <joepie91|m> | I like the alternatives less |
| 10:44:24 | <f_> | What have you considered so far |
| 10:44:37 | <f_> | Personally I use soju because I like how advanced and friendly it is |
| 10:44:50 | <f_> | though I have tried ZNC and found it was slightly janky (sorry katia) |
| 10:45:09 | <f_> | kiska: hackint.logs.kiska.pw seems to be down? |
| 10:45:50 | <f_> | I also tried thelounge and it was....okay? Although has some issues here and there. |
| 10:46:14 | <f_> | And I'm not very fond of web clients (though props to The Lounge for being better than Element) |
| 10:46:29 | <steering> | f_: yes, was mentioned 2024-10-10 here |
| 10:46:37 | | nyakase quits [Client Quit] |
| 10:46:50 | <steering> | ded + no backups |
| 10:47:49 | <joepie91|m> | I mean, I've been using IRC in some form for like 20 years, and I've tried many clients in that time, but I didn't like any of them except a weird-ass Windows client that will not work properly under WINE |
| 10:48:06 | <joepie91|m> | and I absolutely do not want to fuck with bouncers and their jank again |
| 10:49:36 | <f_> | soju isn't janky at all IMO hence why I prefer it muuuuuch more over the other bouncers available |
| 10:49:59 | <f_> | I like that it populates all networks in my IRC client automatically provided it supports soju |
| 10:50:25 | <f_> | and the history handling is perfect.. I like that I can scroll up to get more messages :P |
| 10:50:42 | <f_> | no jank involved |
| 10:50:54 | <joepie91|m> | I haven't tried soju but at the same time I don't really intend on going back to having a separate IRC setup |
| 10:51:10 | <joepie91|m> | I just don't use IRC enough for this anymore, I mostly use it to stay in touch with a few people |
| 10:51:16 | <f_> | Anyway. joepie91|m: I will say that f0x did pull in my bridge fixes to pixie.town's bridge |
| 10:51:42 | <f_> | At least some of them, such as +b handling and fixing up replies |
| 10:52:28 | <joepie91|m> | most of my social circles nowadays exist on Matrix anyway and so I live in a Matrix client anyway, meaning I'd rather use my energy making a Matrix client worth a damn, than maintaining a whole parallel IRC setup :p |
| 10:52:39 | <joepie91|m> | right |
| 10:52:59 | | Froxcey (Froxcey) joins |
| 10:55:37 | <joepie91|m> | on which note, this weekend's project: https://gist.github.com/joepie91/a7f55ddcc6a18bf7adf40699b5769de2?ts=4 |
| 10:56:26 | <joepie91|m> | takes in N sequences of items that may have gaps in them (Matrix events, in this case) and merges them into a coherent sequence efficiently |
| 10:56:54 | <joepie91|m> | so that my client can actually maintain a local cache and merge in server responses and not be janky as fuck in navigating history |
| 10:57:40 | | Froxcey quits [Ping timeout: 260 seconds] |
| 10:59:05 | <@JAA> | TIL ts query parameter |
| 11:05:48 | <f_> | joepie91|m: I have not found a matrix client I like.. sadly |
| 11:07:53 | | Froxcey (Froxcey) joins |
| 11:10:16 | <joepie91|m> | f_: same-ish. hence making my own :p |
| 11:10:38 | <f_> | I don't like the matrix protocol enough to go make one, and also don't have much time.. |
| 11:10:42 | <joepie91|m> | I'm working on a low-stimuli client specifically |
| 11:11:12 | <f_> | I'm more into TUI clients.. something inspired by senpai, the IRC client I currently use - https://git.sr.ht/~delthas/senpai |
| 11:12:50 | | Froxcey quits [Ping timeout: 260 seconds] |
| 11:19:07 | <f_> | joepie91|m: anyway, I wish you all the best in making a new client! |
| 11:19:28 | <f_> | Might consider it as I do have to use matrix sometimes |
| 11:21:13 | <katia> | hi |
| 11:21:52 | | Froxcey (Froxcey) joins |
| 11:22:44 | | joepie91|m uploaded an image: (144KiB) < https://matrix.hackint.org/_irc/v1/media/download/AfJqhzcBZZ1EISulrlXPnwuECAjOepiknZ8ab12Zi4wMgZ82NYZA8_1ya8GyWeG5uytT357uJZsJU_iRYY-VYW5Cfcz_r5DwAHBpeGllLnRvd24va3VPbGRMRlR4aXJ3VmVucFJ0b0dBd0VZ > |
| 11:22:53 | <joepie91|m> | f_: ^ impression of what I'm going for UI-wise |
| 11:23:05 | <joepie91|m> | not complete yet ofc |
| 11:23:23 | <joepie91|m> | though not a lot of other stuff will be added |
| 11:28:47 | | Froxcey quits [Remote host closed the connection] |
| 11:28:54 | | Froxcey (Froxcey) joins |
| 11:51:52 | | DigitalDragons quits [Quit: Ping timeout (120 seconds)] |
| 11:51:53 | | Exorcism quits [Quit: Ping timeout (120 seconds)] |
| 11:53:38 | | Exorcism (exorcism) joins |
| 11:53:44 | | DigitalDragons (DigitalDragons) joins |
| 12:00:03 | | Bleo182600722719623 quits [Quit: The Lounge - https://thelounge.chat] |
| 12:00:44 | | Froxcey quits [Remote host closed the connection] |
| 12:01:20 | | Hackerpcs quits [Quit: Hackerpcs] |
| 12:02:50 | | Bleo182600722719623 joins |
| 12:07:07 | | Hackerpcs (Hackerpcs) joins |
| 12:18:58 | | Froxcey (Froxcey) joins |
| 12:21:08 | | Froxcey quits [Read error: Connection reset by peer] |
| 12:23:43 | | Froxcey (Froxcey) joins |
| 12:28:15 | | Froxcey quits [Ping timeout: 252 seconds] |
| 12:29:15 | | Froxcey (Froxcey) joins |
| 12:33:45 | | Froxcey quits [Ping timeout: 252 seconds] |
| 12:36:12 | | etnguyen03 (etnguyen03) joins |
| 12:53:21 | | etnguyen03 quits [Client Quit] |
| 13:02:26 | | etnguyen03 (etnguyen03) joins |
| 13:07:31 | | Froxcey (Froxcey) joins |
| 13:08:28 | | Froxcey quits [Remote host closed the connection] |
| 13:10:59 | | jacksonchen666 quits [Client Quit] |
| 13:19:51 | | Froxcey (Froxcey) joins |
| 13:20:41 | | Froxcey quits [Remote host closed the connection] |
| 13:20:48 | | Froxcey (Froxcey) joins |
| 13:25:35 | | alittleglitchy quits [Remote host closed the connection] |
| 13:25:35 | | c3manu quits [Remote host closed the connection] |
| 13:25:55 | | alittleglitchy joins |
| 13:26:02 | | c3manu (c3manu) joins |
| 13:31:56 | | Froxcey quits [Remote host closed the connection] |
| 13:36:57 | | Froxcey (Froxcey) joins |
| 13:41:35 | | Froxcey quits [Ping timeout: 260 seconds] |
| 13:50:59 | | Froxcey (Froxcey) joins |
| 13:55:42 | | Froxcey quits [Ping timeout: 252 seconds] |
| 14:02:32 | | Froxcey (Froxcey) joins |
| 14:05:30 | | xarph_ quits [Ping timeout: 260 seconds] |
| 14:06:49 | | xarph joins |
| 14:28:09 | | Terbium quits [Ping timeout: 252 seconds] |
| 14:54:42 | | Froxcey quits [Remote host closed the connection] |
| 15:02:49 | | Froxcey (Froxcey) joins |
| 15:06:14 | <immibis> | matrix seems like a protocol that is fundamentally impossible to make good |
| 15:06:30 | <immibis> | although most of that problem is on the homeserver, not the client |
| 15:12:55 | <joepie91|m> | I don't think that is the case; and I often find that people mistake "impossible to get the same tradeoffs out of as IRC/XMPP/etc." for "impossible to make good" |
| 15:13:26 | <joepie91|m> | Matrix as a protocol makes different design choices that makes some things very easy and other things very difficult, and that set is not the same set of tradeoffs as what nerds are typically accustomed to |
| 15:13:37 | <joepie91|m> | that's not to say the protocol doesn't have issues, but they're not fundamental issues |
| 15:14:59 | <joepie91|m> | for example: you will never get the extreme efficiency out of Matrix that a strict message-bus protocol like IRC or XMPP will give you; but on the flipside, you will never get the kind of room/channel resiliency out of IRC or XMPP that Matrix will give you |
| 15:15:43 | <joepie91|m> | and those are incompatible goals; either your rooms are centralized on an authoritative server and they are efficient but fragile, or your rooms are decentralized and they are robust but extra complexity is needed to resolve state across servers |
| 15:16:28 | <nicolas17> | resilient to what? |
| 15:16:43 | <joepie91|m> | (for the purposes of this point, "authoritative server" can also be a cluster of servers, the point is that they are under central control) |
| 15:17:16 | <joepie91|m> | nicolas17: server outages, outright server disappearances (a pretty big issue with decentralized networks typically), network segmentations, etc. |
| 15:17:31 | <nicolas17> | vs split-brained matrix rooms that require a "state reset"? |
| 15:18:08 | <joepie91|m> | a situation like "my government blocks the server on which community X exists, so I cannot participate in community X" cannot occur in Matrix, but it can occur in XMPP and IRC |
| 15:18:44 | <joepie91|m> | nicolas17: <joepie91> that's not to say the protocol doesn't have issues, but they're not fundamental issues |
| 15:18:47 | <joepie91|m> | this is a very important distinction |
| 15:18:49 | <nicolas17> | my experience with network segmentations in matrix has been significantly worse than with IRC |
| 15:19:06 | <joepie91|m> | state resets are not a fundamental property of the protocol architecture, they are a property of a shit implementation and governance process |
| 15:19:45 | <nicolas17> | the more I look at Matrix the more I realize that what I used to think were bad decisions in XMPP were actually better |
| 15:20:24 | <joepie91|m> | I feel like you're not actually engaging with what I am saying, and are just complaining at this point |
| 15:20:31 | | Froxcey quits [Remote host closed the connection] |
| 15:20:45 | <joepie91|m> | which, if you want to just complain, that's fine, but I don't intend on participating in that conversation |
| 15:20:50 | <nicolas17> | fine, matrix has different goals that I don't need or want |
| 15:21:27 | <joepie91|m> | sure, that's entirely valid |
| 15:22:05 | <nicolas17> | I'm not doing things that require government-censorship-resistance or even end-to-end encryption |
| 15:22:11 | <nicolas17> | I had similar discussions when KDE used Telegram |
| 15:22:21 | <nicolas17> | people would show up to say "don't use telegram, it's not secure" |
| 15:22:30 | <nicolas17> | secure against what? |
| 15:23:05 | <nicolas17> | the e2ee isn't perfect? the room is bridged to IRC anyway, maybe even has public logging, who cares about e2ee |
| 15:24:14 | <joepie91|m> | idk, I don't think a generalized conversation can be usefully had about this sort of thing. different communities are going to have different needs, that depend on the participants, the goals of the community, and so on |
| 15:24:33 | <joepie91|m> | it's ultimately always going to be a process of negotiating everyone's needs within a given community |
| 15:25:26 | <joepie91|m> | I feel like people treat this stuff too much like a competition and not enough like an interoperability problem, personally |
| 15:26:48 | | Froxcey (Froxcey) joins |
| 15:26:59 | <joepie91|m> | we'd all get a lot better results if people stopped constantly shitfighting over protocol preferences and instead put in the work to make their respective part of the protocol picture work and interoperate better |
| 15:31:15 | | Froxcey quits [Ping timeout: 260 seconds] |
| 15:32:11 | | Sluggs quits [Excess Flood] |
| 15:33:23 | <joepie91|m> | also to be clear, when I say 'people' I don't just mean one side of the argument, I really mean everybody, including but not limited to the Matrix folks |
| 15:34:12 | <joepie91|m> | Matrix has shit governance, XMPP has shit community dynamics, IRC has a shit protocol (at least by modern standards), they all have their own problems and all of them are factors in why things suck |
| 15:34:35 | | Sluggs joins |
| 15:35:42 | <joepie91|m> | (and obviously the closed platforms are, well, closed) |
| 15:43:17 | | Froxcey (Froxcey) joins |
| 15:45:15 | | ymgve quits [Ping timeout: 260 seconds] |
| 15:47:54 | | Froxcey quits [Ping timeout: 252 seconds] |
| 16:00:01 | | ymgve joins |
| 16:03:11 | | Froxcey (Froxcey) joins |
| 16:04:07 | | MrMcNuggets (MrMcNuggets) joins |
| 16:06:02 | | Froxcey quits [Remote host closed the connection] |
| 16:06:03 | | Froxcey (Froxcey) joins |
| 16:18:55 | | BornOn420 quits [Ping timeout: 276 seconds] |
| 16:18:55 | | sec^nd quits [Ping timeout: 276 seconds] |
| 16:20:36 | | sec^nd (second) joins |
| 16:21:04 | | BornOn420 (BornOn420) joins |
| 16:31:13 | <f_> | joepie91|m: matrix has fundamental issues |
| 16:31:20 | <f_> | Issues that make it unfit for me to use. |
| 16:32:01 | | Terbium joins |
| 16:35:57 | <joepie91|m> | like I said, "the tradeoffs of Matrix do not work for me" is a completely valid thing to conclude, it's just something different from "it's fundamentally broken" :) |
| 16:36:31 | <f_> | it's fundamentally broken for me :) |
| 16:36:44 | | DigitalDragons still hasn't found anything she likes the experience of using better than Discord |
| 16:36:55 | <f_> | I'm not talking about little bugs here and there. |
| 16:37:09 | <f_> | I'm talking about clients literally hanging or segfaulting upon sync. |
| 16:37:20 | <f_> | About history breaking a lot, and state resets. |
| 16:37:32 | <f_> | About broken E2EE, that too. |
| 16:37:44 | <f_> | (libolm) |
| 16:37:58 | <f_> | Also about frequent desyncs, but I suspect it might be Element |
| 16:38:07 | <joepie91|m> | none of those are fundamental issues, "fundamental" has a very specific meaning |
| 16:38:17 | <joepie91|m> | they are serious issues, but not fundamental ones |
| 16:38:18 | <f_> | They are fundamental *for me* |
| 16:38:34 | <f_> | I'm not trying to pretend they are fundamental for everyone. |
| 16:38:52 | <f_> | But these things.. IRC and XMPP do it perfectly (except E2EE on IRC of course) |
| 16:39:08 | <joepie91|m> | "fundamental", as in "an inherent unchangeable property of the system", this is necessarily a global and not a personal descriptor |
| 16:39:29 | <f_> | sure, not a native english speaker |
| 16:39:47 | <joepie91|m> | something is fundamentally broken when some unchangeable property of its design causes it to not meet its stated design objectives |
| 16:40:02 | <f_> | But these are serious issues, and there is very little chance I switch to Matrix if these, among many others, are not fixed. |
| 16:40:03 | <joepie91|m> | these are just bugs. serious bugs, and there's no excuse for them still being there, but still just bugs |
| 16:40:24 | <joepie91|m> | oh, absolutely, and I completely understand that |
| 16:40:39 | <f_> | I also have past experiences with fixing stuff and PRing all that with matrix.org/EMS |
| 16:40:46 | <joepie91|m> | I'm making this distinction of fundamental vs. serious issues for a very specific reason: because it determines whether there is a potential future for it |
| 16:40:58 | <joepie91|m> | if the issues truly are fundamental, then no amount of fixing and contributing will ever fix them |
| 16:41:06 | <joepie91|m> | because they simply cannot be fixed |
| 16:41:13 | <f_> | joepie91|m: gotcha |
| 16:41:42 | <joepie91|m> | but all of these problems are solvable; it may require a lot of work and governance changes, but they are fixable, there is a way forward, it 'just' requires the right people to get their head out their collective asses :) |
| 16:41:49 | <DigitalDragons> | I don't think everyone defines "fundamental" in that way |
| 16:42:28 | <joepie91|m> | people rarely all define words in the same way, regardless of the specific words, but in this case there's a very good reason to make that distinction :p |
| 16:42:32 | <f_> | joepie91|m: Matrix also needs less matrix.org, more decentralisation .. because else there's no point in federation if 90% of people just use matrix.org |
| 16:42:51 | <joepie91|m> | and unfortunately a lot of people do interpret "Matrix is fundamentally broken" to mean that it is unfixable |
| 16:43:02 | <f_> | I'm not saying it is unfixable |
| 16:43:03 | <joepie91|m> | and that's caused a lot of unnecessary conflict and frustration |
| 16:43:11 | <f_> | I'm saying that in its current state it is unusable for me. |
| 16:43:22 | <@JAA> | 'A lot of work and governance changes' does sound like a Ship of Theseus situation to me though. |
| 16:43:45 | <joepie91|m> | f_: I understand you to be clear, I'm saying that that specific phrase of "fundamentally broken" is a very common source of misunderstandings, and that's why I'm trying to define it explicitly |
| 16:43:45 | <@JAA> | At what point are the changes large enough that it's no longer the same system? |
| 16:43:54 | <f_> | joepie91|m: gotcha. |
| 16:44:09 | | f_[m] joins |
| 16:44:22 | <joepie91|m> | person A might say it with the intention of "it doesn't work for me" and then person B might interpret it as "is unfixable" and neither side realizes the other side's understanding |
| 16:44:25 | <f_[m]> | kicks and giggles |
| 16:45:11 | <joepie91|m> | re: matrix.org, Matrix is - somewhat surprisingly - doing better here than a lot of federated systems historically have, but it's definitely still too big, I agree |
| 16:45:12 | <joepie91|m> | problem for that mainly lies with Synapse |
| 16:45:12 | <joepie91|m> | it sucks to run a Synapse basically |
| 16:45:25 | <DigitalDragons> | I do wonder whether it would be less effort to just start from scratch, though |
| 16:45:27 | <f_> | joepie91|m: it sucks to run a matrix in its current state. |
| 16:45:37 | <joepie91|m> | JAA: I would consider "protocol compatibility" as the threshold |
| 16:45:40 | <f_> | Take a single-core 10 GB VPS |
| 16:46:24 | <joepie91|m> | DigitalDragons: there's a good argument to be made for that, and I have been working on more-or-less that with a few others, though with a specific approach to compatibility |
| 16:46:37 | <joepie91|m> | but also, diversity of tactics |
| 16:46:44 | <joepie91|m> | it's not necessarily one or the other |
| 16:47:39 | <joepie91|m> | there's people working on the governance changes, slowly, I personally am not involved in that anymore and have started working on a separate thing, might as well do both in parallel so that hopefully at least one succeeds |
| 16:48:06 | <f_> | joepie91|m: I'm just skeptical about matrix ever improving significantly. The status quo regarding clients for instance, has not changed in years. |
| 16:48:24 | | Froxcey quits [Remote host closed the connection] |
| 16:48:34 | <f_> | back in 2018 you had element/riot, some other element-based clients, and a lot of unfinished clients |
| 16:48:52 | | Froxcey (Froxcey) joins |
| 16:49:02 | <f_> | today the situation has not changed much. You still have Element, some element-based clients, maybe cinny, and a whole lot of unfinished clients. |
| 16:49:15 | <joepie91|m> | "nothing seems to be changing on the front end while things are slowly improving behind the scenes, and then suddenly things go fast" is a common pattern in dealing with governance issues, FWIW |
| 16:49:26 | <@JAA> | joepie91|m: That's fair, but then probably most of your gripes with IRC are also not fundamental issues by your definition because you can change just about everything about how ircds work without affecting the client-server protocol. E2EE would probably need an extension, but that's already happening in other parts, so I don't see that as a blocker either. |
| 16:49:44 | <joepie91|m> | most of the work right now is happening on the foundation level, not the technical level |
| 16:49:44 | <f_> | joepie91|m: You know what I also really love about Matrix? I joined #archiveteam-ot:hackint.org as f_[m], but I see zero messages on Element. |
| 16:50:17 | <f_> | Just the spinner thing and my "<f_[m]> kicks and giggles" message, that's all. |
| 16:50:23 | <f_> | nothing else |
| 16:50:25 | <joepie91|m> | JAA: I only really have one probably-fundamental issue with IRC, most of my gripes are more of an "it's unlikely this will ever get fixed for cultural reasons" problem :) |
| 16:50:44 | <f_> | joepie91|m: That mentality seems to have changed these days. |
| 16:51:07 | <f_[m]> | I can send messages though |
| 16:51:07 | <f_[m]> | can I? |
| 16:51:08 | <f_[m]> | sighs |
| 16:51:26 | <f_> | ^ see? Another gripe of mine is it takes ages to join a channel |
| 16:51:44 | <f_> | and also I sent a message just now and it'll take another few ages to get there |
| 16:51:56 | <f_[m]> | ah finally it works now |
| 16:52:14 | <f_> | got there^ |
| 16:52:22 | <f_> | <f_[m]> ah finally it works now |
| 16:52:25 | <joepie91|m> | f_: well... yes and no. it has changed these days, but I am acutely aware of how and when it changed, and that's the reason I still don't have much faith in IRC improving. I was complaining at various IRC people for the past decade or so about how things needed to be improved if they wanted to avoid irrelevance, this was broadly dismissed, I provided concrete suggestions, these were dismissed.... right up until Matrix started gaining |
| 16:52:25 | <joepie91|m> | traction, and Suddenly(tm) things started moving and those same ideas started making their way into implementations |
| 16:52:45 | <joepie91|m> | which to me feels somewhat analogous to the idea of 'fairweather friends' |
| 16:53:12 | <f_> | Uh? Not so sure about that. |
| 16:53:13 | <joepie91|m> | am I confident that people keep working towards improving IRC even when the pressure from things like Matrix disappears? no, not at all, because historically they didn't |
| 16:53:21 | <@JAA> | joepie91|m: Which one? |
| 16:53:46 | <joepie91|m> | I am not talking about the handful of people trying to make IRCv3 happen to be clear, but about the broader community acceptance of that idea |
| 16:54:05 | <joepie91|m> | there have always been a few people trying to push IRC forward but they've broadly not been taken very seriously in the past |
| 16:54:32 | <f_> | joepie91|m: these days it's just EFnet staff disagreeing |
| 16:54:34 | | f_ hides |
| 16:55:14 | <f_[m]> | f_[m]: Why is this message pinned at the bottom |
| 16:55:22 | <f_> | "<f_[m]> sighs" |
| 16:55:32 | <f_> | It's always shown at the bottom |
| 16:55:38 | <f_> | very reliable, I must say. |
| 16:55:43 | | f_[m] leaves |
| 16:55:58 | <joepie91|m> | JAA: not sure what "which one" was in response to |
| 16:56:05 | <DigitalDragons> | my biggest gripe with IRC is the lack of a community > category > channel hierarchy and historical logs |
| 16:56:36 | <joepie91|m> | f_: you don't need to convince me that the current state of Matrix clients is shit, I am very aware :) |
| 16:56:38 | <f_> | DigitalDragons: historical logs: see ircv3 |
| 16:56:46 | | Froxcey quits [Remote host closed the connection] |
| 16:57:07 | <@JAA> | joepie91|m: The probably-fundamental issue with IRC. Or is it this cultural thing? |
| 16:57:18 | <joepie91|m> | I am in some 550 rooms on Matrix (native and bridged), not counting DMs, and I run into a shitton of issues that most casual users never even see, so :p |
| 16:57:40 | <DigitalDragons> | er, and message editing/deleting |
| 16:57:41 | <f_> | joepie91|m: have seen no issues with 550-ish channels on IRC |
| 16:57:48 | <joepie91|m> | JAA: oooh, right. the fundamental issue is that its messagebus architecture is a poor fit for the expectations that people have of chat systems today |
| 16:57:50 | <f_> | DigitalDragons: Deleting: see ircv3 |
| 16:58:03 | <joepie91|m> | "people" as in "general public" |
| 16:58:34 | <joepie91|m> | f_: my point being that I get hit harder by these reliability issues than most Matrix users, ie. I have probably seen every bug you can think of :p |
| 16:58:43 | <DigitalDragons> | it is still a gripe until it is widely supported :) |
| 16:59:07 | <f_> | DigitalDragons: yes, but it is a gripe with the IRC networks you're in then, not IRC :) |
| 16:59:41 | <f_> | I'm not saying IRC is the perfect chat protocol, just that it *IMO* is much more reliable than matrix |
| 17:00:18 | <joepie91|m> | in terms of currently available implementations, that is certainly true |
| 17:00:24 | <f_> | joepie91|m: see, you're encountering loads of issues with 550-ish matrix channels, while I'm having zero issues with 550-ish IRC channels. |
| 17:00:29 | <f_> | Except... |
| 17:00:35 | <f_> | soju starts up very slowly |
| 17:00:45 | <joepie91|m> | like I said: you don't have to convince me |
| 17:01:26 | <joepie91|m> | keep in mind that I have been complaining to core devs about these problems for years, both publicly and in DMs |
| 17:01:40 | <joepie91|m> | I am very familiar with the problem, including often the causes |
| 17:01:41 | <f_> | no answer/fix? |
| 17:01:44 | | Froxcey (Froxcey) joins |
| 17:02:09 | <joepie91|m> | some issues have gotten fixed, but the governance issues consistently haven't |
| 17:02:32 | <@JAA> | joepie91|m: Not sure I follow re messagebus. |
| 17:02:40 | <@JAA> | Which expectations can't be realised with one? |
| 17:02:55 | <joepie91|m> | a notable example would be the tendency for Element's codebase to acquire more and more technical debt, and I've repeatedly tried to provide recommendations on how to get rid of this technical debt, but "shipping features to customers" was a higher priority to them |
| 17:03:03 | <joepie91|m> | this technical debt is responsible for a lot of issues, and I warned them ahead of time that the company would eventually drown in the maintenance load, which well, they are doing now |
| 17:03:06 | <f_> | joepie91|m: I don't think they ever will change that. |
| 17:03:22 | <joepie91|m> | I do not think Element the company ever will, no |
| 17:03:31 | <f_> | This, for instance https://github.com/matrix-org/matrix-appservice-irc/pull/1807 |
| 17:03:32 | <joepie91|m> | but Matrix the project might, once the two get decoupled more |
| 17:03:40 | <f_> | Needed a month to get any eyeballs on it |
| 17:03:57 | <f_> | Then they were quite helpful and I had faith it would get in |
| 17:04:03 | <f_> | they even split it in multiple PRs |
| 17:04:12 | <f_> | Since then, radio silence. |
| 17:04:53 | <f_> | All that happened from June to September |
| 17:05:02 | <f_> | Since September, nothing at all. |
| 17:05:12 | <joepie91|m> | f_: so the current situation is that Element and Matrix are nominally separate entities, but in practice Matrix has relied on Element's work and governance for years and years, to the point that the two have nearly become indistinguishable. Matrix is trying to get rid of that control by Element now, but since all the funding went to Element and not to Matrix, the result is mostly that there's just not enough manpower to actually fix the |
| 17:05:12 | <joepie91|m> | issues left behind by Element |
| 17:05:14 | <f_> | We are in november, almost december |
| 17:05:42 | <joepie91|m> | so the choices for Matrix issues getting fixed currently are a) asking Element to fix it or b) maybe, maybe a volunteer has time to fix it. maybe. |
| 17:06:11 | <f_> | a) involving convincing Element about how much profit they can do if they fix it |
| 17:06:18 | <f_> | and b) as well |
| 17:06:20 | | Froxcey quits [Ping timeout: 260 seconds] |
| 17:06:36 | <f_> | Anyway. I need to get back to work. |
| 17:06:49 | <joepie91|m> | and if A happens, that means that it's going to be done The Element Way and that's how we got into this mess to begin with |
| 17:06:53 | <joepie91|m> | this is the root of the governance problem |
| 17:06:55 | <f_> | but one more thing: JAA: where does atirclog log? |
| 17:07:15 | <joepie91|m> | and even if a volunteer tries to fix it, it often still blocks on an Element employee who also runs a Matrix project |
| 17:07:24 | <joepie91|m> | for review, merge, whatever |
| 17:07:54 | <@JAA> | f_: To a place that isn't currently intended to be public because it has Issues™. |
| 17:08:10 | <f_> | joepie91|m: I think you mostly got what my main gripes are with matrix. |
| 17:08:30 | <f_> | and hope you understand why I don't enjoy matrix all that much. |
| 17:08:56 | <joepie91|m> | oh yeah, I completely understand, there is a reason I am not trying to convince you otherwise |
| 17:09:02 | <joepie91|m> | I just approach it as a problem to be resolved :p |
| 17:09:17 | <joepie91|m> | this is the reason I am working on my own client and all that |
| 17:09:34 | <joepie91|m> | and that I am in parallel working on a separate protocol |
| 17:09:52 | <joepie91|m> | I recognize the idea behind Matrix as a valid one but they fucked up the implementation |
| 17:10:16 | <f_> | yeah the main idea behind matrix wasn't bad |
| 17:10:35 | <f_> | the implementation however, needs a lot of improvements and manpower to get there |
| 17:11:22 | <joepie91|m> | yep |
| 17:13:12 | <f_> | joepie91|m: by the way, try sending "!irc nick joepie91" here |
| 17:13:25 | <f_> | to fixup your nick |
| 17:13:35 | <f_> | joepie91|m-- |
| 17:13:36 | <eggdrop> | [karma] 'joepie91|m' now has 0 karma! |
| 17:13:39 | <f_> | joepie91++ |
| 17:13:39 | <eggdrop> | [karma] 'joepie91' now has 1 karma! |
| 17:13:41 | <f_> | joepie91++ |
| 17:13:43 | <eggdrop> | [karma] 'joepie91' now has 2 karma! |
| 17:13:52 | | joepie91|m is now known as joepie91 |
| 17:13:59 | <f_> | joepie91: it worked |
| 17:13:59 | <joepie91> | better? |
| 17:14:08 | <joepie91> | huh. it worked. |
| 17:14:21 | <joepie91> | savour the victories where they occur, I suppose |
| 17:14:21 | <joepie91> | :p |
| 17:14:28 | <f_> | "-- joepie91|m→joepie91" |
| 17:24:19 | | Froxcey (Froxcey) joins |
| 17:28:34 | <immibis> | better to do five things well than fifty things poorly. IRC has a design that's informed by the need to implement it. Matrix starts with an unimplementable thing it would like to achieve, then doesn't implement it well because that's impossible. |
| 17:28:48 | <immibis> | btw telegram doesn't even HAVE e2ee |
| 17:29:05 | | Froxcey quits [Ping timeout: 260 seconds] |
| 17:30:28 | <immibis> | joepie91|m: matrix breaks protocol compatibility regularly. I think the room versions go up to about 11? |
| 17:31:41 | <immibis> | IRC's fundamental issue is the lack of mobile device (on-again-off-again internet connection) support |
| 17:32:08 | <joepie91> | room versions exist specifically to maintain protocol compatibility |
| 17:32:20 | <immibis> | joepie91|m: IRC has a whole bunch of stuff now, like server side message echo and timestamps and even emoji reactions (which are dumb and no client supports them) |
| 17:33:45 | <immibis> | room versions indicate a lack of compatibility. If you don't support the room version, you can't be in the room, which is also how new protocols work |
| 17:33:48 | <@JAA> | Reactions are still a draft. |
| 17:34:31 | <@JAA> | And unstable internet connections aren't an unfixable issue in IRC. |
| 17:34:53 | <@JAA> | But yeah, not sure anything's still happening in that area. Maybe there's some renewed interest once chathistory is finalised. |
| 17:34:59 | <immibis> | They are. The whole protocol is built around a single TCP connection and when it dies you log off. |
| 17:35:19 | <f_> | JAA, immibis: ergo ircd has a built-in bouncer |
| 17:35:29 | <@JAA> | That doesn't mean it's unfixable. Lots of things are being done with opt-in extensions. |
| 17:35:44 | <f_> | So when it dies you don't log off |
| 17:36:09 | <@JAA> | There was a proposal a few years ago where you could resume your last session up to some time after you disconnect. The server would buffer messages and use chathistory to supply them to your client when you reconnect. |
| 17:36:25 | <immibis> | Any extension to IRC to make it persistent will have to fundamentally reinvent the protocol. Bouncers are a hack. I'm using a quasselcore "bouncer" with a non-IRC protocol. |
| 17:36:36 | | Froxcey (Froxcey) joins |
| 17:36:42 | <immibis> | Yes, that's probably the best it can be - an emulation of a longer lived TCP session. |
| 17:36:53 | <f_> | immibis: Well Ergo made IRC persistent without reinventing the protocol |
| 17:37:01 | <f_> | so... "you're wrong!" |
| 17:37:04 | <f_> | :p |
| 17:37:09 | <@JAA> | The entire computing world is hacks stacked on top of each other. :-) |
| 17:37:10 | <immibis> | The client will still have to check in every 10 minutes or so - otherwise the law will start demanding some kind of moderation of the persisted messages. |
| 17:37:24 | <DigitalDragons> | You have things like thelounge that mostly solve the mobile issue for IRC, it just happens that most people run their own instead of sharing |
| 17:37:46 | <immibis> | f_: bouncers are a hack - they just replay the last N messages as if they were new messages |
| 17:38:02 | <f_> | immibis: I'm only aware of ZNC doing that. |
| 17:38:12 | <f_> | My bouncer doesn't do that |
| 17:38:26 | <immibis> | the moderation architecture of IRC is also dependent on it being a message bus because you don't need to moderate the message history. |
| 17:38:46 | <f_> | immibis: okay, have you ever *seen* IRCv3 chathistory? |
| 17:39:38 | <immibis> | never seen ergo ircd |
| 17:39:51 | <joepie91> | immibis: the point of room versions is to section off the small part of the protocol where incompatible changes may be needed for eg. security reasons, so that homeservers can support any version of a room, and an upgrade to that part of the protocol means you do not have to break compatibility with old rooms to be able to use new ones |
| 17:39:55 | <f_> | never seen soju either? |
| 17:40:04 | <f_> | you should give both and ircv3 chathistory a try :) |
| 17:40:26 | <joepie91> | ie. it is specifically a mechanism for reducing the impact of unavoidable compatibility breaks |
| 17:40:53 | <f_> | joepie91: doesn't look like that to me |
| 17:41:10 | <f_> | Unless you're talking about the homeserver? |
| 17:41:12 | | Froxcey quits [Ping timeout: 252 seconds] |
| 17:41:22 | <immibis> | A small part? Are rooms not the entire purpose of the protocol? |
| 17:41:35 | <joepie91> | and sure, you can argue "that means you can't join new rooms with old homeservers!" but come on, it's a completely unrealistic expectation to expect that a piece of software that interacts with a network protocol that is under continuous development can keep working forever with zero change even on new things that didn't exist when it did |
| 17:41:38 | <f_> | Froxcey: fix your connection |
| 17:41:56 | <f_> | joepie91: uh, no that makes perfect sense to me. |
| 17:42:01 | <joepie91> | what doesn't look like what? |
| 17:42:14 | <immibis> | joepie91: straw man. a compatible protocol would work in a degraded mode. |
| 17:42:37 | <immibis> | if I connect to an irc server with emoji reactions I just won't see them |
| 17:43:01 | <immibis> | unrealircd supports a network with a mix of two adjacent major versions |
| 17:43:03 | <steering> | f_: they can't fix their connection if you tell them while they're gone! :) |
| 17:44:44 | <joepie91> | immibis: which is how every other part of the protocol works, but crucially not *the part that cannot be changed in a non-breaking manner*, which is what room versions are for |
| 17:45:19 | <immibis> | well that sounds like an issue with the protocol, that the most important part of it can only be changed in a fully breaking manner |
| 17:45:33 | <joepie91> | and yes, room versions are only a small part of the protocol |
| 17:45:53 | <immibis> | rooms are not |
| 17:46:12 | <joepie91> | immibis: if you believe that a protocol can be fully non-breaking for an arbitrary set of future needs, well, I don't know what to tell you other than I hope you never have to design a protocol... |
| 17:46:35 | <joepie91> | because you will not be enjoying the experience |
| 17:46:35 | <immibis> | there isn't an arbitrary set of future needs |
| 17:46:48 | <joepie91> | immibis: "room versions" and "rooms" are not the same thing |
| 17:47:03 | <joepie91> | look, if you're going to criticize the protocol, please do at least make sure that you understand the thing you're criticizing, or alternatively leave some room to learn |
| 17:47:31 | | katocala joins |
| 17:47:35 | <f_> | steering: I know :p |
| 17:47:37 | <joepie91> | like, do you actually know what the room version does? |
| 17:47:41 | | katocala is now authenticated as katocala |
| 17:48:12 | <f_> | joepie91: 🤣 |
| 17:48:15 | <joepie91> | actually yes, there is an arbitrary set of future needs, that is very specifically part of Matrix's design objectives |
| 17:48:18 | <immibis> | room versions are the versions of the room protocol. The room protocol is the most important part of a protocol about chatting in rooms. |
| 17:48:37 | <joepie91> | and is one of the major reasons why it makes some different design choices than eg. IRC |
| 17:48:41 | <f_> | joepie91: I don't like how you upgrade from one version to another, though. |
| 17:49:00 | <joepie91> | what is "the room protocol"? |
| 17:49:04 | <f_> | you basically create an entirely new room and set a tombstone event on the old one |
| 17:50:02 | <joepie91> | f_: I don't like it either, but there *is* a good reason for it from a technical perspective, and I consider it mostly a UI problem (as evidenced by Telegram doing basically the same thing but you just never notice it there) |
| 17:56:34 | <joepie91> | f_: to elaborate on the Telegram thing: Telegram has different kinds of groups (regular vs. supergroups or something) and they work differently internally, and have different limits on eg. usercount. you can "change" the type of a group, and I believe under some circumstances this happens automatically. from a user perspective this just looks like a group setting, but in practice a new group gets created with a new ID and a reference in the |
| 17:56:34 | <joepie91> | old one, much like how it works in Matrix, and this is really obvious when you interact with Telegram through its API (including in many bridges) |
| 17:57:45 | <joepie91> | I suspect it is for the same reason as in Matrix; the exact mechanism by which the room structure and validity of its contents are defined, or the infrastructure on which it runs, change - and the easiest and safest way to implement that is by simply creating a new room of a different type and transparently forwarding the users, because not having a way to change the internals of an existing room also means no attack surface |
| 17:58:27 | <joepie91> | in the case of Telegram I suspect it's because they don't want coordination overhead between different clusters; in the case of Matrix it's because it changes the stateres logic and this reduces the chance of stateres bugs -> state resets |
| 18:07:14 | | Froxcey (Froxcey) joins |
| 18:21:34 | | imer quits [Killed (NickServ (GHOST command used by imer9))] |
| 18:21:47 | | imer (imer) joins |
| 18:23:25 | <f_> | Froxcey: fix your connection |
| 18:23:38 | <f_> | joepie91: What I don't like is how matrix's UX handles it |
| 18:23:44 | <f_> | With telegram it's transparent |
| 18:23:53 | <f_> | while with matrix it'll leave lots of users behind.. |
| 18:32:42 | <joepie91> | yeah |
| 18:33:34 | | parfait (kdqep) joins |
| 18:35:12 | <joepie91> | immibis: to follow up on the earlier thing: there is no such thing as a "room protocol" in Matrix, and the majority of what "a room" looks like isn't defined by the room version, but by the rest of the spec. the only part that the room version really governs, are the event validity rules and the state resolution algorithm, which necessarily needs to be identical between all participants to get consistent results. everything from event types, |
| 18:35:12 | <joepie91> | semantic meaning of events and so on all exists *separate from* the room version, with the only exception being those bits that are critical to state resolution like bans and power levels. |
| 18:35:40 | <joepie91> | in other words, the 'room version' is what would be the consensus algorithm in a distributed system |
| 18:35:57 | <joepie91> | it is just called 'room version' because that is easier to communicate to people without a technical/protocol background |
| 18:42:19 | <f_> | I'm not sure what immib.is meant by 'room protocol' |
| 18:42:32 | <f_> | I know matrix sucks but at least bring up valid arguments :p |
| 18:42:48 | <f_> | else it's just not honest |
| 18:47:07 | <joepie91> | that was more or less my frustration, and why I asked :p |
| 18:47:17 | <joepie91> | there are plenty of legitimate issues with it, no need to invent new ones |
| 18:52:58 | <nicolas17> | erm |
| 18:53:01 | <nicolas17> | https://www.opengroup.org/onlinepubs/9699919799/functions/fcntl.html what the actual fuck |
| 18:53:27 | <nicolas17> | someone has really misconfigured that server |
| 18:53:52 | <Ryz> | Hmm, I've been hearing ping noises on my The Lounge, but I can't appear to see where they came from at all :/ |
| 18:54:00 | <Ryz> | This has been happening for today or yesterday S: |
| 18:55:17 | <nicolas17> | JAA: curl -v https://www.opengroup.org/onlinepubs/9699919799/functions/fcntl.html |
| 18:56:15 | <DigitalDragons> | Ryz: Can you use the recent mentions tab up next to the search bar? |
| 18:56:36 | <f_> | <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> |
| 18:56:36 | <f_> | <html><head> |
| 18:56:36 | <f_> | <title>302 Found</title> |
| 18:56:36 | <f_> | </head><body> |
| 18:56:36 | <f_> | <h1>Found</h1> |
| 18:56:37 | <f_> | <p>The document has moved <a href="balancer://pubs/onlinepubs/9699919799/functions/fcntl.html">here</a>.</p> |
| 18:56:37 | <f_> | </body></html> |
| 18:57:13 | <Ryz> | DigitalDragons, I'm on a much older version of The Lounge because the newer versions screw up the custom skin formatting or stuff ><; |
| 18:58:46 | <DigitalDragons> | D: |
| 18:59:44 | <@JAA> | nicolas17: lol, nice |
| 19:00:01 | | MrMcNuggets quits [Client Quit] |
| 19:00:03 | <@JAA> | Happens on the latest POSIX, too. |
| 19:25:31 | | ducky quits [Read error: Connection reset by peer] |
| 19:26:07 | | ducky (ducky) joins |
| 20:28:10 | <nicolas17> | welp |
| 20:28:20 | <nicolas17> | https://theapplewiki.com/wiki/List_of_asset_types this is gonna take us a while to fill in |
| 21:06:55 | | BlueMaxima joins |
| 21:29:48 | | BearFortress quits [] |
| 22:00:22 | | ThetaDev quits [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] |
| 22:00:30 | | ThetaDev joins |
| 22:09:33 | | ducky quits [Ping timeout: 260 seconds] |
| 22:11:32 | | ducky (ducky) joins |
| 22:13:58 | | etnguyen03 quits [Quit: Konversation terminated!] |
| 22:14:15 | | etnguyen03 (etnguyen03) joins |
| 22:21:00 | | mls (mls) joins |
| 23:10:39 | | mls quits [Ping timeout: 252 seconds] |
| 23:15:40 | | mls (mls) joins |
| 23:16:38 | | sralracer quits [Quit: Ooops, wrong browser tab.] |
| 23:17:25 | | sralracer (sralracer) joins |
| 23:18:27 | | sralracer quits [Client Quit] |