10:22 <hannes> according to the freenode server we should celebrate today! "Channel #mirage created Tue Jan 19 00:10:01 2010" this is exacly 11 years ago, and MirageOS is still very alive. Godspeed! :)

10:31 <dinosaure> \o/

10:42 <reynir> Nice! \o/

11:27 <avsm[m]> Hah, according to my email, I created the irc channel to collaborate on the "Turning down the LAMP" paper (which eventually got published that year https://www.usenix.org/conference/hotcloud-10/turning-down-lamp-software-specialisation-cloud).

11:27 <avsm[m]> It's quite fun re-reading it.

11:28 <dave[m]1> time for a retrospective article maybe? (or do we have to wait for 15)

11:29 <avsm[m]> I was thinking about that indeed -- was also re-reading this "multiscale" paper I wrote from 2009 that motivated the need for Mirage: https://www.cl.cam.ac.uk/~jac22/out/orizens.pdf

11:29 <avsm[m]> As we evaluate a shift to Matrix for MirageOS comms, a lot of the issues brought up there about personal data security have just gotten worse in the intervening time

11:30 <hannes> indeed

11:41 <h01ger> a lot of issues have just gotten worse in the intervening time

12:13 <tg-x> what got worse exactly recently?

12:14 <tg-x> in any case also good to keep in mind that matrix does not scale and consumes way too much resources, and some providers stopped supporting matrix due to that, in addition to the privacy issues

12:15 <tg-x> it's ok to support it in addition to irc, but don't drop irc

12:17 <h01ger> #xkcd1782

12:30 <hannes> tg-x: you may be interested to read/skim over the papers from > 10 years ago avsm linked to above (which include motivations for mirageos - one being 'personal containers' -- i.e. avoid centralized storage by facebook, google, etc.). i don't think anyone has plans to "drop irc", there's 'only' the proposition that matrix is a federated system (similar to email) that has a shiny look and is usable by

12:30 <hannes> non-experts (plus, in addition, there are irc-matrix bridges, as used by dave & avsm (and others)). :) 'does not scale and consumes too much resources' <- this may be an opportunity (I doubt matrix by (protocol) design is in that category -- but i have barely looked at the protocol)

12:35 <tg-x> sure, bridging is fine

12:36 <tg-x> i'll take a look at that paper

12:38 <tg-x> one of the problems is that there are a few huge instances instead of many smaller ones, the protocol & implementation details i'm not so familiar with