jdev - 2025-06-15

reading https://xmpp.org/extensions/xep-0184.html#format it seems like delivery receipts can be of any message type? (so chat and i forgot what the other 1:1 type message is)

mellium requires you provide the router with the type of the message youre looking for hence why i ask

or wait theres normal and headline and a couple others, my bad

it would be helpful if i read the highlighted text > Note: It is a good practice to use the same message type as the message that requested the receipt, however a client SHOULD also accept receipts with a different message type.

you react to type=chat for a 1:1 conversation, and to type=groupchat in a groupchat if you want to support that

> you react to type=chat for a 1:1 conversation, and to type=groupchat in a groupchat if you want to support that lovetox, no, i mean the type of the message of which the `<received xmlns='urn:xmpp:receipts' id='richard2-4.1.247'/>` will be sent within ✏ ↺

yes, you have a handler for type=chat, then you know only messages will be given to the handler that have type=chat, so you send your received with type=chat

> 2025-06-13T14:09:01Z - theTedd: > The example has "affiliation='member'" when it should be 'owner' And the message tag, I suppose. ↺

> yes, you have a handler for type=chat, then you know only messages will be given to the handler that have type=chat, so you send your received with type=chat yes, i am sending as the same message type, however the doc explicitly says i should be prepared to recieve them as a different message type than the message i sesnt ↺

you need to expect everything, people build the stanzas, they can put in anything they want into the type attribute

the question is, what do *you* want to handle

and thats what i would implement

https://downloadable.pain.agency/file_share/0684e79c-8c48-7c68-aa03-064faf02a7bb/b307c109-aaa7-481b-aa4f-76800ab5c974.png

if you send a request for receipt with type=chat, most clients will answer with type=chat, if thats your question

> if you send a request for receipt with type=chat, most clients will answer with type=chat, if thats your question that was my question yes ↺

and i would not think at this point on client who do not, because they go against the explicit recommendation of the XEP

so they cannot expect all clients to support this

alright

i'm also following the recommendation of the xep and not listening for one from MUCs

> 2025-06-15T07:46:25Z - jjj333_p (any pronouns): > i'm also following the recommendation of the xep and not listening for one from MUCs Yeah, I remember someone disputing the plurality of notes in Ad-Hoc spec (here or not?), because… real usage… vague interpretation… whatever, they're just lazy to implement multiple notes lol, and seek for justifications. ↺

(the same time, I'm afraid to implement correcting non-last messages, even though the real usage shows it actually works and I don't know clients where it doesn't for sure)

> (the same time, I'm afraid to implement correcting non-last messages, even though the real usage shows it actually works and I don't know clients where it doesn't for sure) im far from that point but imo in anything id call a "nice messaging app" its pretty unacceptable to only be able to edit the last message, so i will be implementing that and just hoping for the best in terms of other clients supporting it ↺

in general here im prioritizing features over compatibility with legacy clients, especially when its been a thing for many years

> (the same time, I'm afraid to implement correcting non-last messages, even though the real usage shows it actually works and I don't know clients where it doesn't for sure) Conversations? ↺

yes features are good, but if you are the only client who supports it, then you also need to think how that will look on other clients

Gajim accepts older corrections, but does not allow to send them

i also dont think it makes sense to allow to edit a year old message

but i also thinking about allowing the last X messages or so, definitly something i want to do multiple times a week

> yes features are good, but if you are the only client who supports it, then you also need to think how that will look on other clients my understanding is most current clients behave this way. ive not seen any issues arise from applications just written so shitty that it happens (bifrost) ↺

however if it gets to that point i might get me an android emulator and make sure across my guestimation of popular clients

> i also dont think it makes sense to allow to edit a year old message Messengers that do allow message editing usually have no restrictions, AFAIK ↺

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

modern dino and gajim on pc seem fine, im not sure if monal even supports edits

> Messengers that do allow message editing usually have no restrictions, AFAIK signal and such only allow retractions and edits to like 3 hours i think (could be wrong on the time, but its less than a week), and imessage only lets you "unsend" or "correct" within 15 minutes ↺

about message reactions ( https://xmpp.org/extensions/xep-0444.html ) is it generally common practice for clients/servers to reject non-emoji reactions?

im quite a fan of how many many matrix clients allow freeform text reactions

the xep itself doesnt mention any inherent restrictions, just that an error might be returned

> the xep itself doesnt mention any inherent restrictions, just that an error might be returned > A <reaction> element SHOULD only contain Unicode codepoints that can be displayed as a single emoji, as specified in the latest revision of the Unicode® Technical Standard #51 [7]. Receiving entities MAY ignore <reaction> elements that do not comply with this specification. ↺

ah, i failed to read again, my bad

secondary question, when a xep says _should_ how strong is that? as in if i dont follow it im not really following the xep or room to play just dont expect other things to support it

> secondary question, when a xep says _should_ how strong is that? as in if i dont follow it im not really following the xep or room to play just dont expect other things to support it SHOULD, MUST, MAY and others are an RFC thing ↺

SHOULD means the same as MUST (unless you have a really good reason)

sad, i was hoping for freeform reactions to be a thing 💔, thats good information going foward though

> SHOULD, MUST, MAY and others are an RFC thing https://www.rfc-editor.org/rfc/bcp/bcp14.txt ↺

MAY is what gives some room for choices

> This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

Speaking of SHOULD meaning should what clients out there support <thread/> elements properly

As in at all

Their 'good reason' is that the UX is difficult 🙃

Trying to figure out how to assign messages to threads when messages without <thread/> are received in a way that'll work properly

would it be a particularly bad implementation of the reaction spec to do like signal/whatsapp/telegram/imessage and allow the user to only send one reaction? as in it would still support recieving multiple but if the person using the client chooses to send one it sends only that one new reaction and removes the old one?

i guess that comes down to ux, and is technically compliant either way

i.e. how to determine a part of which conversation a particular message is likely to be

(Outside of ones with direct references which would make it trivial obvious)

> Trying to figure out how to assign messages to threads when messages without <thread/> are received in a way that'll work properly One way is to have a 'main' default thread where all message go unless otherwise connected to a thread ↺

> Trying to figure out how to assign messages to threads when messages without <thread/> are received in a way that'll work properly XEP-0201 specifies that AFAIK ✏ ↺

It doesn't appear to

>> Trying to figure out how to assign messages to threads when messages without <thread/> are received in a way that'll work properly > One way is to have a 'main' default thread where all message go unless otherwise connected to a thread What if a user is in one of those threads, and their conversational partner switches to their phone client which doesn't mirror <thread/> elements?

Then they're not using threads, but there's not much you can do about that

We'd still have to handle it as best we can or just... also not support <thread/> elements

If you're responding to their non-thread messages then you messages are also in the non-thread

A naive but probably not worse than any of the others idea would be figuring that the last <thread/> which saw activity should get the message

That kind of thing works until it doesn't, and then it's worse than not doing it in the first place

> If you're responding to their non-thread messages then you messages are also in the non-thread No, the users are still in the same conversation, but one of them went AFK and their phone client doesn't even look at <thread/> elements

Perhaps the bad UX would cause both conversers to put pressure on the devs to support the feature

So they just see the unstructured messages, and your threaded replies are unstructured for them too

Another (and, maybe as important) question is: should be last message's `subject` used as a thread name? Unnamed threads are pretty bad UX…

But all of this is part of: the UX is difficult 🙃 ✏

The last <subject/> makes sense

Perhaps only if the <message/> containing it didn't also have a <body/> element

Depending how you present them, you could change thread subject midway

That's about how this power users' client on which Goot is working works presently

<message><thread>asdf</thread><subject>Shopping list reminders</subject></message>

> Perhaps only if the <message/> containing it didn't also have a <body/> element I hasn't seen any client that sends `<message/>` without `<body/>` for `chat` or `groupchat` ↺

And i doubt that any clients actually show message `<subject/>` or allow to change it

Except things like receipts etc?

They should

Message without body is used for many different things, except for user-generated messages

Do reactions count

Clients that support MUC generally display its subject

Yes exactly. Should means you should expect things might break if you do it, but doing it isn't out of compliance per se ↺

> i guess that comes down to ux, and is technically compliant either way 👍 ↺

> Clients that support MUC generally display its subject Ah, i forgot that MUC relies on `<subject>` ↺

> i.e. how to determine a part of which conversation a particular message is likely to be If there is no thread element it is part of the "null thread" conversation or if you prefer it's not part of any conversation at all or in some cases you may wish to reject such messages ↺

But explicitly must ignore <message><thread>asdf</thread><subject>This is the subject!</subject></message> elements

So, the `<subject>` thing for threads would work only if a message has a body ✏

> So, the `<subject>` thing for threads would work only if a message has a body Not necessarily

> But explicitly must ignore <message><thread>asdf</thread><subject>This is the subject!</subject></message> elements Needs research on whether any server does that ↺

Subject doesn't need a body, and is usually separate

Servers probably just forward them as-is

And/or store them

>>> Trying to figure out how to assign messages to threads when messages without <thread/> are received in a way that'll work properly >> One way is to have a 'main' default thread where all message go unless otherwise connected to a thread > What if a user is in one of those threads, and their conversational partner switches to their phone client which doesn't mirror <thread/> elements? You can't build your life around "what happens if they use a different app which is busted". Heuristically guessing that their app is lying about metadata this way lies madness ↺

But don't otherwise treat them special

They're still normal message stanzas, even without a body

> Another (and, maybe as important) question is: should be last message's `subject` used as a thread name? Unnamed threads are pretty bad UX… What I've been doing is that a message with only subject and no body sets thread name ↺

> So, the `<subject>` thing would work only if a message has a body Or a thread ↺

> Servers probably just forward them as-is If MUC servers don't ignore messages with both `<thread/>` and `<subject/>` but with no `<body>` then any attempt at changing the thread subject would actually change MUC subject ↺

They do; it's a requirement

Muc servers do ignore this, both per spec and in practise

Rather, they don't treat them as subject changes

> Muc servers do ignore this, both per spec and in practise Ah, ok then ↺

Some clients were broken about this but most got fixed after I started sending them

In general if you're doing thread stuff I'd love to collaborate. I think I have the only current attempts at thread ux

Would also like to see that

Wonder how different our ideas are

Cheogram Android and https://app.cheogram.com both have some UX, with android being the most mature

> 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 ↺

But this would actually work if and only if all participating clients do this

> 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 ↺