Reminder if you work for any of these companies (not unlikely on this site) you are actively enabling this. If your first reaction is doubt, deflection, rationalization or discomfort, there are ways out.
Code is a liability - the more there is, the higher potential for bugs and poor performance. I'd recommend treating cheap code like cheap toxic waste, and try to minimize how much is generated.
When I tested all the p2p messengers I could get my hands on for Android and iOS about two years back, the only one that worked at all without having a router around was Briar. Glad to see it helping people.
I was wondering the same thing. My best guess is that is to guard against operator misuse. Like usb-a only plugging in one way. Anything that is secret will never accidentally print to stdout. String interpolation in bash with `—option $empty` might be safer than `8<$empty`. Have to explore more but yeah, this is a new pattern for me as well.
I am describing what I see on Element X on iOS today. If someone replies to threads, it is not hidden and navigable on this client. Even after switching the labs feature on, the app was showing the thread interspersed with the rest of the conversation.
Uninstalling the app, reinstalling, and making sure the labs option is turned on before navigating to a room with threads, is behaving how I expect.
So maybe, its a bug that the room does not re-render after toggling that setting.
I felt bad making a long thread once I opened Element X and saw it didn't have support for threads.
Someone let me know later that threads are hidden behind a Labs setting, but it only allows the client to reply to threads, but still exposes the entire thread inline for the channel which sucks up all the air in the chat.
Pre-launch I seem to recall using an entirely different product with the same name, that supported CUE or HCL and had a better gui editor. I think post acquisition they scrapped it for the current (and IMO) worse reskin.