XSF Discussion - 2019-10-01

pep., you can set arbitrary headers from javascript

(mostly arbitrary)

so a web client could make good use of that

Could somebody pleaser rerun travis for PR #574? (https://github.com/xsf/xmpp.org/pull/574)

COM8, rebase your branch on current master to fix that issue

(that’ll also re-trigger the CI automatically)

OK

Ok, now I need somebody that reviews the changes again 😀

For some reason I can't merge anymore? hmm.

Or maybe I've never been able to merge on xmpp.org

🎶 I can't code 🎶 I can't merge 🎶

:)

what? no XEP-0118?

Guus: you can't have them directly in messages.

That's fine, juste have the MUC subscribe

And display them for who's interested

Technically, the MUC could act as a PubSub subscription proxy.

like it does for avatars

it doesn't? :(

Because we're still using that presence hack

Maybe if previous council hadn't rejected Link Mauve's PR..

current council is almost a previous council now, so it's time to bribe the next council

yeah

unrelated: I’m hungry

jonas’: there is no XEP for that ;)

we *do* have User Mood

also, I still need to write my council application

unrelated: I’m hungry and suprisingly far away from food that’s not oreos

oreos is at least something

We're two on that pack of oreos, it won't last long

then daniel was incorrect about his statement.

or maybe has a rather narrow definition of food :-X

I hope things don't get to that

never mess with hungry nerds.

Other non food related question: Any reason why the URL in the subject for the logs still is http? https works fine for me

It used to not have the right cert on the logs host.

but now this has been taken care of and we can change it?

cc @ MattJ ^

In the MLS WG Interim today.

dwd, will you be able to send a council agenda?

.

jonas’, lots of clients will do a get after a receiving 302 to a post

so muclumbus search is currently broken on all Conversations

because the http library i'm using does follow the same 'broken' behaviour on purpose

Daniel, derp, yeah

going to fix that ad-hoc

I didn’t recall that you need a POST for search

Daniel, should be fixed

Anyone got any MUC log data? Joins, message, leave? MLS Working Group is asking.

xmpp.org and jabber.org both should have some.

Kev, Public and machine readable?

jonas’, what change did you make? because it doesn’t appear to be working

I have join parts I think

Jabber.org should have machine readable stuff, but not public, would have to ask Peter for it.

dwd: I have some years worth of poezio logs, but those lack join / part history ✏

jonas’, in fact i can’t see any changes. still redirecting

Oh, wait, can I get the join/leave/presence updates off MAM these days?

dwd: most probably not

It's the joins and leaves of individual clients we could use, here.

MR 20191001T10:38:17Z 000 <Kev>  xmpp.org and jabber.org both should have some. MR 20191001T10:38:34Z 000 <dwd>  Kev, Public and machine readable? MI 20191001T10:38:44Z 000 ---> kokonoe joined the room MR 20191001T10:39:32Z 000 <Daniel>  jonas’, what change did you make? because it doesn’t appear to be working MR 20191001T10:39:39Z 000 <Ge0rG>  I have some years worth of poezio logs, but those lack join / part history MR 20191001T10:39:50Z 000 <pep.>  I have join parts I think MR 20191001T10:39:52Z 000 <Kev>  Jabber.org should have machine readable stuff, but not public, would have to ask Peter for it. MR 20191001T10:40:06Z 000 <Daniel>  jonas’, in fact i can’t see any changes. still redirecting

I have join/parts

pep., Ah, interesting.

44M for my xsf@ logs

I can upload that somewhere

In that format?

yep

It's machine readable. There's no distinction between presence and messages semantically, but "--->" and "<---" with no nicks should be good enough markers I think

Unless a MUC admin wants to troll you

Daniel, but it’s a 301 now

Unless somebody joins as `---`

Probably better than nothing, but in a perfect world I'd have device data.

Ge0rG, no, you'd see <--->

Ah, it's a difference between the stored and the displayed format

yep

jonas’, that has the same broken properties

can we not redirect at all?

Daniel, okay, working on that

will have to figure out the correct rewritecond for that

give me a minute

HTTP is the broken property here...

indeed

Obviously

Daniel, should be fixed

oh, actually presence and messages are marked differently

MI / MR at the beginning of the line

I mean it's not really broken. They just clarified a must not with a should

"clarified"

Small typo fix basically

dwd, ^

Daniel, for 301, I think it’s always been a "keep POSTing", not a "convert to GET"

pep.: wasn't there an &nbsp; in the mix, used as a separator?

Daniel, in any case, I removed the redirect for ^/api.+$ URIs

hmm, not impossible, I don't recall the exact format

Link Mauve, ^

> Daniel, for 301, I think it’s always been a "keep POSTing", not a "convert to GET" Maybe. But nobody was doing this. And "get after post" is actually a pattern in webdev

To avoid the f5 resend isuue

jonas’: fixed indeed. Thanks

Daniel, sorry for messing this up, I could’ve sworn that the search via API was a GET and not a POST

(I actually thought about this when setting up the redirect last night)

should’ve double-checked

dwd: MUC? xmpp.org has logs wit join and part info

jonas’: no worries. Thank you for offering this service

Search via POST? That's unusual

Zash, yeah, I put it on my mental todo to also allow GET

and in a v2 of the API it’ll be GET only

debacle here? I wonder if he (aka debian xmpp team) wants to share the newsletter to planet.debian.org 😃

Zash, That'd be useful.

Everybody is talking of The Newsletter, but has it been tweeted yet?

however, the Debian XMPP team blog is also aggregated on Planet Jabber, which probably already has the newsletter - it would be duplicated there https://planet.jabber.org/

I don't think that matters

debacle: you would cause infinite recursion

That is, I don't think it's a reason to not broadcast to a wider audience :)

The Debian XMPP team could up their blogging.

Daniel, FYI, the search endpoint now supports both GET and POST

nyco, it doesn’t hurt to add a ping for urgent PRs here, multiple channels (email + xmpp) help to remind me when I’ve seen a message one of the channels

jonas’: one ping only!</Scottish-Russian-accent>

Could the Message Fastening XEP (https://xmpp.org/extensions/inbox/fasten.html) be a way to have proper answering/threading instead of citations?

j.r, the protocol isn’t the problem, how to deal with clients which don’t support it is the problem

XMPP has support for threading in RFC 6121 even, but no client does it because it’s unclear how to handle clients which don’t support or don’t want to support threads

jonas’: yeah that's a interesting thought... you could do some legacy citation but how to filter it out for clients that support it 🤔