XMPP Council - 2020-09-23

it is time

1) Roll Call

Fear Not For I Have Returned

let’s do an allround ping ... Ge0rG, Zash, dwd, daniel.

Here

Perfect timeing, just started preparing dinner.

perfect!

Ho

I was under the impression that we’d have a dwd today, but maybe he’ll appear. Either way, we’re quorum’d, so let’s continue

2) Agenda Bashing

any modifications?

I have appeared.

weeeee

assuming no modifications

Possible AOB: What's up with reactions &c

3) (No) Editor’s Update I’m still catching up on things

Zash, I hope I’ll remember that until the AOB section

4) Items for voting

4a) XEP-0060: Disallow '=' and ';' in NodeIDs to allow use in URIs and refer to PRECIS Stringprep URL: https://github.com/xsf/xeps/pull/983 Abstract: This PR limits node IDs by disallowing the characters '=' and ';'. The reason is that currently it is possible to forge possibly dangerous PubSub node IDs when used in URIs.

The node id is meant to be URL-encoded, surely?

I was surprised by this and I’m going to be on-list with a default to -1 because: This is fixing the problem on the wrong end; the node ID should simply be URL-encoded.

the on-list is s.t. the author still has a chance to defend themselves

On list

I'll go -1. If I'm being an idiot, vanitasvitae knows where to find me. :-)

I stopped reading at that point, I’m also uncertain about the correctness of the statements w.r.t. the stringprepping and stuff

dwd, that’s not a valid reasoning for a -1 ;P

-1. The URI bit seems wrong and the PRECIS part ought to have been a separate PR.

the second part is true for sure, Zash ✏

I can on-list until we get a comment from an URI expert :)

5) Pending Votes

I think everything expired while I was away and AFAICT no new votes have been started?

Sounds plausible.

I didn’t see anything from scanning the minutes or the SoD

so I’m assuming that’s true

6) Date of Next

+1w wfm

+1

+1w wfm

+1w wfm

excellent

7) AOB

Should we be doing a drum-roll?

Reactions came up in the Dino room the other day. From what I can scrape off of logs and lists, we're waiting for someone to figure out how it would work with ... that other XEP for attaching messages to other messages (name escapes me)·

Ah.

I'm wondering what's status of all that? It's been quiet since early this year.

fastening

That's the one.

I think the folks involved got hit not just by the covid fallout

I seem to recall Kev apologising in xsf@ because the year has been quite terrible for him.

(maybe we don’t need the above statement that explicitly in the minutes)

Well, we did, I think. Loosely, Kev proposed Fastening, we expanded that into MAM-FC, but we were expecting the original authors to use that for reactions.

That said, I have been somewhat crazily busy this year, and I know tere's an outstanding comment against MAM-FC with one of the Tigase folks pointing out that you can't use it for both paging and refresh-since.

Understandable.

Does anyone want to put a hat on for this?

Anything we can do other than wait for relevant authors to recover?

technically, there is a lot we can do

the question is if we find someone to do it

But I do actually have to implement this. Since Doctors and Nurses want to react to things. So that means doing Reactions as well, which means someone writing that spec - I'd really rather it weren't me, but I can if needs be.

dwd, maybe you can poke the original author folks for a collaboration.

on the spec that is

that’s probably better, even if they cannot implement it right away, than you going alone

jonas’, Well, the only feedback I had from them was that they didn't like it.

I got the impression that they did not like fastening very much.

me too

I think their argument was strictly that there should be no generic support for anything.

so I suggest that you, dwd, with a concrete implementation case, set up a call with them to discuss how to move forward

call because high-bandwidth will be better for resolving this conflict IMO

dwd, do you think that’d work?

(oh, now I also see typing notifications)

Like the call about message routing and persistence that we had earlier this year?

what's MAM-FC?

Ge0rG, hi, welcome, we missed you too, thanks for this constructive and not at all passive aggressive comment!

In all honesty I don't see any desire from them to work on a general solution in this space, which means there's zero common ground or even goal.

eta, https://xmpp.org/extensions/xep-0427.html

dwd, I’d still suggest such a meeting

impressions can be misleading when carried over email

Maybe it could work by pinging them in the xsf@ MUC?

eta, A way of collating things-that-apply-to-other-messages like reactions, edits, receipts so they can be efficiently handled and archived in a generic way.

I think there were also limits pointed out to what can be reasonably fastened

jonas’, Well, I can do when I have time. I'm likely to implement it before then and feed any findings from that back into the spec. (And also loop around the Tigase(?) folks).

dwd, see, that’s exactly what I’d like to avoid

there is enough impression about the council/xsf/standards process being hostile to spec authors sometimes

and I don’t like de-facto standards because of implementations appearing

Maybe all this is premature genericness and we should just start with something simpler so we can Second System Effect to the max later? :)

Zash, Go ahead and design a concrete proposal.

what about the original Reactions proposal?

it seemed very simple to me

jonas’, I can't implement that on its own because of the interactions it would then have with archiving, which also cause us massive problems already with receipts/markers.

jonas’, Hence MAM-FC, which should address both cases.

jonas’, But since it didn't handle another imaginary case involving clapping for blog posts, one person complained.

What kind of interactions with archiving beyond a special parser for the reference syntax in your MAM implementation?

What if people just have different use-cases and some things are not supposed to interact? (just asking)

If you don't like my design, PLEASE make a counter proposal.

they made one already

an original* proposal

How about we wrap up the meeting and continue in xsf@?

No, we have reactions on their own. That's trivial. We could have a collation for those, specifically, but then you have to have a specific collation for every kind of thing, which involves heavyweight stanza inspection and archiving design within the server, which is painful.

closing the meeting sounds like a reasonable proposal ✏

Seems there are still unresolved issues that needs to be worked out

8) Ite Meeting Est

please move the discussion to xsf@, the authors are also more likely to be active there I think

Thanks jonas’, Tedd, et all

What about AOAOBs?

:O

Ge0rG, Did you want to talk about carbons?

Ge0rG, running out of meeting time :)

I wanted to report from the Board meeting and remind of CS21

Ge0rG, do that here and now then

Last week in the Board meeting it was established that The Designer apparently vanished and that anybody can move forward with any variant of Badges. Tedd hinted on doing some more work on this.

The idea to have a compliance page on the home page was approved and Seve kinda sorta volunteered to take care of it

Also it's time to move forward with the CS21 XEP so that we don't end up with it published some time in 2021

daniel: any news on the A/V ETA?

No

I'm still in the process of moving

But once I'm done I'll take care of that

Would it make sense to give the XEP a number before that?

Yes.

I mean, we know (I think) we want a CS21, so we should create the Experimental and bring it under XSF IPR as soon as we can on that basis.

In that case, jonas’ please put it up for vote

Are we done?

Yes

Thanks for discussing my PR. I aggree that URL encoding the item ID makes much more sense :)

vanitasvitae, glad to hear that! :)