| 18 Apr 2026 |
|  @sboukiou:matrix.org left the room. | 18:39:10 |
|  @scrumplex:duckhub.io left the room. | 20:32:23 |
| 19 Apr 2026 |
|  comonad joined the room. | 09:23:26 |
| 20 Apr 2026 |
|  @ninio_artillero:kde.org left the room. | 22:05:26 |
| 23 Apr 2026 |
|  天川理音 joined the room. | 07:41:40 |
|  @not-jack:matrix.org left the room. | 12:27:31 |
| 24 Apr 2026 |
|  @hytero:r4.fo joined the room. | 05:42:01 |
| @hytero:r4.fo left the room. | 05:49:59 |
| 25 Apr 2026 |
|  kekser joined the room. | 23:12:39 |
| 27 Apr 2026 |
|  Ninja joined the room. | 14:57:14 |
| 29 Apr 2026 |
 Sanskar | kiara: Reading through the easyturn (#506645) and contracts (#506343) PRs more carefully, I think I get now why a generic wrapper doesn't work.
They're actually two different failure modes: easyturn breaks because a flat legacy option space can't map to named instances without knowing the cardinality upfront, while contracts breaks because the module spans a runtime dependency graph that has no single modular equivalent.
One thing I'm still not clear on: if the contracts PR lands, does migration for a dependent service become two separate steps? First map it to its modular shape, then manually audit and add the contract declarations? Or is there a way the contract requirements get derived from the existing config references?
| 11:01:22 |
 @cinerealkiara:matrix.org | In reply to @sanskar-0day:matrix.org
kiara: Reading through the easyturn (#506645) and contracts (#506343) PRs more carefully, I think I get now why a generic wrapper doesn't work.
They're actually two different failure modes: easyturn breaks because a flat legacy option space can't map to named instances without knowing the cardinality upfront, while contracts breaks because the module spans a runtime dependency graph that has no single modular equivalent.
One thing I'm still not clear on: if the contracts PR lands, does migration for a dependent service become two separate steps? First map it to its modular shape, then manually audit and add the contract declarations? Or is there a way the contract requirements get derived from the existing config references?
one could imagine taking an submodule option shape as a request shape, tho the question might be what to take as the result if we wanna infer things: none? same submodule tree?
like the honest answer here is i haven't actually tried to do this yet. | 11:13:04 |
|  Swaraj set a profile picture. | 14:47:53 |
|  KangYu Peng joined the room. | 17:28:41 |
| @cinerealkiara:matrix.org | i tried to further explore the idea of identity contracts generated from a modular service's submodule option shape for the case of our existing modular service snid, but didn't so much get to something particularly more useful than just a custom snid contract aimed at this boundary (in which case... maybe a more generic contract for such a use-case might do as well) | 18:51:38 |
| 30 Apr 2026 |
| Sanskar | That's interesting, if the identity contract ends up being roughly equivalent to just writing a custom snid contract, it kind of suggests the inference step doesn't actually save much.
Maybe the real value of automation isn't generating the contract itself, but just helping figure out which boundaries actually need one? | 05:58:21 |
| @cinerealkiara:matrix.org | In reply to @sanskar-0day:matrix.org
That's interesting, if the identity contract ends up being roughly equivalent to just writing a custom snid contract, it kind of suggests the inference step doesn't actually save much.
Maybe the real value of automation isn't generating the contract itself, but just helping figure out which boundaries actually need one? if we're talking inter-service boundaries, I think grepping service modules for `services\.\w+.* =` should go a long way in finding what else they set | 07:57:54 |
| Sanskar | Agreed. Grepping gets us the obvious write boundaries for cheap, leaving a much smaller surface area to manually audit.
Certainly better than overengineering it. | 09:18:58 |
 Yyovil | Thanks Tristan Ross and Robert Hensing (roberth). Forever grateful to yall for this opportunity. | 18:15:23 |
 Robert Hensing (roberth) | Just posted the announcement on community Discourse | 19:55:50 |
| 1 May 2026 |
|  prescientmoon joined the room. | 12:59:49 |
| 4 May 2026 |
|  AnnoyingRains changed their profile picture. | 02:36:05 |
| 3 May 2026 |
| AnnoyingRains changed their profile picture. | 13:02:40 |
|  @elloutro:matrix.org changed their display name from LaLoutre to Bastien. | 20:17:42 |
| 6 May 2026 |
|  Yogansh set a profile picture. | 03:33:00 |
| 7 May 2026 |
| @cinerealkiara:matrix.org changed their profile picture. | 18:34:11 |
| 12 May 2026 |
| @elloutro:matrix.org left the room. | 16:42:46 |
| 13 May 2026 |
|  @devprashant__19:matrix.org left the room. | 11:17:31 |
| 14 May 2026 |
|  Ahmed Amr joined the room. | 00:35:51 |
| 19 May 2026 |
|  MossyGuy joined the room. | 20:14:16 |
