XSF Discussion - 2020-09-17

pep., if you replace it, then the old/previous feature is also gone, right?

yes

so i'd just remove all traces of "max" and add a new feature for your proposed "-1"

related: I do wonder if there should be room for a union type form field type, e.g. this field's value is either a int or one of "foo", "bar" or "baz". ✏

as I also don't like overloading integer values with extra semantics (think "error codes"), but I can see that the way of least resistance may be the way forward in this case

> as I also don't like overloading integer values with extra semantics (think "error codes"), but I can see that the way of least resistance may be the way forward in this case I'm really not a fan of this either. That's why my original proposal didn't. But it seems like the community has spoken

yeah I'm also not a fan, but..

To be clear 'max' is not a blocker for me

> But it seems like the community has spoken I am not sure if I'd put it that way. Clearly there are two different camps in how this should be done. What we should do now is to see if we can find a compromise

MattJ, ahh ok, I assumed that pep made the propsoal because this was blocking adoption by prosody

We have had this discussion already in the past year, and I think the conclusion was that we need some new type like 'integer-with-max'

more like "integer-with-list-of-predefined-strings", but yes ✏

Predefined where?

The point is that we need to validate it, so the list of possible strings needs to be known

hence predefined

So what strings are you thinking?

depends on the use case

the xep where the form field is specified in also declares those

No thanks

How about 'min' and 'max' as aliases for the xep122(?) min and max limits?

I mean, again not a blocker, but annoying

Yes, min and max makes sense

What I would rather not have is an open-ended data type where the possible legal values are dependent on context

Zash: I think max is distinct from the integer limit though, no?

In that it's asking the server to be essentially unlimited, as much as is allowed.

(I don't particularly have a horse in this race, I think pretty much anything is workable here)

The max integer limit is "as much as is allowed"

But what I'm guessing you're saying is that it may change

MattJ: It wouldn't really depend on _context_, in that this field variable would always have this data type, no? (We do have XEPs where valid types do depend on context, I do hate _that_ ...)

Holger: what I took the proposal to be is a data type that is essentially an integer or string

Where the strings are chosen by the XEP it is used in

Which is almost useless for validation

> MattJ, ahh ok, I assumed that pep made the propsoal because this was blocking adoption by prosody I kinda did?

if it's not blocking then.. great? :)

MattJ: We have various form fields and whatnot where an XEP defines a limited set of valid strings already, no? (I.e. enumerations ...)

Whatever, in this specific case it's really about integer|'unlimited', not integer|string, right ...

And those would use list options

I'll restate the problem: we offload dataform parsing and validation to a library, it currently takes care of ensuring max_items is an integer, and so on. The proposed "max" change means we have to stop declaring this field as an integer and move all validation back into code that uses the library

MattJ: Or fix the library ;-)

Obviously that can be done, but using this "max" hack has come up in other contexts since

Holger: fix it to do what?

(I have a similar problem but I do see how union types are useful to support.)

"max" is not valid for xs:integer

To support validation of complex types.

if somebody had told Council back then, we'd probably have approved -1 instead of "max" or "∞"

I just wouldn't have seen declaring the type to be "integer|'unlimited'" (or in other cases "integer|enum('one', 'two', 'three')") as a hack. Quite the opposite, I'd see limiting us to simple types as a hack to work around implementation problems.

Not everything goes into integers indeed. and having "max" is certainly more explicit than "-1" for clients or server devs

Holger: it's based on XEP-0122 so that validation constraints can be communicated to clients

Ah!

So all I'm asking is that we use a proper defined type instead

So it's a spec limiting an implementation limiting another spec!

pep.: Exactly.

we surely could extend xep122 to support those kinds of union form field types ✏

I'd be totally happy to get behind that - and I see it being useful in other contexts too

That does mean a lot more work..

I'm also happy with xmpp:integer-with-max :)

Whatever makes most sense to people

UsefulPubSubThings when? (hint: never!!)

A well thought design is appealing, but the path leading to that is full of ambushes :p

Long and perilous

So we should just pile on hacks?

pep.: yes, I know spec work is draining in this way :(

Zash: isn't that what happens in practice most of the time

Giving up and adding more hacks isn't going to help with that

I agree, but that needs work and dedication. I'm curious how projects like Movim and Sàt ever managed to make something useful out of pubsub without this tbh, or what I point out in https://mail.jabber.org/pipermail/standards/2019-October/036503.html

Me too

I may not be entirely available for the board meeting. I'll be in transports in between things (missing a word.)

I have two AOBs for Board.

Or rather, Council has.

pep., MattJ: I think movim just gets you to force max-items to something high

in server config, that is

We're also lacking a config option to ask the server to return an error when reaching the limit, rather than discarding older items

eta, yeah and that fails whenever an operator is not aware one of their users is using movim

And what MattJ says

(which I mentioned in my email last year)

ah.

Even though for the issue I mentioned just now, that's possibly another issue that goes alongside using servers that correspond to your use-case

(how to find them is something I want to tackle but -ENOTIME)

Busy adding custom types in XEPs

MattJ, something something registry not working.

Yeah, that minor issue :)

So I "can't" submit my change just now.

https://xmpp.org/extensions/xep-0137.html#example-1 oops, unqualified NS "si-profile"?

How do I define a datatype in a registrar definition? :/

I mean not just saying it exists

Taking example on https://xmpp.org/extensions/xep-0137.xml#registrar.xdata-validate, that includes a definition from the XEP itself, is that enough?

In https://xmpp.org/extensions/xep-0137.xml#usecase.xdata

Yeah, I guess the new type needs a XEP?

I'm not entirely sure this is the correct thing to do though, MattJ. You can apply a range to xs:integer for sure but how to you apply a range to <xs:simpleType><xs:union><xs:simpleType><xs:restriction base='nonNegativeInteger'/></xs:simpleType><xs:simpleType><xs:restriction base='string'><enumeration value='max'/></xs:restriction></xs:simpleType></xs:union></xs:simpletype>

What I had in mind at the beginning was to allow servers to send over their own type definition :x

But that's madness

kinda like EXI?

Agreed, madness :)

But then how do I solve the <range/> thing.

It's also not like it could be applied to a variant of our custom union type because there's no variant

And I can't define another derived integer type with custom range because every deployment is different :)

In this new XEP/modification to existing XEP I might be able to say "any <range/> thing applies to this integer value" but that's meh

It's meh but I'm not sure I see another solution

Fortunately 122 says there can only be one <range/> within <validate/> (in the non-normative schema)

another solution would be to go to the w3c with a revolutionary union type with variants! (not me plz)

0. Welcome + Agenda

half-here

Hi

👋

MattJ Guus

hi

sorry

Oh, forgot it was Thursday

o/

welcome all

I've added an item from last meeting from Ge0rG

And although my name wasn't mentioned thrice, it appeared that dwd had a suggestion for a topic from the Council meeting, too

Hope either of them is around.

I'd really like to receive agendas prior to the meeting, so that we can prepare. We've agreed on that, didn't we?

ralphm: the Council asked to create a web page linking to the latest / emphasizing the latest and linking to all Compliance Suite(s)

We did indeed. My apologies

ralphm: and the second question from dwd was "what about the badges"

(I'm paraphrasing here)

ok

For board to consider: the discussion on the compliance suites.

1. Minute taker

I'll write up minutes later.

2. IETF's use of Jabber

This was an AOB item by Ge0rG last meeting.

Ge0rG, what is this about?

there was a thread on the IETF (users?) ML about how they are trying Slack as an IM alternative

and in that thread, there were some opinions about XMPP that are based on ~15 years old facts

so I wrote a nice mail to their xmpp admin, offering help with improving their xmpp infrastructure as well as their recommended clients

Ah, I haven't seen that.

the xmpp admin forwarded it to the IETF Executive Director

Thanks for picking that up. Any response, yet?

yes, we've had some communication, and the next step would be to set up a converse.js instance, help them a bit with ejabberd config and provide better client recommendations

The ones on https://www.ietf.org/jabber/ are also ~15 years old

Do we have something solid we can recommend for the major platforms?

They also asked if we can offer commercial-grade service / hosting for them, but I declined

we can hardly offer commercial-grade hosting for our own needs.

You can, 'we' can't.

but I think we have people who do offer commercial-grade hosting?

The XSF obviously doesn't offer hosting, but I'm sure there are people who would be happy to provide such an offering

ralphm: the original mail was signed by me and two other XSF members

I.e. we, the XSF, vs you, people in the community.

flow: those people need to stand up and volunteer then.

wait volunteer?

I assumed we where talking about commercial paid services

flow: no

ahh so commercial-grade without the commercial

None of the people who contributed to the initial mail volunteered any infrastructure yet.

flow: commercial-grade as opposed to commercial

I'm assuming they don't just want a random XMPP community member running this

Ge0rG I suppose we can call for volunteers on a mailinglist?

but maybe that was just a misunderstanding between me and the IETF folks

MattJ, right, that makes sense

There are a number of commercial entities around XMPP who I'm sure would be happy to sponsor a commercial-grade deployment for the IETF

Do IETF also provide XMPP accounts, or just the groupchat service?

wasn't the initial jabber setup of the ietf done by some random xmpp community member?

exactly my thought Matt

I seem to remember we did the latter long, long, long time ago.

this all is exciting, and I applaud the people involved to have picked this up - but how is this a board issue?

ralphm: they are only hosting the MUC server and intend to keep doing so.

ralphm: aka. they don't want to host user accounts themselves

but they'd probably be grateful to have a recommended server with IBR and good stability

or a small list of recommended servers

Guus: the question might be, besides running muc.xmpp.org, do you also want to run muc.ietf.org, as an XSF effort. This would surely need to pass board.

Ahh, that MUC-only requirement may lower the bar to provide the service for free

I'd offer mine, but it lacks both in stability and in bus factor

ralphm: I don't think they want to change hosting for their MUC component.

ok

I'm pretty sure we can put up a Holger to review their configuration and to add / fine-tune the modules needed for MAM and all the other fancy stuff, though

Sure

Then we also need to make a list of recommended clients

And then we need to set up a converse.js instance with a nice fancy web front listing all their MUCs

Ge0rG: 'we'? we can hardly get a client list up on our website :)

I'm reluctant to provide a recommendation on behalf of the XSF.

Any other volunteers?

But I know there are people in this discussion with opinions, that'd be perfectly fine to be voiced.

Outside of their capacity within the XSF.

the last mail from the IETF came on Sept 8th, and I failed to respond so far.

ralphm: I don't want to make it political, I want to help in pragmatic and useful ways

Indeed.

I do not see an issue with individuals making recommendations, even if those individuals have XSF associations.

I very much like us to help the IETF, don't get me wrong.

ralphm: 'us'?

Just that given the recent discussion, it cannot be an XSF recommendation.

I'm perfectly fine with signing that recommendation with my name only.

But I still need help preparing it, see above.

I'm happy to recommend some clients

See :-D

Also I'm going on vacation in some days and my capacity to prepare something will go from ~0 to ~-10

MattJ: yes, ripping your client recommendation list came to my mind

10 minutes left. Does this need furhter board action?

The new one in Prosody? That's less of a recommendation list and more a list of clients that came to mind, but yeah

MattJ: maybe in terms of a diff to https://www.ietf.org/how/meetings/jabber/ ;)

Guus: no, that was FYI

Guus: I think can move the remainder of this discussion outside of the meeting.

Thanks for noting this Ge0rG!

unless the Board wants to get all political and provide actual help, of course

3. Compliancy Suites

Council is preparing a new Compliance Suite for 2021, and thus Dave was so kind to make a public inquiry on standards@ about their usefulness.

The feedback was mainly: - we need badges to make CS more useful - the XEP process is horrible, we need just a webpage

But a new webpage would require New Council Process as well as New Webteam Process, I've decided to stick to the old process so far.

I with my CS author hat, that is.

Why do we need processes to get a page added / modified on the website?

Nevertheless, it would be Awesome:tm: to have Somebody Else:tm: create a page on our website that would be linked prominently and link to the current CS

I've failed to get in contact with the person who initially offered to do the design of the badges. At this point, I'd have whoever volunteers just create *something*.

Guus: up to now the Council has defined what belongs into CS. Of course we can delegate that to the Webteam

As for the website, please collaborate with the comms team.

https://op-co.de/tmp/xmpp-compliance-badges-2020/ :D

Isn't the website merely a reflection of what's in the most up-to-date CS?

Ge0rG: hooray!

Guus: it would suffice to have a page on the website that explains CS (copy&paste from the CS intro!) and links to the document du jour

If we can avoid changing or adding any processes, and just have a page that reflects that... that'd be ... good?

Guus: a paragraph, a bold link to current year, a list with links to previous editions

> The feedback was mainly: > - we need badges to make CS more useful > - the XEP process is horrible, we need just a webpage Is that really the only feedback? You (council) discarded the part where some said they're not so useful as is?

Guus: and a place in the website where it should be

I'd indeed just create a PR and have someone in comms +1 it

all fine by me - but more of a commsteam issue than board?

Guus: somebody needs to do it

sure, but that's not neccesarily a board member? :_)

Guus: I hoped Board can direct some resources at it.

I don't think so, as board depends on volunteers.

unless you propose hiring someone or somesuch

I'm very busy at the moment but I will try to tackle that Ge0rG

> I've failed to get in contact with the person who initially offered to do the design does that mean you tried and they didn't respond or that you had no chance to try?

Seve: cool, thanks!

I'm also in comms so.. ;)))

Ge0rG, I tried and they didn't respond

(several times)

ralphm: cool, thanks for that!

there was significant bike-shedding of the design a year ago or two, and an alternative design by theTedd.

Thanks, Seve

So I have mixed feelings about just pushing through with mine, as it's clearly not perfect

Ge0rG, let's just have something, and then go from there.

+1

But OTOH, I could just PR it on shields.io and be done

If somebody then steps up with: "hey, I fixed your fugly graphix, here's the PR", then yay

I'm applauding all of your efforts, Ge0rG - unsure if your due dilligence by running it past board adds unneeded delays though.

ok

4. AOB

I would like for next meeting to discuss this https://trello.com/c/GHGXcYuq/405-how-should-we-approach-txxmpps-pr

I had a quick look and I don't see the issue. happy to take that to next meeting

It has been there for a while already and would like to close the issue

(No more AOB here)

Ok

5. Date of Next

+1W

6. Close

Thanks all

Thanks!

Thank you everyone 🙂

thanks

is it me or is git.gnupg.org down?

MattJ: so, do you volunteer to make a useful modern client list?

On the page you linked: s/Pidgin/Gajim/;s/Adium/Beagle IM/

I'll let you make the call for Android :)

yeah, it's obviously s/Yaxim/yaxim/

Pidgin and Adium are borderline unmaintained right now (I know they have hope to revive Pidgin's XMPP support Soon™, but I'm not holding my breath, and Adium basically has no developers at all)

MattJ: I am aware of that, but is Beagle a good modern desktop client?

What about Swift.IM and Dino?

Monal desktop probably isn't there yet

Dino isn't officially packaged for Windows, and... I think it doesn't support MAM in MUCs yet (?)

MattJ: Accurate afaik

MattJ: did you test BeagleIM on mac?

and I haven't been following Swift recently, but pretty sure it's even further behind on that kind of thing

No, I haven't

That would require dusting off my Mac, which I do need to do at some point

so there is no reliable recommendation for macOS?

Beagle is using the same underlying code as Siskin, I don't have a problem with recommending it

the question is what moden client is?

Not Adium

Beagle has the same set of features as Siskin and is based on the same library

Andrzej: https://xmpp.org/extensions/xep-0423.html would be a good start :D

If it supports MUC, HTTP upload, and MAM, we're pretty good I think

MAM and Carbons

it has MUC, MAM:2, HTTP File Upload, VoIP (jingle/JMI), Carbons, MIX, Message retraction, last message correction, etc

And MAM in MUC?

it is available since latest release

Andrzej: that's great!

VCardTemp, VCard4, PEP based avatars, stream management, XEP-0184, chat states (partially), user blocking,

I would say it almost matches CS2020 as it is missing Jingle File Transfer and `/me` command

WHAT? NO /me?!?!

THE MOST IMPORTANT XEP OF ALL!!!11!!!1

Hah

Someone actually told me once that XMPP wasn't acceptable because of a client that didn't do /me

I do not fell that I'm missing something due to lack of `/me` but if someone would report that as a feature maybe it could be added ✏

Technically, it's `/me `

Weird semantics-shoehorned-into-<body> thing, but it's one of those small details.

Zash: may I remind you a sentence of yours this day :p

?

“Giving up and adding more hacks isn't going to help with that”

Well-established hack dating back to IRC behavior.

If you come up with a way to do this in a more XMPP-ish way, I'm all ears. Or eyes.

Zash: technically, the wire-format is not from IRC. The XMPP variation added a hack on top of XMPP

message { is-action body "is doing stuff" }

Ge0rG: Why I said "behavior", not protocol. :)

> mdosch likes /me But not when someone is quoting it as you don't know anymore who is /me

Woo, conversations changed that.

I wonder if I should steal that

this seems like a bug

Do it!

unless you do it properly of course

a featurebug!

Speaking of which, where'd references & co go?

Andrzej, https://github.com/tigase/beagle-im/issues/50 - you're welcome :)

well the good thing about stuffing everything in body is that clients don't need support!

is Siskin in a usable state for end users?

I had to give away my iPhone recently

I would say "yes", but it depends on what you expect from the app, used server, etc.

I would say "no", but that also applies to most software I use and write every day... :)

Andrzej: a client where a technically competent person can set up an account and join a MUC without jumping through burning hoops or running into dead ends (failure without error messages etc)

I haven't tried the latest release yet, but I think all the issues I could find are reported as fixed

cool

MattJ, yes they are fixed

and some parts of the UI are simpler now

is it reasonable to list Dino as a Linux client?

Nice

Ge0rG, I worry about it not supporting MUC MAM

MattJ: yaxim doesn't either. MUC history seemed good enough for me

In a MUC-focused deployment, that will be a weird cause of confusion if Dino users only see some of the history

Also the interaction between MAM and joining a room is bad.

whoever invented that...

theTedd: that's exciting!

also, Ge0rG, I had some suggestions for CS (actually from last time, but I didn't want to interrupt the process) - let me know whenever you're mentally prepared 😉

theTedd: I totally loved your badge generator workflow, maybe you can make it work out of DOAP?

theTedd: just pile them on https://github.com/xsf/xeps/pull/980

I have considered that, in addition to just dumping a text list of xeps

theTedd: I'm currently mentally not able to do useful discussion, but feel free nevertheless

that's what I presumed; it's more ideas/discussion than PR suitable

and re badges, I thought about putting the level and year on the RHS of the badge, something like [Mobile Client: 2020 Core] with colorcoding of advanced>core and 2020>2019>...

</bikeshed>

I will be doing colours by year (shades of green through orange and red)

related question: is there anything for a client to actually implement for XEP-0411 (Bookmarks Conversion) ?

If it has code to do bookmarks conversion itself, disable that if it sees the feature.

I was wondering whether it makes sense to have it as a requirement in the CS for clients (it currently is for IM Advanced)

theTedd: yes, because both legacy bookmark formats are mandatory for Advanced IM Client

so if you have a server that does 0411, you'll end up with duplicate bookmarks

right, okay

in other news:this muc kicks me if I join from jabber.org (which may be justified)

You can't join or you get kicked?

it joins, sync, and is then immediately kicked with "Kicked: jid malformed" (errors 333 and 110)

I'm assuming it's actually a S2S issue

your client sending an error to the muc?

But yeah, jabber.org is difficult. My s2s to it is broken for a long time. First we didn't share a cipher, now I can't validate the cert and it relies on dialback which is diabled here.

A 199 ping from jabber.org to muc.xmpp.org seems to get there and back just fine

theTedd: sounds like one of the nicknames here causes jabber.org to freak out

I blame Rixon 👁🗨

You receive initial presence, your server dislikes it and bounces the stanza, you get kicked

This can be from the Prosody MUC code if your nickname does not satisfy resourceprep in "strict mode"

... or maybe not

joining jdev and council worked, so yeah it's probably a nick

Mmm, yeah, looks like Rixon 👁🗨

Oh wait, the "strict mode" thing isn't in a release, so never mind.

MattJ: lack of MUC MAM is definitely an issue

Ge0rG: you just don't notice it on yaxim because your phone is nearly always on

eta: that's true. Also I've configured my rooms to keep 500 messages and to return 50 by default

and yaxim will poll for history since the last message's timestamp. That's absolutely not prone to race conditions!