XSF Discussion - 2019-03-28

I can't remember the last time a standards@ thread triggered carlo

Heh

> Within the limitations of XMPP, your ideas are among the least worst. Can we have motivational posters printed with this one, please?

:D

https://datatracker.ietf.org/meeting/104/materials/slides-104-mls-mls-federation-00

Seve, Thanks for this. I've not looked when the WG meeting itself is, I thought I might listen in.

dwd, meeting happening now, I can't follow it but the room is this one: mls@jabber.ietf.org

More slides are being shared there

Ah - you'll want the audio etc too.

But I don't think I really understand more than one word in five when they start the serious cryptography.

:D

Yeah, there's audio stream available as well, but I'm at work anyway, can't follow anything (implying I would understand something, which is most probably not :D)

PFF you're away from the list one day and there's already a full thread on markup formats

Was a week ago a good time to poke someone about https://tools.ietf.org/html/draft-ietf-acme-email-tls ?

dwd, appreciate your email response to evgeny

as did I.

Although I have to admit that evgeny's mail made me chuckle.

But yeah, neither carlo's email nor the response added much or even any value to the discussion

Let's not single out one person - there's a lot of this going on, sadly.

It causes me (and thus very likely others) to not participate in discussions like this.

which hurts standards development (not that I'm bringing to much to the table, but if more people are discouraged, this becomes an issue real fast).

I literally discarded a draft email to that thread, for "I don't want to waste time arguing right now" reasons.

the whole thread was tl;dr. Am I missing out on drama?

Feels more like a holy war than drama

much of the same: "everything is broken and you're not dipshits for even considering other options than my solution."

it's... discouraging.

I tend to believe that this is something that can not be settled in a discussion, but has to be settled by the ecosystem

much of the same: "everything is broken and you're dipshits for even considering other options than my solution."

flow I tend to agree. Sadly, implemenation in the ecosystem takes time, which fuels the 'why isn't this fixed yet' thought.

There's a conversation about behaviour in technical debate in the IETF list at the moment, but I'll say here what I'm currently writing there:

Yes, people should not be assholes - because it's vastly less efficient as well as the more obvious social things.

"... and you're all dipshits for not taking my word for that!" <-- right? 😉

To be fair, maybe I missed something, but apart from two emails I found the discussions quite constructive so far

But also, it's worth picking out the technical argument from things and treating it independently from the aggression.

MattJ I'm not ruling out I've started to be oversensitive at a certain pressure point.

MattJ, I could cheerfully point out several emails in there that I felt added very little, if anything, to the technical debate.

MattJ, And, in addition, had a distinctly aggressive air.

"Please, everyone, ensure your messages are like an efficient light bulb - optimise for light, not heat." very spot on :D I like it very much (and it works with the jabber icon)

MattJ, possibly. I also found the thread to be civilized for large parts. The "holy war" remark was not meant towards that specific thread, but the situation regarding rich(?) text in XMPP as whole.

Can we un-deprecate 71?

We can do anything, if you can convince the council

It was deprecated solely because of the security implications, right? Specifically: that it's very complex to have an implementation that is secure.

Even though the spec itself does not have obvious security issues.

And the security problems are in the Web, not the spec. "Not markdown" has the same problems.

Also the same web clients that had security flaws in their XHTML-IM often also had security flaws elsewhere (like not escaping nicknames)

nothing to do with XHTML-IM

In fact, you can get the same problems without rich text support

But using XHTML-IM invites people to just dump it into the DOM ✏

waqas wrote a safe sanitizer for it, fwiw, and it's not complex

People will just dump "not markdown" through a markdown lib into HTML and dump that into the DOM

Well, the feeling in Council wasm't that XHTML-IM was the sole source of security issues, it was that it was very hard to avoid security issues.

(it's linked from the modernxmpp docs)

And, in addition, that many uses of XHTML-IM went beyond the subset it mandates anyway.

I'm biased on this. Good thing I'm not on council 🙂

not biased - but I'm undecided.

The opposite of biased? :)

I can't make up my mind.

I agree it's not a simple issue

And if you're making fun of my English, I move that we start using Dutch as the primary language in here. Where I have the same problem, but at least you won't notice then. 😉

However I tend to agree with Andrew Nenakhov that we shouldn't artificially limit what can be done (e.g. about text in hyperlinks)

Otherwise people will just make up their own stuff which will probably be worse in the long run

agreed.

I'm also a big fan of "I've implemented this and it works".

Right

Not saying we should just adopt those ideas wholesale and verbatim, but it does strongly suggest there's some solid ideas to get from the work.

Also the argument that OOB exists and works isn't accurate, OOB is a hack implemented by Conversations and adopted by others

I'm not against OOB (in fact I like it), but Conversations has broken it (<desc> can't be used, for example)

Also it's implemented by others is wildly varying ways - I've been doing a lot with it recently.

Gajim, for example, requires the URL in the <body/> to triger rendering the OOB.

That's from Conversations

https://docs.modernxmpp.org/client/protocol/#communicating-the-url

I guess "and Gajim" can be added there

That behavior originated in Conversations

and there are two reasons, one of which is that Daniel didn't want to have to change the DB schema :)

And before that it was just the URL by itself in <body>

The other is that it's a sensible fallback, and ensures that a user of a fallback client client doesn't lose any info

"I'm also a big fan of "I've implemented this and it works".", Poezio and gajim have implemented xhtml-im and it works :P

:)

10:39:10 dwd> I'm also a big fan of "I've implemented this and it works".

I’m not

especially not with influential implementations.

because it’s typically already deployed in the wild at that point and then everyone *has* to follow suit

(Styling intended)

Yeah, I'm also half-half on that, mostly because of what jonas’ says

Hence the follow-up statement.

I need to reply to that thread anyway.. noticed a few funny statements (if only a few)

you dont understand the reasons behind the oob thing

also its weird dwd that you want to control what the client of another person shows or does

its really nothing you should think about

btw you dont have to use oob at all with Gajim, if the user chooses he can let Gajim show and load *all* links, it doesnt matter if they have a oob element or not

The Web is so great, we can't do XMPP without it.

lovetox, I'd just like to send an image to someone. It's not about controlling if the user sees it inline or not, it's about expressing intent.

lovetox, Compare and contrast with RFC 2183, which allows people to indicate if the MIME part is intended to be an attached file or an inline portion of the message.

yes your intent is declared when you use oob

you dont need to follow body==oob url logic

if a user uses http upload to share a picture, he communicates a URL, i as a client add a oob tag to tell another client, that the intent is a shared image that the user specifically uploaded, so not a copy paste of URL from somewhere

because we also need a fallback for clients that dont support oob, this results in oob url == body

for this particular case of sharing something

that does not mean that oob cant be used in other ways , like adding a description

if your client has support for adding a description to uploaded content, tell me and i will make it look good in Gajim

i didnt saw something like that though until now

lovetox, the problem is that if you put anything in <desc> it is ignored by Conversations, and any other client

so the sensible thing to do would be to put the <desc> content also in <body> for fallback clients

yeah and? open a issue on their tracker for it

But then Conversations will stop displaying it inline

Daniel knows about it and doesn't want to fix it, because it would require a schema change in the Conversations database

yeah and?! Because one client does not support something now we stop using it?

I mean, he didn't say he would never fix it, but it's not priority, and it means that <desc> can't be used in practice today

i dont get this kind of argument

Tell that to all the users of Conversations :)

lovetox, But opening an issue on the tracker would surely be trying to control how a client presents some data?

"When your client sends me a message, it doesn't display"

"It doesn't work in IE"

then he doesnt see the description

whats the difference to now where you cant add one

because it doesnt show it inline anymore

so you want to control how the image is displayed

If you wanna make everything worse, send the description in a separate message.

Link Mauve: didn't you intend to post to standards@ about MUC Avatars and how to move forward?

Didn't I intent to just load mod_pep onto a MUC and call it a day?

>yeah and?! Because one client does not support something now we stop using it? Out of context somebody would think we should rename XMPP to Conversations :)

"ejabberd - a Conversations™ compatible server"

It would be funny if it wasn't about the abuse of trademarks and the sad state of XMPP.

Well since xmpp stands for messaging and *Presence* protocol, I could hardly call Conversations an XMPP client at all 😂 XMP, or XMPp at best

"MattJ> But then Conversations will stop displaying it inline" maybe someday we'll finally rename to The Conversations Protocol.

conversations does funny things when you simply slap an OOB tag on all the links

Well that's a conversations problem..

Btw, is it just me unable to find a setting, or there are no roster groups at all?

What do you mean?

Andrew Nenakhov, possibly there are not roster groups at all

Define "roster groups"

They are, but look like tags, I think

you don't have to add every aspect of the protocol to your (G)UI, and some argue that they do more harm than good

Seve, I can't find even tags now

Roster groups in COnversations are indeed displayed as tags. It's a reasonable rendering of what they are, in fairness.

I agree with that semantically they are tags. I just somehow don't see them at all now.

There's a setting somewhere that make them show up in the "start conversation" view

How does Xabber handle roster groups? And how are they named in the UI?

Like it should. ☝️

...

Andrew Nenakhov, oh, so you’re doing tags, too? :)

Of course, no )

hm, I find tags much more useful

My co-workers don't. We are using Xabber for Web as a daily driver desktop chat app. Briefly experimented with tag based groups, quicky dropped cause everyone hated it

So like, 'redsolution' shared roster groups to list all active colleagues and their presences, 'developers' 'managers'

+1 for tags. Just to annoy Андрей.

Lol

the concept of a contact list is deprecated anyway. all you need is a search/address bar where you can type things.

Tell that to my managers, lol

aren't you the manager? I thought so...

Then tell me how far they've sent you

Andrew Nenakhov, https://sotecware.net/files/mlxc/02-tagsinput.webm FWIW

Andrew Nenakhov: or is everybody managed by FSB now?

jonas’, the main use pattern of using groups was to scroll over them to see who's online, sorted by relevant groups.

Andrew Nenakhov, I see

I became headaches when thinking about how to deal with the situation where a user attempts to do conflicting changes to the same contact in multiple groups

and I prefer the tags UI anyways

jonas’, like, what conflicting changes?

Andrew Nenakhov, or to put it another way: I found it to be confusing behaviour when changing a contacts name in one group affects the contact in another group

jonas’, I don't find it confusing. Maybe because I have good interfaces.

maybe

if it's a tree, it's confusing.

because you imply that one contact is multiple leafs.

and if it's not a tree but a DAG, it's even more confusing because nobody will understand that.

hm tags sound like a good idea

lovetox, I think they are! https://sotecware.net/files/mlxc/02-tagsinput.webm

lovetox: please fix the dialogs where a JID is split into locapart and domain first

I have another clip somewhere where I showcase the UI to manage tags on a contact, but I can’t seem to find it

jonas’, anyway, I fully understand the reasoning behind tags approach. It just didn't stick with my personnel do we dropped that option for now

Ge0rG the account creation dialog is on my list

lovetox: I recently encountered it in the Join MUC dialog

but it is a big thing, because it contains so many workflows

lovetox: also are you following https://docs.modernxmpp.org ?

IBR, Anonymous registration, proxy settings etc

this must all be done in this one dialog

account creation is kind of special, because you need to specify the server first

Also: https://github.com/modernxmpp/modernxmpp/issues/7

if you think about it, to have a really good account creation/adding GUI you need to support a shitload of things

you need Forms support with nice looking GUI, you need catpcha support with Forms, you need BOSH, http proxys, socks5 proxies, a lib that supports IBR really good with giving meaningful errors if something does not work

and at last you need to handle the 7 different allowed methods that a server can offer you the IBR registration

lovetox: what's your point, again?

lovetox, if there really are 7 (which I hope not), I'm pretty confident you can ignore some of those

that it sounds trivial to make a good add/creation dialog

but it entails many things to do it really good

I can think of simple (no form), form, or out-of-band

MattJ: Don't look at mod_register_redirect

lovetox, would really appreciate anything you can bring to the modernxmpp docs

lovetox: I never claimed it's easy :D

MattJ i referred to the table of death in the IBR xep

my own client only implements half-a-method

Ha

It doesn't actually seem that bad

out-of-band registration _is_ bad.

The table is possibly a little excessive. For a client that supports forms, it's basically telling you to always use that if the server offers it

I mean it's working more or less on PCs, where it's not so hard to type a username and a password, but it really sucks on mobile

Ge0rG, agreed

_especially_ if you need to solve some 64px klingon captcha on your 1080p 4" display.

(which reminds me of the misdesigned xmpp compliance badges with the tiny fonts)

And guess how many clients actually support anything but username+password

You're making me sad

3?

Ge0rG, by "number installed" instead of "number of software projects"? likely! :)

This is where it turns out those 3 are the libpurple ones.

somebody write an android transverter from data forms to ui widges

!

Pidgin supports dataforms

Or, some sort of extended IBR at least

Board: I'm getting a service person visiting my house somewhere today. He hasn't been here yet. Luck shall have it that he'll arrive just when the board meeting starts.

I might be unresponsive.

Noted, thanks!

I've heard that moparisthebest volunteers for the Editor role.

Yeah it's the form.

That guy is pulling up now.

Impeccable timing

Afk

MattJ, feels like it's just you and me

Your friendly ex-officio COuncil Chair is here too.

_o/

that Council Chair could do their voting duty as well :D

Ge0rG, Yeah.

Hey

0. Welcome + agenda

Who? What?

Me

Seve: I think you had something to say about the agenda?

Yes ralphm.

I moved a bit the items that we have for discussion to give them some time as well. I was fearing that we would stick to juts one and don't discuss the rest.

just*

Ok.

Some of them look like they need less time than others, so I thought this would be a good idea to have things done.

Sounds good

1. Minute taker

dwd?

I will, sadly, be disappearing into a meeting shortly, sorry.

:-(

Anyone?

I'm back

Had network issues.

Back, too.

2. Server outage post-mortem

Guus' point

We've discussed this two weeks ago, iirc

Right, I wasn't sure if it needs to be on here still.

We did. Not sure we actually got anywhere though, or if there is anywhere left to go

Don't recall any action

I'd like to see if we want have improvements, and if so, discuss how we improve things.

ralphm volunteered to talk to intosi during practice about this.

(unsure what practice)

Indeed I did, and haven't yet, so I will try today.

We have rehearsals on Thursdays, me on drums, him on bass.

3. Automagically merge PRs from authors.

Let's, as board, decide if we want things to improve somehow

if not, we need no furhter action

if so, we should facilitate furhter action.

MattJ?

ah, we're moving on.

Guus: I'll first have that chat.

(and put it as a todo in Trello)

Presumably you'd want to merge only on Experimental?

dwd, yes

This was prompted by a remark from zinid, and how he's frustrated by the round-trip times regarding publishing to (Experimental) specs where he is the author

He'd like to commit, and see it rendered

How would you implement this? Just allow authors merge control and have them merge themselves?

My counter was that PRs are a typical workflow in just about any open-source project

Is that worth the trouble of implementing some kind of access control system?

Well right now the Editors are the access control system

If he just wants to have things rendered, local rendering works just fine for me?

ralphm, rendered for others to reference as well

You can rather easily publish the rendered html

Ge0rG, not on xmpp.org, obviously

MattJ: do you have an idea on this would work?

how

If we can automate more, I don't see harm in doing that. If the task of automating things takes more resources than doing things manually the next few years, I see no point in automating stuff.

MattJ: obviously. But replacing the editors with some kind of bot that can check the identity of a github user against the author field in the XEP is not trivial

I'd like to hear Editor feedback on this idea - I know jonas has made a lot of progress with automation

a second pair of eyes before we _publish_ things seems desirable, though.

What's there for board to decide, here?

I'm just relaying feedback from an author, that the times between submission and publication can be long, and trying to avoid the "but we're all volunteers" response

if Editors choose to further automate things, yey for them.

I'd be ok for the Editors to form their opinion on this and change (or not change) their processes accordingly.

Guus, Board oversees the submission process, so I think it's a relevant point to receive feedback on that process from the people using it

we should try and optimize things, sure. People could also volunteer to take up the role of Editor - something that was requested repeatedly.

I don't think it really affects our procedures.

MattJ I don't see this as a process change though?

Guus: agreed, more Editors FTW

Guus, not necessarily, no

But you did make the comment about "a second pair of eyes"

Anyway, if we want to conclude that this is up to Editors, that's fine by me

I'm not against automation at all. If Editors want this, and if we find someone to do the automation, by all means.

MattJ: I do think for now this is up to the Editors

Sounds good to me

4. High Profile XMPP Uses

I saw a bunch of things on Trello, what do we need to discuss?

We were brainstorming, to put it simple, I think.

Trying to figure out what can we offer to these "High Profile XMPP Users"

I'd like to see a plan developed that leads to someone reaching out to organisations.

we can discuss that plan. 🙂

Right, in that case, let's put it at the top for next week.

5. Tigase & XMPP Logo

nyco: what's this?

they wanna use the logo, asking for authorisation

This is explicitly about the XMPP logo, and not related to the Jabber trademark?

yep, I could ask, to double check

The logo is, IIRC, public domain isn't it?

I *think* it is licensed Expat/MIT

I was going to *think* the same.

do we have that written down somewhere? 🙂

I was pretty sure so, but I can't find any reference right now

We have had. From my recollection it falls under our IPR policy. Would be good if stpeter remembers.

I'll send an e-mail to ask

In any case, the copyright is owned by the XSF, so you can license it however you like, I think.

Yes, but if we already have, it would be nice to know which one we used.

let's ask Peter, and make sure to re-instate a description on the website.

for future reference.

+1

Can we preemptively tell Tigase that they can use it?

Seems fine to me

Yes

seems like we need to figure out the 'how', not the 'if' they can use it.

I'd say yes, I use it without asking... should I remove it?

no point in making them wait for that, right?

I think that's it.

agree, Guus ✏

6. AOB

?

None here

nyco can you tell Tigase?

I will

next week DST

for ... everyone?

7. Date of Next

+6D23H

:)

wfm

8. Close

Thanks all!

change of time

nyco: you missed the DST comment?

I failed to understand...

Daylight Savings Time

that's +1 then

:-D

all board members will meet at the same time-of-day as today.

that's clearer for my poor mind

Please, can somebody retroactively make minutes from this?

it'll just not be 7 times 24 hours later, and for US-based people, the time-of-day changes, as compared to today.

The XSF Events calendar has the right agenda item for the board meeting - just follow that, and you're fine. 🙂

Guus: it is pinned to local time, right?

yes. It is pinned to local (I think London) time, and explicitly not to UTC.

weird, in scifi movies, when a spaceship reaches a planet, no one ever asks about time and timezones, they just land earth should do the same: one unique time for the whole planet, no timezone, just a "planetzone" and yes, some countries would have their mornings at 0:00 and some would go party in the night at 07:00 😉

UTC, yes

the EU is trying that right now.

:)

(and the reference point would be Paris, of course...)

nyco whenever a spaceship arrives at a planet, they can raise the relevant ruling party immediately. They're not even in the bathroom, ever, let alone asleep.

But unfortunately, it's harder to change the local starting time of events than the offset of local time to the sun.

in the future, the human does no pee anymore

diapers.

Viva das .Beat

Time in Star Trek is complicated.

ralphm: s/in Star Trek//

I think in general they use a 24h clock, but DS9 is on a 26h day schedule (to align with Bajor)

It's all wibbly-wobbly

Interstellar (the movie) is fun with time. Unsure if it's accurate, but it's fun.

ralphm: yes, they are using their cis-male-privileged Earth time everywhere.

…

I've started re-reruns of voyager - amazed to find that the borg don't play a role at all in the first few seasons. Totally forgot about that.

8472 is my favorite species.

About XEP-0308: Last Message Correction : https://xmpp.org/extensions/xep-0308.html -> It is not specified about log, when we changed the last message, the log has 2 entries (not only 1), it is possible to add a solution?

(it also happens to be a TCP port that's not on the nmap top1000 list)

Neustradamus: what log?

the weak will perish.

but TNG was peak Star Trek anyway. VOY had a horrible ending, and DS9 was merely space soap opera

Ge0rG: Log in the client and saved by the server

Neustradamus: fix the client?

It is not specified in the XEP no? The problem is for server and client no?

Test 2 ✏

Discovery is pretty nice so far

look here: http://logs.xmpp.org/xsf/2019-03-28

Neustradamus: I think it's by design.

It is an example on this XMPP software server, but it is for other XMPP server softwares too.

The prosody log display might need support for LMC

Holger (for ejabberd), Kev (for M-Link), Guus (for Openfire), MattJ (for Prosody), what do you think?

I like Discovery too.

Neustradamus, I think... patches welcome

I'm working on higher priority things right now

The XEP must be patched for it for have a 1.0.1, we are ok?

Neustradamus you want to replace a message when you correct it?

then you lose the information what was corrected

so the client cant show you what the message was before it was corrected

why do you think the server should do this? the client can fuse the messages after receiving it

To have only the last message in log, not the old message and the new message, example the Test 1 -> Test 2 for minutes ago, there are 2 entries in log.

A log on the web is a different thing than a server archive.

(Technically, that is the server archive, with some transform)

Yes. But then you can instrument the Some Transform.

You can. Have fun!

I'm working on higher priority things right now

SCAM can send you that on a coffee mug, I think.

Your ideas are intriguing to me and I wish to subscribe to your newsletter

Pelican Brief flashbacks...

dwd: was the lack of a vote in your ATT mail by design or by accident?

In any case that was good feedback :)

Design. A veto seems like a last resort, I'd like to see what others say first.

But I am leaning toward a veto, as is probably obvious.

why is it voting already

it was my interpretation that after submitting something to the inbox the author can gather inital feedback and maybe improve the XEP

ah but voting does not really change something

the xep stays forever in inbox and can be improved

It's merely a vote on assigning a number.

dwd: I'd also love to see your vote on 412.

And somebody else would love to get all votes on DoX before the weekend.

lovetox, In general, if something's veto'd, people ditch it.

lovetox, Also, I have an enormous pet hate of people working on documents in Inbox, excepting addressing veto feedback. There's a huge IPR hole they then fall into.

lovetox, Unless/until we accept a XEP and give it a number, it's really not clear whose copyright and license it is.

so the right approach would be to submit the xep to the list before submitting it to inbox

Ge0rG, didn’t DoX expire this week?

Ge0rG, yeah, DoX expired and with the last meeting’s votes it was accepted

I’ll publish it, but not on April 1st

I find it too misleading

it is intended to be taken serious, but the nature of it makes it look like it might not be. I don’t want any confusion around that.

why can't it be both? :)

March 31 at 23:59

in my opinion, it has valid use-cases, but is also silly enough to be published on April 1st :)

moparisthebest, simply to avoid confusion

what's wrong with a little confusion

Yay!

jonas’: please do on 1st

moparisthebest, people already complain enough about confusing things with our standards

but what's confusing, it's a simple spec that has implementations, anyone that doesn't want it will ignore it, anyone that does might go "haha this was published on April 1st" but, what's the downside

it’s "this was published on April 1st, is this serious, do people implement it, what?"

that's fine, it's easily resolved, if it was published on April 2nd you still don't know if people implement it

I don't like humorous XEPs, but in his defense this isn't

it's a little humorous, we don't have a Type for that

Type: Slightly Humorous Standards Track

Type: Art

Type: Author thinks it's hilarious but everyone else disagrees Standards Track

Ge0rG, since you in particular seemed to consider using this for real, did you see https://github.com/wiktor-k/prosody-dox

> Type: Author thinks it's hilarious but everyone else disagrees Standards Track Accurate

So 1 council member (and author) are for April 1st release, editor and council member (same person) is against, can we get more council members to weigh in? dwd Link Mauve Kev ?

Anything that suggests people shouldn't implement sounds good to me. ;-)

dwd: so you are for April 1st as well... 😁

Yay that's another council member for!

Haven't seen kev yet

I don't think, strictly, that the date of publication is something I can actually vote for or against, however.

dwd: you can kindly ask the editor to do his duty on a given date.

FWIW, I've never been particularly in favour of the "Humorous" track. But then, I'm in favour of more subtle jokes.

Exactly

Like a real spec with multiple independent implementations that is a bit silly and happens to be released on April 1st ?

That's just good marketing

I think that after we missed to assign the number 404 to a XEP that actually deserves it, we can have DoX on April 1st... @jonas’

Ge0rG, Hidden Jid support isn't bad.

I tend to disagree