Hi everyone. I noticed the migration to the new #users:nixos.org and the reason (for #nix:nixos.org being out of sync with topic, title etc.). It was also out of sync for me in showing the list of moderators in the room.

I would like to note that someone should also update the description of the space https://matrix.to/#/#community:nixos.org as the description still refers to the old room:

The primary support channel for Nix/NixOS is #nix:nixos.org.

Hi everyone. I noticed the migration to the new https://matrix.to/#/#users:nixos.org and the reason (for https://matrix.to/#/#nix:nixos.org being out of sync with topic, title etc.). It was also out of sync for me in showing the list of moderators in the room.

I would like to note that someone should also update the description of the space https://matrix.to/#/#community:nixos.org as the description still refers to the old room:

The primary support channel for Nix/NixOS is #nix:nixos.org.

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

With the few amount of time 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).

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).

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).