Open code3z opened 2 years ago
Threading is not part of the spec yet. You can refer to the proposal here - MSC3440 - Threading.
And so cinny implementing something custom will only result in a rewrite when it is part of the spec.
Ah okay. I hope it gets implemented because rooms are going to be hard to organize.
It would still be a nice to have.
MSC3440 has been finalised and merged into the spec. Probably it's one of the most desired features in Element, so after the next Element release, it will be used a lot, and if someone want to participate in busy rooms, it will be a necesary feature for that. Probably @ajbura is waiting for this feature to be implemented fully in Matrix JS SDK.
Threads are currently in beta on Element and are already used by some people in chats and groups.
@ajbura, @notramo are threads in the roadmap for Cinny? If so, what could be the timeframe for its implementation?
MSC3440 has been merged to the spec as of March 9th, 2022, and has been an incredibly useful feature. I'd say it's the only reason I'm still tied to Element/Schildichat, and I'd definitely love to be able to use Cinny full-time with this feature.
+1
Hello, Any news on this ? Thanks
Are threads on the roadmap?
Anecdote: I've been using threads extensively in DMs, and I'd like to see another implementation other than Element offer them
waiting for threads
Any movement on this? Or is this dead in the water waiting for someone to work on an implementation?
This really should be added to the public roadmap. This is a killer feature and prevents me from moving managed Discord communities to Cinny+Matrix (Element is VERY cluttered and users have not liked it).
+1
+1
This is in spec, has been since version 1.4. We're now on 1.7. https://spec.matrix.org/v1.7/client-server-api/#threading https://spec.matrix.org/v1.7/changelog/#v14
This is something I'd mark as a somewhat major feature that is missing. And I don't really get the "It's not part of the spec." argument when you've added custom sticker/emoji support, which as far as I'm aware is stuck in limbo between two different spec proposals. It's nice to have, I'm happy with the proposal you've chosen, but it's not spec yet. When element and other clients are implementing it, it's probably worthwhile looking at implementing it here to.
This, and the incomplete encryption settings and verification is going to leave me unable to use this as my sole client.
Custom emoji was just a client side implementation while Threads required implementation on server, sdk and then the client so comparing those is unreasonable.
Speaking of implementation now since it's part of spec, it has tons of issues and even the main implementation which is element has plans to put it under labs again. So IMO it's better to wait it to be stable than filling the app with bugs.
it has tons of issues and even the main implementation which is element has plans to put it under labs again
Those are client issues, not spec issues, which means nothing prevents Cinny from implementing this feature without implementing Element bugs.
That reasoning also valid for every other feature that Cinny has implemented.
That said, adding any feature to any app almost always adds bugs, it's normal, and it's also still better for the user than not adding anything.
Someone said : refusing to love for fear of suffering is like refusing to live for fear of dying. I'd add : so is refusing to add features for fear of adding bugs.
Custom emoji was just a client side implementation while Threads required implementation on server, sdk and then the client so comparing those is unreasonable.
What I'm comparing is the state of the proposals, not the server/sdk/client implementations. And that is a mess IMO. The Element client supports the Vector thingie, I was running Dimension with turt2live's stickerbot, which is now deprecated, and the non Vector client support for the new thing is all over the place. Of note, Chinny's seems to be the cleanest from a user prospective. From what I can tell, the spec Cinny and some other clients use is MSC2545, which is also like the first response said, "not part of the spec yet". Given that MSC2545 has been implemented anyway, not part of the spec isn't really a showstopper.
Here's the open issues for the server implementation of threads. As KaKi87 pointed out, you've pointed to another clients issues. They have bugs, sure. Don't replicate them here if you can help it >.<
thanks for the heads up 🔥
@notramo Threads are next on our roadmap, so they will land soon. We do not have Polar unfortunatly but there's are other mediums if you would like to donate to the project.
One of the main points of Polar is to support core maintainers and avoid hungry bounty hunters jumping on issues, potentially overwhelming core maintainers.
I don't accuse anyone for only wanting the money, but it's interesting that this issue only gained traction after money have been mentioned.
I only want to support core maintainers of this project, they declined this way of supporting them, so I won't donate for this feature. Especially not for devs who never previously contributed to this project. Also, I won't donate to any other project/fork that implements this feature. I want to use this in Cinny.
Please keep the discussion on the technical details of this feature.
@kfiven, I deleted all my comments where I mentioned donations, sorry for messing up the conversation.
Is your feature request related to a problem? Please describe.
It can get very cluttered with everyone talking in the same channel. It would be really, really amazing to have threads like in discord. They're kind of like sub-channels that are tied to a specific message and can be created by anyone. For instance, someone could bring up an issue and we could create a thread on that message.
Proof that it is possible: https://github.com/matrix-org/cerulean