XSF Discussion - 2019-04-09

moparisthebest: SamWhited might know the right people there...

jonas’, what kind of changes can move a XEP to Deferred state?

Seve: no changes for a year

Ge0rG, yes, but can changes in the document move it to Deferred? Just trying to understand the following sentence: "Only substantial, non-editorial changes count as activity (or updates) for the purpose of considering moving a XEP from or to Deferred state." What kind of changes can move a XEP to Deferred?

Seve: none

Seve: that sounds like an unfortunate wording

Ge0rG, thank you, I just wanted to check just in case https://github.com/xsf/xeps/pull/780/files

Seve: ah, it actually does have a meaning: editorial changes don't count when checking whether to move *to* Deferred

Ge0rG: may be too early for me then! I'll check it out later, on my bike. Thank you :)

Don't read and drive!

> No DoX servers on there yet though :) What is DoX? I thought the X was to denote T/H without typing longly? Oh, DNS over XMPP?

Seve, the point is, editorial changes do *not* count when considering whether to move a XEP to deferred. I.e. if it has received editorial changes (but no substantial, non-editorial changes) over 12 months, it still moves to deferred.

jonas’, that way is understandable, but I'm not sure if the problem here is my poor English or the wording. I will try to check it again on the evening today and see, because I'm still so-so with the "from or to", but my poor English has many chances to be the problem here :)

heh

I can fix the wording either way

please leave a comment on the PR so that I don’t forget

For the little it's worth, the wording seems fine to me.

Because there are changes from and to deferred, and the type of updates done affects both.

But isn't question if the wording is fine for people with less knowledge about how the process works. And obviously it already confused people. If it can be improved so that it is easier to understand, then we should

(and I will)

Kev, I’m still not convinced that the things XEP-0001 says about versioning are sufficient to simply refer to that from the text, because it doesn’t at all mention how editorial changes affect versioning, AFAICT

Indeed, isn't that the point? That editorial changes are out of scope of the process. They don't need approval, they don't need 'Updated Versions' (in XEP-0001 speak), they don't trigger moves from Deferred, etc.

Is it part of the process specification that they don't need approval and stuff?

It's part of xep 1 that immaterial changes to Draft don't need approval, yes.

Kev, I think it should still be mentioned

moparisthebest, https://github.com/igniterealtime/Smack/commit/62fd897cf7c021b845ce7f4e66b5e04348204975

Did anyone try Matrix's Jitsi videoconferences? Do they even work?

Browser is just endlessly loading up Jitsi widget, then shows unpressable button "join conference"

Maybe ask in a matrix channel?

It is impolite to ask fanboys if their crap even works )))

Ok, it's definitely broken.

https://medium.com/miquido/successful-migration-to-a-custom-xmpp-solution-76fcdecb0928

Hey goffi thanks for sharing! Will take a look later

they use a mongoseIM and a custom inbox feature (cf. https://mongooseim.readthedocs.io/en/latest/modules/mod_inbox/)

flow: very nice!

flow: Have you possibility to add SCRAM-SHA-256(-PLUS) in Smack too?

Neustradamus, yes, but not a priority

Because a lot of softwares use Smack and for have a full compatibility with "New generation" servers

Tigase, Jackal, Metronome IM already ready.

Openfire wait Smack I think ^^

Ejabberd had all informations for add support.

Can anyone tell why service discovery was removed from xep203?

https://xmpp.org/extensions/xep-0203.html#revision-history-v0.3 I guess look up council logs from around 2007-03-28 ?

wat

https://mail.jabber.org/pipermail/council/2007-March/002051.html

> 8. XEP-0203: Delayed Delivery > Issue Last Call? > No objections. Peter to add section on service discovery.

https://mail.jabber.org/pipermail/council/2007-March/002058.html

Oh, here https://mail.jabber.org/pipermail/council/2007-March/002057.html

> Ralph -1 pending removal of service discovery section. Peter to remove and publish version 0.3.

So, ask if ralphm remembers what the reasoning was

Let me think.

I'd have to look at the diffs and discussion logs.

Doesn't seem to be any logs from 2007 in the current archive tho

Doesn't mean I don't have them.

I would guess that it makes sense to just always stamp on delay since the receiver should ignore what they don't understand

Maybe also because it is a format that can also be at a different level than as the child of a stanza.

I'll look into it later, when back home

Still remote, but seems the log files at logs.jabber.org have 404'd since 2007, though there was always an index. Maybe intosi or Kev can comment on this.

> Zash> I would guess that it makes sense to just always stamp on delay since the receiver should ignore what they don't understand

then we should rename it to timestamps

When *delayed*, not always

but then I need to check if my service would add <delayed/> by doing disco, no?

background is https://medium.com/p/48806d283e6e/info

You know who did it by looking at the @from attribute

It seems sevral people seem to want to use delayed delivery for a generic timestamp thing. I think you need a new XEP with different semantics for that.

I receive a message stanza, how do I know if it got delayed or not? If there is no <delay/> tag on it then it may also because the service does not add them at all

Well then you don't know.

service discovery doesn't change that does it?

moparisthebest, if the service announces the feature and if it is specified that it will add <delay/> if it does so

I always felt that it would have been better if we hand't done <delay/> but <timestamp/>

akin to what you'll find in your mail headers

so you are trying to distinguish between "server announces delay but not marked delayed so it definitly wasn't delayed" and "maybe it was delayed maybe it was not" ?

moparisthebest, yep

Why haven't you submitted a XEP about it?

You mean like trace headers, ie Received?

I wouldn't advise showing "maybe it was delayed maybe not" to users, that kind of thing would anger them

"XMPP sucks, can't even tell if it was delayed or not"

INSTANT MESSAGING

Zash, yes, like 'Received', I always expected that such a XEP does not has a chance of getting accepted

I think it'd be better to always assume not delayed, then if a user complains, blame it on their network connection :D

but I would possibly try anyway

flow: I want the part where it records the security status of the connection it received from

so a "I promise it was encrypted but may be lying" element Zash ?

Zash, good point, so we could sneak in timestamp by a generic "trace" extension xep

which also records more metadata about the connection the stanza was received

isn't e2e vastly superior there, aka "I promise was encrypted via this cryptographic proof"

moparisthebest, depends on your goal

it is mostly interestant for statistic and debug use cases, but not for protection/security

*interesting

moparisthebest: It would be for debugging primarily, which also means it probably doesn't need to go on every stanza

Could go on a modified ping of some sort

meh, but I want my timestamps on every stanza

flow: Take 203, reword the semantics, submit, ???, PROFIT!

but the ping thing is interesting, that way you could record the stream information of every involved stream in both directions

Also, I'd wanna be careful with stuff that's added on every stanza

true, but there is a need for timestamps and xep203 commonly gets misunderstood by people https://medium.com/@les92raf/oh-i-get-that-right-xep-0203-can-serve-as-timestamp-xep-cb20020e8104

but maybe re-adding disco to xep203 and explicitly pointing out the use-case as "timestamp XEP" is sufficient

<time stamp="xep82" [ by="jid" ] />

But semaaaaaantics

Zash, how about an (optional) 'from'?

flow: ?

<time stamp="xep82" [ by="jid" ] [ from="jid" ] />

flow: Isn't it already?

by==from

or wat

isn't by the entity that adds the stamp?

flow: That's what I meant. What do you mean by from?

@from looks like an accomodation for legacy entity time things

Zash, I would record the xmpp address of the entity from which the stanzas was received in the 'from' attribute

again, think of mail's 'Recveived' header

flow: For the trace path use case? That makes more sense

Altho it might be redundant?

Also privacy considerations

dunno, yes, I could also go on with <time/> without 'from'

privacy considerations?

Leaking sender JID trough semi-anon MUCs and the like

right

If <time stamp="xep82"> means the timestamp that the original client sent it it then it makes sense

https://xmpp.org/extensions/xep-0203.xml is 404, what's with that?

I think that was mentioned already last week or this weekend

(but I don't remember)

I FIX

any chance to un-break this link? http://logs.xmpp.org/xsf/2018-07-05/#14:03:32

MMmmmm, if it's 404 it's likely among the files that were corrupted in the crash

the recent one?

because that’s after The Big Server Crash

Oh

The trailing /

timestamp anchor doesn’t work though

Those were not unique

meh

Not sure why it didn't use them in the conversion tho

jonas’: Feeling up to some homegrown HTML template hackery?

probably not

I already parsed ldif in sed today, I think that’s enough

-- FIXME In the year, 105105, if MUC is still alive, -- if Prosody can survive... Enjoy this Y10k bug

jonas’: There's a semantic difference between foo and foo/ and it irks me

It's trying very hard to make something/ always be listings and something/foo be content

jonas’: http://logs.xmpp.org/xsf/2018-07-05/#14:03:32 works now?

\o/ thank you :)

since when do you have +w on that machine? good to know :>

Prosody stuff

Fixed the logs page to work with the Prosody version in use now.

GSoC is down to 37 minutes for applications

Guus, ha, now that you’re around, please be notified that I made a card in the board trello, I hope I made it in the right place

oh right, seve too :)

I'm on mobile, hard to check

But if it's on the board somewhere, we will find it

good :)

it’s right on the top left, firts thing in agenda items

jonas’, ahh I didn't find it hah :D I moved to Itemos for discussion, since this is what we use currently

jonas’, thank you very much!!

my last memory of it was that the leftmost column served as "inbox" and board would assign it to wherever. thanks Seve

Whatever works :)

Zash, does that come close to your xmpp traceroute vision: http://geekplace.eu/xeps/xep-traceroute/xep-traceroute.html ?

In a 199 ping?

Zash, that's mostly a "what if"

the ping recipient probably won't do the right thing, so we need a custom IQ anyways

…probably i think. I wondered if we could design something like that which does not require support from the recipient

And things adding stuff to IQ stanzas along the way is a bit weird

true, message is also an option of course

flow: OF if everything along the way supports it then it doesn't matter

Zash, which stanza type to use?

Dunno