XSF Discussion - 2019-03-29

Me too, actually

jonas’: so you are in on the 04/01 cabal? 😁

not necessarily

Seve You can count me as another person who doesn't find humorous XEPs particularly funny.

Good to know I'm not alone, jcbrand :)

moparisthebest, another, less important, aspect is that April 1st is a monday, and I don’t have lots of resources for doing editor work on mondays

How much more than pressing a button is it? Would it be hard to stimulate a Monday from a different time zone? That should give you half a day of wiggle room in each direction.

Ge0rG, assigning a number, checking that it builds, checking that the metadata is ok for publication, tagging, archiving, pushing, waiting two hours to send the email (and not forgetting about that)

much of this is automated, but to apply the appropriate amount of care, I need to allocate a bit of time for that

DoX: If it's meant to be implemented: Standards Track and not April 1st. If it's not meant to be implemented, Humorous and April 1st. Although whether it's actually amusing or not is an open question.

If it's standards track who cares if April 1st?

I agree with Kev - Anything published on April 1st runs the risk of being treated as humorous. Many people won't notice the track that's published on.

Guus: I don't see this being a problem with that specific proposal.

If a XEP is not intended to be dismissed off-hand as humorous, we shouldn't publish it on April first.

I don't see a problem with publishing serious proposals on April 1st, and I don't think people will dismiss something they actually need based on the publication date.

It will introduce confusion with at least some people, which we can easily avoid.

And especially with DoX, which is of the "ha-ha, only serious" kind <http://www.catb.org/~esr/jargon/html/H/ha-ha-only-serious.html>

that's utterly confusing to anyone that's not on top of things.

I’d maybe not say "utterly", but yeah. Especially with this type of borderline proposal, I think we should commit to it being either the one (humorous) or the other (standards track).

There's nothing wrong with publishing a serious proposal on April 1st, but that's not a reason to actively push for it to be published on April 1st.

>If it's standards track who cares if April 1st? I agree, not all the world celebrates 1st of April, just saying.

I don't check when a XEP was published, honestly.

I care about the content.

Seve, me neither, but some may, and especially on the day of publication.

I'm not pushing to any of the sides, just mentioning that

Many people won't be affected, but some will. We should err on the side of caution. Especially since it'd be effortless to do so.

you folks are way too serious.

Ge0rG I like meta-jokes as much as the next guy, probably more. But let's not do that in a standards organisation.

If it was an obviously serious proposal, April 1st would make no difference.

But this is a XEP that at first glance I assumed was meant to be a joke.

Guus: ..in a standards organization that has an explicit document class for "funny" things?

Ge0rG we can go back and forth over this all day, but I don't think we're going to agree. 🙂

this is kind of those cheap 80ies tv shows where there are two huge neon signs above the stage with "Applause!" and "Laughter!"

Kev: the XSF process doesn't allow for a proposal to be _both_ standards track and humorous.

What about if we change our process to allow for that? It would probably take a year or so, and then we can publish this XEP on April 1st 2020.

Come on :)

Kev: speaking of process, is there a chance to get a quick vote from you on XEP-0412?

Ge0rG Comedytrain has open podium on Tuesdays, in Toomler, Amsterday. 😉

Ge0rG: Probably not while I'm off ill.

If I've not done it Monday, do feel free to chase.

Kev: alright, thanks. Get well soon :)

Thanks.

(this is not meant egoistically at all)

It didn't, until you mentioned that. 🙂

As someone with no skin in the game: get well soon, Kev.

Ta. It's only a cold, but it turns out they can be plenty annoying enough.

It was well-intentioned, but then I had a feeling that it sounds like an empty phrase, and then I realized that it's even worse if taken in the context of my inquiry.

I suppose that whatever I'm saying now is only going to make it worse.

yup.

Ge0rG, Keep digging, it's fun watching.

So let's get back to DoX.

dwd: you owe me a vote as well :P

Ge0rG, I'm still debating whether to through this back to another Last Call. We've had so few comments, I'm not sure it'll fix anything, though.

Ge0rG, That is more or less my concern with ATT. It's a (relatively) novel cryptographic design that the XSF is probably not the best place for.

dwd: there is always CS-2020 for comments.

Ge0rG, That's a fair point.

dwd, I'm missing context, but it feels wrong to have both a defined (although minimum) period for 'last call', but also throw things back to last call for not having enough feedback.

indeed, what Guus said. 0412 has been in Last Call for over a month.

Guus, Yes, although Council has done exactly that. But in this instance, we have had a change in author, and that author has added their own changes.

dwd: as I said before, I'd rather undo my changes than go through another month of Last Call Feedback Not Happening.

dwd: so either Council is agreeing with my (rather minor) changes, or not. In the latter case, I'll just revert the commits and get that thing out ASAP, and push them into CS-2020

Ge0rG, Sure. And equally, I'm not sure I want to veto the spec from Draft anyway. I just need to think about it a bit before making a decision.

dwd: and after all, Draft isn't Final. So it boils down to us (the Council) not closing any roads for us.

If the change is considerable, that might warrant a Last Call. If this is about the Compliance Suites, I 'd much prefer to finally either reject or publish things. Sam has a point - it's almost April - this is getting silly.

especially if we have another xep coming up next year.

April 1st would be a good day to publish the Compliance Suite.

Thank you for not leaving that one unused, Ge0rG 😃

Guus, The reason why it's taking so long is not, in fairness, COuncil taking time over things, but the utter lack of discussion in the community.

I might fat-finger it a bit and change the year to 1999, to commemorate the anniversary.

dwd I thkn that Council should decide to either use 'lack of discussion' as grounds to not advance the XEP, or to take it as a silent agreement.

Re-iterating what we've done a couple of times, expecting a different outcome, is not productive.

Guus: if we take lack of discussion as grounds not to advance, then the XSF will stall altogether.

Guus, Or - and where I'm leaning, actually - just push this one through and accept it stinks a bit, and hope to get a decent discussion for CS-2020.

dwd: may I remind you that we had the same argument about CS-2018?

Ge0rG, Yes. The community's input thus far for two years is that they just want a Compliance Suite, but don't care what's in it.

Regarding ATT, I think the upcoming sprint in Berlin will yield a lot of offline discussion about it. So on Sunday/Monday a lot of OMEMO people will have talked about it. The author and various client-devs are involved.

I suspect that part of the reason for a lack of discussion is that there's a feeling that it's not going anywhere, anyways. Let's break that cycle, but getting something out the door.

Syndace: how many security people will be there?

I suspect that part of the reason for a lack of discussion is that there's a feeling that it's not going anywhere, anyways. Let's break that cycle, by getting something out the door.

dwd: maybe the community just trusts into the elected Council to do the right thing?

Ge0rG, The elected Council's Thing is not writing XEPs, though.

> The community's input thus far for two years is that they just want a Compliance Suite, but don't care what's in it. I'm not sure that's true.

There are a small number of loud voices saying that.

Ge0rG: Not sure if any ^^

I'm not sure that's the same as being the Will of the People.

Kev, Oh, indeed - the majority of the community has been entirely silent on the issue.

dwd: in case of Compliance Suites, it might actually be a good idea to have those maintained by a Council member.

(Possibly because it's the opposite of what I think, which is that the date is unimportant (and shouldn't be there at all) and that if we can't do a decent job of a CS, we should delay until we can)

Kev: if the people remain silent, we have no way to determine their will

Kev: we are delaying the decesnt job of a CS at least since 2016 now.

Kev: do you propose to replace the CS XEPS with one, that we periodically update?

I think that with the presence of XMPP clients that stopped implementing new XEPs a decade ago, it is useful to be able to assign a year to a given implementation.

I might be late to a party, but it's absolutely necessary for serious things to be published on April 1st. If anything it makes plausible jokes better.

And we have discussed before that CS does not quite fit into our XEP process, but that for lack of a better process we are sticking to doing it as we are now.

If you want to change the process, please do so for CS-2020

(see, sometimes, you can't tell truth from sarcasm)

Nothing is going to change by pushing this one back to LC, I think. So I'd suggest to either reject or accept the advancement.

I think Council's mandate covers that neatly - the amount of community feedback can be used as an argument to reject, but I don't think Council _requires_ community feedback to vote on a XEP.

Guus, It doesn't mandate this, but neither do the rules preclude this as a reason to veto.

you got me confused.

Guus: I think Dave wants to say that the council may refuse a proposed XEP based on lack of community feedback

Guus, Oh. Yes, unsurprising, I've rephrased what you were saying, more or less.

Yeah, that's what I ment. 🙂

So everybody is in agreement now? Great!

Don't know about you, but I'm frantically refreshing my mailbox.

I'm also frantically refreshing my mailbox, but on my current 64kbit/s connection a login+fetch cycle is counted in minutes.

> Reading new messages (402342 bytes)...

why do you have to re-login to refresh?

that takes away from the franticallity 😞

jonas’: for $reasons. One of them being that IMAP support in mutt plainly sucks

ah, mutt

another one being that I fetch my mail from the ISP via POP3, just to sync my inbox via IMAP to my own server

did I mention yet that mswatch is an ugly hack?

And you've not yet deviced a method to be notified of new mail via XMPP? tsss.

Guus: being notified? Just deliver them over XMPP!

Ge0rG yes, get on with it!

Then we can have COIOX!

jonas’: do you have any plans for this weekend?

Ge0rG, yes.

why?

IT'S A TRAP!

jonas’: you are my no. 1 go-to bot expert. And this looks like we need a bot to synchronize maildir over XMPP

told ya

I'm glad you are not my boss, Ge0rG

😂

Seve: my current developer team has a size of 0.

http://www.quickmeme.com/img/67/67851be4d08f9a4ffb3f0a48ef6e136eacae8e0fc0d0f7dfb9a53c36f388b097.jpg

jonas’, don't forget the owners of quickmeme.com for allowing an upload to bypass the infallible filters

ah, yes

FWIW, I decided that April 1st is not the right date to publish DoX, and since I was nagged about eax-cir in the other room, I’ll just go ahead and process both now

on a different matter, folks interested in future xep archeology might like that I’m starting to tag XEP commits ✏

https://github.com/xsf/xeps/releases

\o/

jonas’: That is awesome!

one question for https://xmpp.org/extensions/xep-0367.html if you are doing the "slack-like reaction" implementation, how can you count emojis for MUC, regarding that uniqueness cannot really be based on the from jid

edhelas: based on the full JID in a MUC?

edhelas: or are you speaking of nickname changes?

jonas’, was that message about JET (0396) prompted by a discussion somewhere?

Because some of us at the berlin sprint were actually talking about that earlier.

I guess people will grump about offline / MUC. Even if there is no actual limitation for jingle regarding this

https://xmpp.org/extensions/xep-0385.html

I think, vaguely, that Jingle FT has a better security model than HTTP upload, though it somewhat depends on the details of the threat model you're working to. I'd love to get some of the crypto-enthusiasts to document their threat model, mind.

Ok I just sent a follow-up on the ATT thread, I'd love to get feedback on that

https://mail.jabber.org/pipermail/standards/2019-March/035993.html