jdev - 2025-06-16

>> Cheogram Android and https://app.cheogram.com both have some UX, with android being the most mature > Cheogram's threads UX was pretty awful last time i checked opinion 🚮 ↺

>> Wonder how different our ideas are > My UX idea is an imageboard-like thread tree with last `<subject>` as a name, if available, or just a shortened last message I've meant for awhile to make a module to ban messages without a thread to some mucs ↺

> Yes exactly. Should means you should expect things might break if you do it, but doing it isn't out of compliance per se seemingly cant react to this, 👍 ↺

> larma, said once a new spec should be written, but its unclear to me what this new spec would do any different, it will probably always be a message that references another message .. There's a few changes that a "any message correction" XEP IMO would need: 1. Reference messages by the stanza-id in MUCs, so that once a client receives an edit to a message they don't know, they can look it up from the MUC MAM. 2. Have a functionality like tombstones in message retraction, that is to update the MAM archive, so that when I fetch an edited message from the MAM archive I will learn about the edit. 3. Clarify that dangling edits (edits of a message the receiver doesn't know) should not be rendered. With last message correction, if the reference can't be resolved, most clients will just consider the edit a new message. 4. Figure out the legacy fallback. You can't just use the body, because if the edit is of an older message, that message, when displayed as a fallback, feels way out of context.

> In general if you're doing thread stuff I'd love to collaborate. I think I have the only current attempts at thread ux What's your UX like ? I'd love to see something zulip-like because it ticks all the right boxes for me ↺

rako: my stuff is all very lightweight designed to help disambiguate simultaneous real time conversations. So basically the opposite of zulip. But one could certainly build a fully compatible zulip style UI and people do ask for that too

> rako: my stuff is all very lightweight designed to help disambiguate simultaneous real time conversations. So basically the opposite of zulip. But one could certainly build a fully compatible zulip style UI and people do ask for that too So, more forum-like ? ↺

(I'm curious because I'm curious whether it is better to continue on top of MUC or to start cleanly over with pubsub, but I've no experience so I can't tell)

If you want slow but real time ish like zulip then MUC is fine. If you want very slow forum like then you might prefer pubsub which is what libervia does. The line is getting pretty blurry these days

The thing is, with muc, it seems that there will be issues: 1) a thread is basically identified by its root, so a newcomer needs to crawl back until the beginning of time to ensure there is no parent 2) how to mark a specific thread as "read" but not other messages that might be earlier

hjops

I don't know what you mean "a thread is identified by its root"

You can mark a thread as read just fine. The relevant xeps all account for this

> I don't know what you mean "a thread is identified by its root" I was talking about the subject of the thread, which can actually be set by a <subject>, so it's not actually a question ! ↺

> 3. Clarify that dangling edits (edits of a message the receiver doesn't know) should not be rendered. With last message correction, if the reference can't be resolved, most clients will just consider the edit a new message. larma: that opens up another security hole that spammers can use to spam people using old clients without the moderators seeing...

> You can mark a thread as read just fine. The relevant xeps all account for this The one I'd love to see more deployed, xep-0490, is a "read until that point" per chat, there's no thread-specific marker ↺

Yes there is :)

Oh you're talking about MDS. That's different

Yeah, to me "mark as read" is only for myself, not to signal others what I read 😁

Sure. That's mostly done locally anyway. MDS is not a common thing yet

https://xmpp.pimux.de/file_share/06850273-790a-79b0-bd49-77459fd8db64/Chat%20Happy.pdf This is an HTML page for HTTP, for people who only run an XMPP server. It is produced by a Python script which generates an Atom Syndication Format and an XSLT stylesheet which transforms it into XHTML. Do you know of someone who would want to work on CSS design?

> Sure. That's mostly done locally anyway. MDS is not a common thing yet It's not really local, because it's an issue of synchronizing the state between your devices. It's the number one pain I'm still having ↺

> > 3. Clarify that dangling edits (edits of a message the receiver doesn't know) should not be rendered. With last message correction, if the reference can't be resolved, most clients will just consider the edit a new message. > larma: that opens up another security hole that spammers can use to spam people using old clients without the moderators seeing... Only if you ignore the 4th point (which says you can't just use the body). ↺

This is a good suggestion! https://xmpp.org/extensions/inbox/data-form-file-element.html

It's the start of one anyway. I've had some code to do file upload, but suggested mime types is useful for sure as is suggested Uri schemes (though it'll probably be mostly https for now)

I have sent an email which specifies how I do it an the moment.