XSF Discussion - 2018-09-13

beautiful :(

https://en.wikipedia.org/wiki/Bootleggers_and_Baptists

is there people going to the 35c3 this year ?

o/

nice :) would it be possible to get early tickets by the XSF folks ?

Hello!

Haven't checked when is it (and also never been there)

First test release of eyeCU with my Jingle RTP Sessions implementation is out.

Windows build only so far. No installer - just a ZIP archive. Anyone wish to test it?

Yagiza, does it run in Wine?

Link Mauve, I don't know. It uses Qt5 for MSVC12 and FFMpeg libraries for Windows.

Link Mauve, never tried to run it with Wine.

I didn’t manage to finish to build it the other day btw, I couldn’t find any mention of qputil or qpdns.

Where does it come from?

Link Mauve, those libraries are from QtPurple framework.

Here's the link for those, who want to test: http://eyecu.ru/download/eyecu2-test.zip

It shoul run on Windows'XP and newer.

If my implementation of XEP-0166, XEP-0167, XEP-0176, XEP-0177 and XEP-0266 is wrong or incorrect, please, let me know.

Yagiza, have you done any interoperability testing with other clients, such as Gajim (0.16, not 1.0), Pidgin or Psi?

Or Empathy.

Link Mauve, not yet. It was just released and I didn't even tested connectivity outside of my own flat.

Ok. :)

Link Mauve, so, I'm looking for testers.

Yagiza, is https://github.com/gatlin/QPurple the most up to date QPurple project? There hasn’t been a single commit in five years. :/

Link Mauve, I guess, no. QtPurple is a different project from Purple Soft.

edhelas: it would be nice to get early tickets indeed. I think mathieui did it last year? Just send an email asking for it?

daniel, does Conversations do XEP-0333 in MUC? And does it just sync all messages even if I'm offline for 2 months?

Seems many clients are struggling with long MAM sync times, especially in busy MUCs after being offline for some time

With no way to know which messages you want or don't want from that history

MattJ: I'm adding a jid attribute to the response

MattJ: do you have principal suggestions on how to solve the offline-for-some-time problem?

Ge0rG, once I do, I'll let you know

I'm in research mode right now

No. Max catchup is a week or so

I don't have anything clever to fill the gaps

> MattJ: I'm adding a jid attribute to the response Which I have been meaning to write down

daniel, to which response?

It's `<displayed id='123' jid='room@service/MattJ' />`

Might be `by` instead of jid

But the idea is the same

and you send that to the bare JID of the MUC?

Yes

That's very helpful, thanks

I mean it's unique since only the time of writing counts right

So you don't have to worry about changing nicks

Lol locking at my code it's actually called 'sender'

MattJ: but that's essentially what I was trying to tell you at the developers Meetup. That's how you can solve the attachment / references problem as well

Well, MattJ could leave the room, someone takes his nick and then sends another message with id='123'

oh. that’s true. i hadn’t considered yet.

Also I'm pondering rewriting ids in MUCs anyway (yes, yes, I know...)

The sender's id would still be reflected back to them, as XEP-0045 now requires

But I guess this would break XEP-0333 from the perspective of everyone else in the room

Unless the MUC also mapped those... ick

MattJ: well not with my fancy client id fall back

I'm quite behind "id attribute and origin-id should be set the same"

It makes it clear that origin-id can always be used as a fallback in these kinds of cases

daniel: "my fancy client id fall back" is exactly what I'd like to avoid all client developers having to get right

The problem for MUC is that the id attribute is the only way to track delivery errors to occupants

daniel: I remember you being strongly opposed to the "fancy client-side self-ping" solution not too long ago.

so if it can't guarantee that those ids are unique, it can't handle delivery failures properly

Ge0rG: yeah but because of the resources. Not because it's complicated

MattJ: you could reject incoming messages with duplicate IDs :P

Origin ID doesn't consume resources

So what we should do is to have the MUC produce its own IDs!!!

Zash, that's what I was thinking, of course :)

Also, on another MUC-related note...

I'm considering sending <presence type="unavailable"/> from unavailable affiliated occupants when you join

MattJ: what problem do you want to solve? additional IQs to obtain affiliation/admin lists?

It seems a more natural way to do it than the iq method, yes

and although the XEP allows fetching the member list, it doesn't allow fetching admins/owners

Which would leak JIDs in semi-anon rooms anyway

the presence would always work

But what do you put as nick then?

except you'd need clients to rely on the presence push to not query affiliation

=resource. You know what I mean

Just leave it empty. It worked well enough for avatars 😁

daniel, Prosody is now storing nicks with affiliations

Ge0rG: yeah but if the room is anon then it's essentially no information at all

If you have an empty presence w/o jid in the x and resource

Use the room JID and let the client figure out all the <x> stuffed in there ;)

No, this would come from the occupant JID, on the assumption that Prosody knows the nick associated with the affiliation

This is already in XEP-0045, and there is already a config option in the XEP for toggling whether to include these presence stanzas

What option?

daniel, I take it back, it's not a config option, it's a status code

<statuscode> <number>102</number> <stanza>message</stanza> <context>Configuration change</context> <purpose> Inform occupants that room now shows unavailable members </purpose> </statuscode>

I thought there was a corresponding option, but I can't see it right now with Ctrl+F at least

45 is full of surprises

Yes, this was a fun find

The most surprising things of 45 are the ones *not* written in the XEP.

ding

dong

ralphm, Guus

MattJ, I'm unavailable as announced

Can maybe lurk at best

Oh, sorry

Np

I propose we skip then

Has anyone heard from ralphm?

ah right, thx for the reminder, so no quorum...

+1W?

wfm

MattJ: not me

not me

:'(

I am still alive

But overloaded with work meetings

ralphm, ok, glad you're ok :)

aaaah

so let's overload him even more!

Next week should be better. 🤞

Famous last words