jdev - 2022-12-04

Are there clients implementing XEP-0461: Message Replies https://xmpp.org/extensions/xep-0461.html ?

A client to test against would be nice :)

movim, probably

Dino?

Ah, Movim supports it, thanks!

wurstsalat: not sure if edhelas fixed it, but there was an issue with character counting in the fallback body

but anyway XEP-0426 needs to be updated. it does not mention newlines and how to deal with trailing whitespace. https://xmpp.org/extensions/xep-0461.html#example-2 just omits newlines and trims left and right whitespace on each line before counting. I think trimming trailing whitespace on each line makes sense, but not counting newline does not seem sensible to me. I planned to submit a patch for this example and also for the character counting xep, but haven't done it yet.

let me know if you reach the same conclusions as me wurstsalat. by the way, you have a xep-0461 implementation in python-nbxmpp yet?

nicoco: yep, I have a prototype in nbxmpp and Gajim. it seems to work fine with Movim, back and forth :) no issues counting characters in the fallback though. I noticed Movim doesn't add a newline after the fallback, yes. But that doesn't affect counting. It just works so far

so you just count everything in the fallback with python's str.__len__()?

because this definitely does not work with example 2: ```python >>> len(""" ... > Anna wrote: ... > We should bake a cake""") 46 ``` (start=0, end=36 !?)

stripping trailing (left and right) whitespace we almost arrive at 36: ```python >>> len(""" ... > Anna wrote: ... > We should bake a cake ... """) 39 ```

but to actually have 36 as in the example we need to not count newlines. Do you think that's sensible? Whatever the conclusion is I think that XEP-0426 (Character counting in message bodies) needs to mention what we do with newlines and left and right whitespace on each line.

also it should mention explicitely that the "char" at position "end" is included in the count (unlike python's slicing conventions btw ;))

nicoco: removing the fallback works fine with slicing strings, and counting chars of a quoted fallback body works fine with len(). Those are my observations so far. And yes, xep-0426 should be explicit on how to deal with newlines I think (it just works in python). I remember wild discussions about whether to include the end char or not ;) strange that it didn't land in the xep

if it works fine with len(), then example 2 of the message replies xep is wrong :)

> examples are not normative I guess this applies here, and I would think the prefixed whitespace is for indentation only (clarity)

but yes, better to be explicit

Well, arguably for something character-counting clarity, indentation does not help clarity

I share the same conclusion on the prefixed whitespace. But then newlines aren't counted either in this example. I wonder if that is intended or not :/

> Well, arguably for something character-counting clarity, indentation does not help clarity as long as there is a disclaimer, I'm fine with the example as it is. but yeah, adding that seems like a good idea to me

> if it works fine with len(), then example 2 of the message replies xep is wrong :) for newlines, yes

nicoco, examples are often wrong, i see the xep leaves out what is exactly counted, but its not sensible to strip anything anywhere

its a big string, and i want the point in the string where the quote ends

hwo many newlines the user made and where should not play a role at all

counting codepoints seems the best way in my opinion, and what python does with inbuilt len

and im sure many other languages also offer a method of counting the codepoints

thanks for your clarifications. just in case this was not clear, I don't have a strong opinion on how this should work, but just wanted to have some more feedback since edhelas, deuill (not in this MUC) and I struggled to make sense of this fallback character counting thing, so I think it can be seen as a sign that there is room for improvement. :) I'll submit a PR soon™

I'm counting the carriage return as an exra character on my side

The best would be to add a simple example on two lines and show that the carriage return was counted as one

> Some programming languages include a string type that operates directly on Unicode code points. If these types are used, offset numbers can be used as-is in string operations. Popular examples of such programming languages are Python and Haskell. from XEP-0426

edhelas, Movim isn't adding a newline at the fallback body's quote end. that fails in Conversations for example, as it renders the reply inside the quote

this is sureley a oversight

wurstsalat https://github.com/movim/movim/commit/a7d568466cfee46870b3fb7295a9ecf4a848443a

;)

great! :)

nicoco: > wurstsalat: not sure if edhelas fixed it, but there was an issue with character counting in the fallback body Wasn't that from a different spec? When I looked it wasn't even acceped.

So you are all just implementing the examples?

I usually use the examples as test cases, but I'll adapt my strategy now that I know that they're non normative. :)

Zash: you're right, I had forgotten that message replies seems to refer to this protoxep: https://xmpp.org/extensions/inbox/compatibility-fallback.html which is different than xep-0428.

IIRC the idea was to merge them?

Implementing and _deploying_ unaccepted protoXEPs ... what could go wrong?

merging them sounds sensible to me. the current situation is confusing. I did not realize message replies referred to a protoxep when I implemented it in slixmpp...

where does `urn:xmpp:feature-fallback:0` come from? registrar, where are you?

Even implementing and deploying Experimental XEPs is risky, since they're subject to change at any time.

larma, is there a Message Replies implementation for Dino somewhere? any plans to clarify XEP-0461 + fallback ? :)

wurstsalat, partial implementation, yes. Also XEP-0461 will use the fallback element from XEP-0428 once its v0.2.0 https://github.com/xsf/xeps/pull/1188/files is merged

larma, will there be any reference to the counting informal xep?

larma, thanks for clarifying! I see characters counted in the PR's example are counted including newlines :)

lovetox, you mean informational? yes ✏

yes, the number in xep-0461 is currently wrong. I planned to combine this with the update once the situation with fallback was clarified (I actually do have the change locally already), but that happened to take longer than expected...

larma, thanks! was there any reaction on your fallback 0.2 PR since July that I missed?

btw https://logs.xmpp.org/ supports XEP-0461

and that's how I noticed the fallback thing

for completeness, the correct end in 0461 is 38. That is the number of characters of: `> Anna wrote:\n> We should bake a cake\n` ✏

wurstsalat, there is currently a vote going on in council to make me author of XEP-0428 so that lack of feedback from dave does not block this anymore. So the situation is probably going to be resolved soon.

good news! :)

good news indeed. thanks larma for the clarification of the count number in the xep example. also, for some reason I never realized I should not take into account the leading whitespace that is "pretty formatting" the stanza. wouldn't it be better to "ugly format" the stanza in examples involving char count?

nicoco, I think "ugly format" makes things much harder to read, but we could at least put some warning that this was reformatted for readability. ✏

I think a warning would be great! for small brain amateur devs like me 😬️

Do MUCs need to broadcast presences from all participants on join or is there a way for a MUC to say: ‘I have 1500 participants, but here’s the presence of the last 20 active chatters’ to clients that join it?

I don't think there's a way to say it exactly like that, but there are similar optimizations possible.

Nothing prevents you from only sending the last 20 active (I would probably opt to always include moderators), and including presence when others say something.

But then you have to keep track of who's seen what

There is a thing in MUC for _not_ broadcasting presence for some roles. Usually you'd hide visitors for example.

There's also https://xmpp.org/extensions/xep-0463.html but it's about affiliations.

Was there one for presence?

In my context, keeping track is rather straightforward since there’s only one ‘real’ xmpp user, so I like that option. But ideally I’d also like clients to reflect how many people really are in the room, because even if I can’t get the nicks of the 1500 users, I have this info. I guess I can include it in the room subject or something.

Personally I feel like this goes in the "meh, save it for the MIX rewrite" ;)

I imagine in MIX this is simply a paged pubsub query

Oh, I do think there's a metadata field for participants?

"muc#roominfo_occupants": "80"

Hehe MIX, yeah. I’d like to give MIX a try but since I also want to use my gateway in a foreseeable future, I decided to have MUCs too :). FWIW the telegram api does more or less that. It’s not ‘paged’ though, you don’t know how many participants you’ll be able to retrieve in a single request, the server decides.

That sounds funky

muc#roominfo_occupants is exactly what I was looking for, thanks a lot

Generally I believe all clients should handle messages from participants even if no presence was sent, tho there may be exceptions.

Otherwise they would have had trouble with the recent history included on join, if any of the speakers there left since

This makes sense and is consistent with my little tests so far with movim and gajim

I think there's text somewhere in '45 about sending a presence probe to get fresh presence