XSF Discussion - 2020-12-09

The "Character counting in message bodies" thread on the Standards ML is mildly amusing, we haven't had one of these in a while.

I hope I helped with that :)

It's basically a "someone is wrong on the internet" thread

https://xkcd.com/386/

do we have somewhere a full list of forbidden characters for JIDs ?

RFC 7622 ✏

Kev, I liked your email :D

also, can someone point me at an XML library which really gives you the raw bytes on the wire and how it handles entities? :)

because if we’re going to count bytes on the wire, we obviously also have to count the bytes used for entities.

"have fun with *that*"

I was very much interested in the IoT hot-path where you really need the body character counts, but jonas’ kind of already raised this question.

I think statements like these and "…much easier than writing 20 emails on this topic" are potentially harmful, as they could interpreted as an attempt to suppress discussion. I found the thread insightful (at least some parts of it).

flow, ok, noted, thanks for the feedback

I am a bit annoyed by the thread because I had essentially the same discussion already a few years back when I brought this specification gap up in References.

As far as I can see, it should be codepoints.

jonas’, I get that, but that is probably more an indication that we are not good in transforming those discussions into a specification

(as long as I don’t have to transform my unicode codepoints into entities again to be able to use this XEP I will be happy with the result, so I’m staying out of that discussion)

flow, yeah, because nobody makes a final call

Kev, nice try ;) (or was that not an attempt to resurfcace that discussion here?) ✏

mathieui, oh, why not? don’t you want to guess whether the sender used a instead of 'a' everywhere?! ✏

that would be fun

flow: I wasn't trying to start discussion, I was saying that to me the case is clearcut for codepoints.

jonas’: but what if you want to highlight the "#"?

(Commenting as the References author)

Ge0rG, shush!

I should write an XML serialiser which creates the most expanded version possible of any character data

the recent MS Teams "important, spoofing" issue makes me want to stuff U+0000 into an xmpp message and see where it gets killed.

jonas': Take that, "nobody makes a final call" ;p

Ge0rG, libexpat and libxml2 throw errors at you when they encounter it on the input

so at least prosody should kill your stream

not sure what ejabberd does

jonas’: I think wrapping each character in CDATA is the best you can do

No wait, empty CDATA sections are legal, so you can do a lot better

waqas, oh, that means infinite expansion… let us omit CDATA sections from considerations then :)

Ge0rG: \0 isn't a legal XML character. CDATA sections, entities, etc don't let you work with non-legal characters, they are more an alternate encoding, but work with the same characters.

waqas: I know. But it wouldn't be the first time for illegal characters going places.

You know what doesn't have character counting problems? Embedded markers. Perhaps we could use some special characters to "mark up" sections that have some special meaning.

Ge0rG: You can probably target pseudo-XML parsers that some servers have, e.g., Tigase I think was pretty liberal

Zash: yes, let's use the zero-width-space as an escape character, followed by an xml element defining the markup

Or we could use <> since those are special in xml

I think counting bytes or code points is a mistake, we should instead count graphemes, as that corresponds to what is rendered and the user sees!

waqas: that position is taken already

oh no

waqas: ITYM grapheme clusters.

let’s count rendered CSS pixels

(as opposed to device pixels)

jonas’: I was just about to type 'what about pixels'

^5

We'll just need to include the font and font-size, etc used for rendering, and then we are all set

how do you treat off-screen hidden text?

Or does that need to be configurable?

waqas, no, obviously that’s all available from context.

just like the wire encoding is

https://www.getdigital.de/web/getdigital/gfx/products/__generated__resized/1100x1100/4883CSS-sucks-v2_4883_square.jpg

Yay for binary XML

Don't forget compression

Also accessibility, e.g., if the text isn't rendered but spoken

you also need to reverse count characters in RTL languages

Kev, FYI the unicode spec seems to always talk about "code point(s)", not "codepoint(s)"

not sure if this is a AE vs BE thing

Just a Kev thing, probably.

I'll fix it in a moment once I'm out of a meeting.

Done while still in a meeting.

who said one can't be producitve in meetings?

Ge0rG nice tshirt :D

We could do something similar with XMPP

something like

<message xmlns="jabber:client" to="juliette@foo.com" type="chat" id="62470128-e587-493e-8592-d7bca532e28f"> <thread>6b3fc7be-0480-461b-8f25-0e7117f5b1d5</thread> <active xmlns="http://jabber.org/protocol/chatstates" /> <body>XMPP is not verbose</body> <request xmlns="urn:xmpp:receipts" /> <markable xmlns="urn:xmpp:chat-markers:0" /> <origin-id xmlns="urn:xmpp:sid:0" id="5ee0e98f-eb38-44ac-b698-19c621b7479d" /> </message>

Needs <delay> and <stanza-id>

Yeah sorry :D You can also add the OMEMO stuff as well

Also the somewhat redundant full JID in @from

This will only be available on the XXL tshirts to be readable :p

And baby sized with <presence/> ?

"Couldn't send message: Slixmpp got into trouble." is probably good while voting, right?

Kev: do you contest the vote now?

I think something has gone quite wrong, as it just told me what my four votes were. After voting on five issues :)

I think it really didn't like that I've got two clients running.

I have two clients running and never had any trouble

maybe it's about *which* clients you are running?

Did you try starting voting on one, and finishing on the other :)

I don't remember. But IIRC memberbot is doing evil resource locking things with the votes ✏

That's what it seemed, to me.

never had an issue either and I always run two clients (but do not switch in the middle of voting)

Zash, machine-readable compliance suite data: https://dpaste.org/dEaq/slim

I should try to get the badge generator finished (complete with DOAP processing)

Oh, I also made a thing for generating almost exactly that

lovely

there are some A|B choices in there

I think it's just BOSH/WebSockets though

gui, tui?

also that

avatars isn't a requirement for text-only clients

https://cerdale.zash.se/upload/eQVYwXp3PqMC47-L/xep-0443.json

tell poezio

requirement != restriction

requirements ≠ implementation ≠ deployment

Hi, I know this is a religious question (no troll): But when one wants to if a client runs on Unix... can I just say Linux? 😅️

"Do you mean *nix or UNIX®?"

https://en.wikipedia.org/wiki/Unix

> when one wants to if a accidentally a word?

Okay, doesnt matter really

The XMPP Newsletter for November 2020 is out! This is the last newsletter for this year! Thanks to everyone contributing! Read about an important circumstance regarding certificates to all parties involved in XMPP! Also updates for several clients and servers! https://xmpp.org/2020/11/newsletter-11-november/

argh, typo "comming year", my bad

😩️ - no, really wurstsalat - you did a great job on the XEP section, you are excused!

https://github.com/xsf/xmpp.org/pull/850

thanks Zash !

emus: We are in December.

Neustradamus, oh hush

It's news from November

Bad timing

https://fosdem.org/2021/schedule/track/real_time_communications/

What're we doing with this?

Neustradamus: let us know if you can read the future

Shh. He can.

But he can only write about it in the perspective of a 16th century astrologer

Neustradamus, we are happy for new contributors and reviewers to reduce time on drafting and reviewing.

Could just call it The Newsletter

NeXtLetter.

emus: With new system, I can not contribute into... Badly.

^^ we have "signifcant growth" since this year (seeing email stats). I guess most subcribers are happy 😊️ and also from the personal feedback I receive

Draft problem

Why you cannot?

emus: Hm, if it's published just before the end of $month, with a Call To Action™ at the end of "did we miss something from tomorrow? tell us in the comments/repliy to the tweet/whaever"...

zash, I dont understand what you mean?

Cover november-01 to 28, publish on 29, ask people to reply with the cool thing that wasn't in the newsletter in order to generate more noise. Not entirely serious.

and also make sure cool thing happens on the 29 that people can reply with.

Anyways, don't listen to me, I can't into marketing.

hehe. I personally think it wont really make a change. I introduced the two review phases to get things less pressure on the team and have more time to ensure quality and force everyone to get done in one night (we also dont have the ressources). I think many people read it rather like a summary of the month, or not as hard into the XMPP development as most here are. I think this request comes from a very different perspective than most readers.

For me that is mostly a question of ressources. If I need to squash things together, I cannot do that usually in one evening alone

and also I dont want to do this alone

> For me that is mostly a question of ressources. If I need to squash things together, I cannot do that usually in one evening alone +1 I'm happy with how it works at the moment

Problems in newsletter links, examples: - https://xmpp.org/2020/11/newsletter-11-november/ (December, 09, 2020) - https://xmpp.org/2020/10/newsletter-10-october/ (November, 05, 2020) - https://xmpp.org/2020/09/newsletter-09-september/ (October, 06, 2020) - https://xmpp.org/2020/08/newsletter-08-august/ (August, 08, 2020) - https://xmpp.org/2020/08/newsletter-06-august/ (August, 06, 2020) - https://xmpp.org/2020/07/newsletter-01-july/ (July, 01, 2020) - https://xmpp.org/2020/06/newsletter/ (June, 09, 2020) - https://xmpp.org/2020/05/newsletter/ (May, 07, 2020) - https://xmpp.org/2020/04/everyone-go-for-decentralisation-03-apr-2020 (April, 03, 2020) - https://xmpp.org/2020/02/newsletter-04-february/ (February, 04, 2020) - ... Link problems like https://github.com/xsf/xmpp.org/issues/638

Really time to solve problems. ✏

Yes, and I will go with what the contributors can manage currently

neustradamus - what is your exact problem with this?

I see the links, but what is the issue you have=

?

Look links, date

https://github.com/xsf/xmpp.org/issues/638 it is not solved yet.

Okay, I see, but lets be honest I is too old to fix on that. but what is it with the other links?

And even more imporant, what is preventing you from contributing to the Newsletter?

Cool URLs don't change.

February: https://xmpp.org/2020/02/newsletter-04-february/ -> https://xmpp.org/2020/02/newsletter April: https://xmpp.org/2020/04/everyone-go-for-decentralisation-03-apr-2020 -> https://xmpp.org/2020/04/newsletter May: https://xmpp.org/2020/05/newsletter/ June: https://xmpp.org/2020/06/newsletter/ July: https://xmpp.org/2020/07/newsletter-01-july/ -> https://xmpp.org/2020/07/newsletter August Part 1: https://xmpp.org/2020/08/newsletter-06-august/ -> https://xmpp.org/2020/08/newsletter-1 August Part 2: https://xmpp.org/2020/08/newsletter-08-august/ -> https://xmpp.org/2020/08/newsletter-2 October: https://xmpp.org/2020/09/newsletter-09-september/ -> https://xmpp.org/2020/10/newsletter November: https://xmpp.org/2020/10/newsletter-10-october/ -> https://xmpp.org/2020/11/newsletter December: https://xmpp.org/2020/11/newsletter-11-november/ -> https://xmpp.org/2020/12/newsletter

Neustradamus, I dont see why we need to change the links now. I personally lag the knowledge for this. I can offer you the following, if you want to commit anything to the next release in February 2021 you join the MUC and if you write up a news you have you can post it there and we can commit that to the next draft. However, the PR your self should work, we always provide a direct link from now on. I see you already have a Github account. So that should work

Do not forget that I have been the last Communication team member. I have contributed several years before the new draft system on GitHub which has a lot of problems (bad link names, bad publication dates) Harmonization needs to be done to solve all problems. The problem is not new and people keep... Strange.

I am happy for support, but I cannot do that my self 🤷‍♂️️

In more when you click on the date of all publications: -> https://xmpp.org/blog.html#

It is easy, create a PR with perfect name to all files.

I dont see the problem with creating a PR right now? Anyway, Im out for today

You can see: https://github.com/xsf/xmpp.org/issues/638 -> https://xmpp.org/2019/01/the-xmpp-newsletter-31-january-2018/ -> https://xmpp.org/2019/01/newsletter It will be remove the bad link problem "January 2018" in "January 2019"

Thanks in advance.

Example of Gajim, no problem: - https://gajim.org/post/2020-11-27-development-news-november/ - https://gajim.org/post/2020-10-28-development-news-october/ - https://gajim.org/post/2020-09-27-development-news-september/ - https://gajim.org/post/2020-08-30-development-news-august/ - https://gajim.org/post/2020-07-26-development-news-july/ - https://gajim.org/post/2020-06-28-development-news-june/ - https://gajim.org/post/2020-05-26-development-news-may/ - https://gajim.org/post/2020-04-28-development-news-april/ - https://gajim.org/post/2020-03-30-development-news-march/ - https://gajim.org/post/2020-02-26-development-news-february/ - https://gajim.org/post/2020-01-27-development-news-january/

Thanks for working on the newsletter, it's genuinely something I look forward to every month.