In reply to @aloisw:kde.org
Just throwing around fancy mathematical terms does not make anything easier, you have to understand what it actually means and how (if at all) it is applicable.

In reply to @gavinrogers:matrix.org
as i said, it's a graph whether we acknolwedge it or not. i'm only noting that it will be an easier to manage graph if it's treated as such. using the tools of lambda calculus to make this easier seems important to me

In reply to @raitobezarius:matrix.org

Quick update on Zulip for people who may have not followed what I'm trying to do:

With the few hours I have in life, I have been trying to experiment with https://github.com/GearKite/MatrixZulipBridge and I believe that the way forward for having an alternative platform which is still connected to the rest of the ecosystem on Matrix would require: https://github.com/GearKite/MatrixZulipBridge/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc (at least).

In the end, even if all that work was done and that a compelling proposal (w.r.t. moderation concerns/demands) could be offered, remains one problem that I don't know how to solve.

Most of the discussions in certain channels of NixOS space are, by nature, thread-oriented: we start a discussion, we follow up there, we split maybe on a tangent, etc, etc.
If Matrix ecosystem had uniform support for threads, that wouldn't be a big deal but they are known to be broken or not rendered by certain clients.

Now, if feature negotiation could be performed and channel could be guarded by "this requires threads to have an OK experience", I believe this could also make the proposal acceptable.

I am aware of various MSCs (https://github.com/matrix-org/matrix-spec-proposals/pull/3968) to have a better control of features in a room but I am not aware of any of them put in practice widely.

Nonetheless, no reasonable solution seems to exist to offer even a featureful bridge to Zulip (even if I worked with Zulip developers towards that end).