| 18 Jul 2025 |
 Cat | But yes there is a case for only using forking upgrades | 17:47:43 |
 emily | In reply to @charles:computer.surgery
yeah it's sad but i believe it is necessary availability is overrated and consistency is underrated. you can have problems "as bad as" lack of availability with AP systems anyway | 17:47:49 |
| Cat | when you adopt a room | 17:47:50 |
| Cat | since you could say the adopted room is not nixos sanctioned | 17:48:01 |
| Cat | and have that be the rule | 17:48:11 |
| Cat | only nixos sanctioned rooms are allowed to be in the upgrade tree. | 17:48:25 |
| Cat | i mean upgrade line. | 17:48:31 |
| emily | ACID is great. admittedly centralization is a bit sad. | 17:48:39 |
| emily | what is a forking upgrade? just making an entirely new room without a backpointer? | 17:49:14 |
| Cat | Yup. | 17:49:21 |
 f0x | you could do a manual 'tombstone' where you just send a normal message redirecting people to the new nixos-controlled room, and limit further posting | 17:49:25 |
 Charles | i think a protocol could get at least some outage resiliency by having a set of trusted write nodes, but not sure yet what the best way to accomplish that would be | 17:49:25 |
| Charles | * i think a more centralized protocol could get at least some outage resiliency by having a set of trusted write nodes, but not sure yet what the best way to accomplish that would be | 17:49:33 |
| Cat | Forking upgrades are upgrades where only 1 side of the chain points at the other room | 17:49:36 |
| Charles | too real | 17:49:40 |
| f0x | ah, also what I ment :D | 17:49:52 |
| Cat | so either the predecessor points at a successor that does not recognise that room as the parent | 17:49:53 |
| Cat | or a child room does not get recognised by its parent. Aka what would happen if someone defined a nix room as precursor when forking nix community. | 17:50:15 |
| Cat | if a freenode situation ever happened in the nix project that would be a likely thing to happen. | 17:50:39 |
| emily | I guess we could do that for new rooms | 17:59:33 |
| emily | many of our existing rooms are adopted though | 17:59:34 |
| emily | oops sorry network issues | 17:59:43 |
| emily | In reply to @charles:computer.surgery
i think a protocol could get at least some outage resiliency by having a set of trusted write nodes, but not sure yet what the best way to accomplish that would be well it's still ultimately just going to be a Paxos type thing right | 18:03:57 |
| emily | so you have the usual everything goes down if the ~centralized authority does thing | 18:04:30 |
| Charles | afaik, yes | 18:04:46 |
| emily | but it's fine. tbh. Matrix isn't resilient enough for the resilience features to pay dividends | 18:04:52 |
| emily | and optimizing for everything going down or being untrustworthy doesn't solve everything sucking really bad if everything goes down or is untrustworthy. someone's gotta do maintenance | 18:05:47 |
| Cat | Matrix is still not totally centralised even with the v12 change | 18:06:04 |
| Cat | but yes its more centralised ofc but atleast your not completely offline just because someone is having maintennance. | 18:06:30 |
| emily | it seems it is buying even less than before with the costs it pays for decentralization though? | 18:06:41 |
