XMPP Council - 2024-12-17

It’s time

1) Roll call

👋

here

Hello!

singpolyma, are you around?

2) Agenda bashing

nothing to bash I assume?!

3) Editors update

* Proposed XMPP Extension: Pubsub Stories * UPDATED: XEP-0500 (MUC Slow Mode) * LAST CALL: XEP-0421 (Anonymous unique occupant identifiers for MUCs)

here​

wrt the last call see my follow up email to that. I’m treating that as an extension of the last call that was already running

(if you are wondering why we didn’t vote on it)

4) Items for voting

a) Proposed XMPP Extension: Pubsub Stories https://xmpp.org/extensions/inbox/stories.html

on list

I have a few problem with this proposal:

- it's not generic, it's only for blogging

- it's handled by the clients, it should be handled by the pubsub service

This XEP effectively registers a PEP node and not much else​

- the delay is vague and should be specified

I think the use case for having this PEP node is reasonable though, there is a benefit to having a well known node for this

The use case is here, the feature is desirable.

goffi: it's not even for blogging really, just for a single piece of media?

singpolyma, where do you see that?

The use case is fine. The business rules could use some work - the publisher's client shouldn't be responsible for retraction, and the configuration of that timeout should be specified somewhere, certainly as far as responsibility.

I mean probably one could imagine implementing the feature by looking in the normal microblog for the most recent single-media item or something. but I don't think having a node specifically for this is all that bad

I got is has temporary messages. I'm not an instagram user, so I don't know exactly how stories work there.

> a) Proposed XMPP Extension: Pubsub Stories > https://xmpp.org/extensions/inbox/stories.html on list ↺

goffi, are those problems big enough to prevent it from being accepted as experimental?

I agree the part about the stuff being maybe temporary could be removed

it's not really needed for the XEP

daniel, I'll go with a +0, I don't want to block, I'll address my concerns on list.

It's a UI consideration

personally i'm concerned about the only one media thing which doesn’t reflect what other 'stories' implementations are doing

but that’s something we can figure out during the experimental phase

is that not what other stories are doing? I thought it was basiaclly always a single video?

The fact that deletion is managed by client is a problem

if the client doesn't connect anymore, the items will never be removed.

singpolyma, afaik 'slide show' is a feature of a single story

> The fact that deletion is managed by client is a problem Right. I think it shouldn't mention deletion at all. That's out of scope ↺

> singpolyma, afaik 'slide show' is a feature of a single story Ah, fair, ok. I probably considered that one video in my head but you're right a list of photos would be sane ↺

Is there not already a XEP for expiring PubSub items? Feels like something that would already exist ..

Maybe but this isn't about expiring items is it?

For messages there is, but AFAIK not for pubsub

(the slight irony is that in the one major 'stories' implementation that I was involved in we just removed stories because nobody uses them)

anyway that all sounds like valueable feedback; however the question is should we accept it as experimental or reject it

+1

Stories must be useful for someone, since so many apps have them ... I just don't know who 😂

+1 from me, but only just. This needs a bunch of work to progress any further.

goffi, do you want to vote now or next meeting?

I've voted +0 already.

17:37

sorry i missed that.

moving on

b) Issue Last Call on 'XEP-0424: Message Retraction' https://xmpp.org/extensions/xep-0424.html

+1

no wories

+1

> b) Issue Last Call on 'XEP-0424: Message Retraction' > https://xmpp.org/extensions/xep-0424.html +1 ↺

I really don't see the point of this XEP

+1

But I guess that's not a reason to block LC and we see what the community thinks?

that‘s what the LC is for

ok​

+1

c) Issue Last Call on 'XEP-0425: Moderated Message Retraction' https://xmpp.org/extensions/xep-0425.html

+1

+1​

+1

+1

larma?

I would prefer to not run them at the same time, so that they're evaluated more independently, but beside that I'm fine with it

> I really don't see the point of this XEP considering how often I see 'edit to blank' some people would probably think it's useful ↺

I consider edit to blank the solution :)​

there's even a button for edit to blank in my app

edit to blank should be a fallback IMHO.

> edit to blank should be a fallback IMHO. That sounds like a good thing to mention during LC 🙂 ↺

indeed

larma, is this a +1?

idk I haven’t considered splitting the LCs up

Consider it a +0, you all seem set to do both at the same time, so I won't block it 🙂 ✏

I think doing them seperately would have benefit so people don't see them as related

what would be the point? reject 424? and decouple 425 from 424?

for example, yes

If 424 wanted changes, that might inform the LC for 425?

but for that to make sense we would really have to do them one after another? not just kick them off a week apart

i'm fine with that if council wants that

but it will take time given how long LCs usually last

I'm OK with both options (two now or with a delay)

Well 425 is using 424. It seems weird if the result could be "425 is fine, let's make it stable. But 424 needs more work"

would require moving the namespace definition into 425 I guess

ok if we all feel like that then we should probably reject the LC for 425

Rejection of LC means "stays experimental"?

yes

we just vote -1 on (c)

Objections to running the LC twice if needs be?

ok I’m gonna change my vote to -1 then

-1 on this basis

and put 425 on the agenda again once 424 has been through LC one way or another

moving on

5) Pending votes

none

6) Date of next

+3w ?

I’m proposing january 7th

> I’m proposing january 7th 👍 ↺

which yes that’s +3w i believe

+3w WFM

+3w wfm

7) AOB

yes

I have a question

the council agenda is the one on standard@ right, there is not any other channel like a draft or pad somewhere?

Because I've missed the Last call topics, and I haven't had time to prepare it well.

For the protoXEP I saw the PR so that's fine.

I think that’s more a fault of me not sending them out in time rather then a wrong medium

I'm not blaming at all :)

the general idea is to send them out 24h+ in advance

OK, so it's standard@ only, right?

I'm checking PR so I should see protoXEPs, but that don't work for other topics.

so usually my excuse for not sending them out in time is that you have 2w to vote any way and I'm perfectly fine with people voting in later meetings. in the past when I knew there were big XEPs to read i also gave people 3weeks

OK, that's right that I can vote on following meeting.

but yes standards (previously we had the council list) is the correct medium from my POV

we can obviously debate that

that make sense yes, so everybody can see it.

but writing it into a pad first doesn’t change the fact that I only get around to it last minute

As we have 2 weeks, it's fine actually. I just wanted to be sure that I wasn't missing any medium.

And thanks for your work.

no you aren’t missing anything. process is I (chair) collect things either from the github PRs (if editor were a different person it would be from editor pinging me) or from people pinging me in here like jcbrand did last week. and then I write the agenda (hopefull 24h prior to the meeting)

which btw jcbrand pinging me in here was public and you could technically have seen that

Indeed, I've seen that.

ok. any other AOB?

wait no, I've missed jcbrand, I saw jonas' message.

no ,no other AOB. ✏

no, no other AOB. ✏

8) close.

Thank you all. See you next year. Happy holidays

Thanks Daniel, thanks all, happy Xmas and New Year.

Thanks everyone! Merry Christmas!