XSF Discussion - 2018-02-17

uh, so I gotta vote for myself

marc, do you intend to bring https://github.com/xsf/xeps/pull/585 to the standards@ list? Please comment with your intention so that I can move forward with the PR, thanks.

jonasw, not really, I'm not on @standards

marc, uh, can you join please?

it is kind of expected of XEP authors

that’s where comments on your XEP will usually be raised

puh... GitHub account *and* joining a mailing list

:D

github is optional ;)

haha

(it just makes my life easier, but you can always mail PRs to editor@)

jonasw, will do but tomorrow or on monday

dwd here ?

would it be possible to update https://xmpp.org/extensions/xep-0376.html to make the subscription fit with the namespace here https://xmpp.org/extensions/xep-0330.html

urn:xmpp:pubsub:subscription:0

330 doesn’t use :0?

0330 define :0

I can also bump 0330 if you need it

agh, right

I also confused namespace and node

I’m not awake yet

ok

I’m not sure what the benefit would be though

> 21:31:53 mathieui> I still haven’t come up with a way of saying my nick in english non-awkwardly how about "matthew"?

that’s more like an english translation of my name, and there’s MattJ

yeah; french matthew? ;-)

names are tricky

It's such a pity that we don't have the htmldiffs on xep bumps any more :(

Is "4.6 Image Restrictions" of vcard-based avatars xep still valid in the world of retina displays?

flow, yes, but we also don’t have a way to work around that, given that htmldiff is really really inefficient

how about starting htmldiff with a 5 min timeout?

it won’t terminate on many XEPs

and also iteam won’t agree to running this on the server.

so we’d have to do some trickery, and since incremental builds with dockerhub do not work, I don’t see a viable way

true, that's why I suggest using the timoout binary

*timeout

ahh, do we incrementally create the diffs, or all diffs every time?

we don’t at all currently

but I’m afraid that we would have to do the latter

…

What's an advisable namespace template for proprietary xmpp functionality?

Guus, https://company.example/

Guus, a URI you contral

then whatever you like

I personally do https://xmlns.zombofant.net/…

Is urn:xmpp: reserved?

it belongs to the XSF afaik

Guus, it's registered with the IANA

kk, uri it is

you could of course also do urn:uuid:

Guus, and I think you want URLs and not URNs

Pourquoi?

Its not referencing a location, but it is an identifier. So a URI or URN, I'd say?

I always get super-confused by those nuanced differences

Guus, IIRC xml namespaces only allow URL

[Definition: An XML namespace is identified by a URI reference [RFC3986]; element and attribute names may be placed in an XML namespace using the mechanisms described in this specification. ]

flow: surely not. We use urn:xmpp in xmpp

Guus, that's not an indication that it's done right

but I could be wrong

as said, IIRC

flow, https://www.w3.org/TR/REC-xml-names/#concepts

"identified by a URI reference"

so URN is a subset of URI and thus valid

Kk

Tx

Guus, bonus points if the URLs point to a schema or document describing what you’re doing :)

Does anyone know something about https://github.com/esl/MongooseIM/blob/inbox-proto-xep/doc/open-extensions/xeps/xep-inbox.html ? A XEP to know which was the last message you read and such. Or is it going to be just in Bind 2.0? https://xmpp.org/extensions/xep-0386.html#example-3

We discussed this at the Summit, but if someone could refresh my memory, please

I guess this will in some way be in bind 2

Hmm... My question is regarding this table: https://github.com/SeveFP/KDE_IM_Requirements/wiki/XMPP-Table I would like to put something on "Remembers last-read position" In Poezio you can leave the view on a certain position and continue reading later on, but if some XEP could assist this and say "Well, not now, but clients could implement it with XEP-0XXX"

:)

Seve, that are chat markers

I’d be surprised if poezio didn’t even emit them

it doesn’t

:(

(but I would consider poezio as not having the previously mentioned feature until we have real chat markers)

Seve, the IRC bridges go the wrong way though

with biboumi, IRC is still the "primary" medium of communication

It's because we had this discussion at Summit, so clients could know what you have read and such, and this would be multi device. That's why I liked to Michał Piotrowski's XEP (Inbox)

Seve, for persistent public logging, research the prosody module which is used for xmpp.org and link to the logs of this channel

(or something like that)

http://logs.xmpp.org/xsf/2018-02-17/#17:11:58

I think that’s this: https://modules.prosody.im/mod_muc_log_http.html

but I’m not sure, ask in xmpp:prosody@conference.prosody.im?join

Firewall friendly: link to XEP-0368, or even https://wiki.xmpp.org/web/Tech_pages/XEP-0368 ✏

Seve, " Depends on the client. Psi and Gajim are able to do this.", this sounds as if ONLY Psi and Gajim can do it. add an "for example," :)

jonasw, Thanks!! Yes you are right, I'm just starting with it, any feedback is welcome please. I'm going to update it as soon as I get home!

Seve, you’re welcome. that should be all of my feedback for now though :)

The nice thing about biboumi is that it allows multi client usage

Kind of like a bouncer.

But yeah, the ideal solution would be an irc server interface exposed by a MUC.

Ge0rG, that's what this is https://github.com/moparisthebest/xmpp-ircd

jonasw, sorry, I didn't understand you. Now, reading moparisthebest's comment, do you mean when they say 'IRC Bridge' they mean connect to XMPP from IRC?

Well there are 2 different ways

Biboumi let's you connect to an IRC server with an XMPP client

The opposite is connecting to xmpp muc with an IRC client, that's my thing

IRC bridge is ambiguous

By the way, thanks for that, I will add it to the table if you don't mind! Pretty handy for this situation.

Oh yea in terms of recommending xmpp mucs to KDE IRC bridge means xmpp-ircd

Sorry I hadn't read backlog

moparisthebest, my bad, I should have specified too

An interesting side effect to it that I didn't even plan is you can join from multiple IRC clients with the same Nick and it all just works

As far as I know no other IRC server supports that

moparisthebest: is there authentication in place

moparisthebest, jonasw, then, from looking at the table, I should put xmpp-ircd in 'IRC Bridge' and biboume and spectrum in 'Popular bridges'?

Ge0rG: no that's the part that is missing, like, nickserv at least, maybe chanserv

Seve: still not exactly sure what they are after

My thing is useful if they are hosting a muc, IRC users can join directly

Biboumi is useful if they are giving out xmpp accounts

moparisthebest: will it properly reflect message ids? 😀

Ge0rG: isn't that the mucs job?

moparisthebest: depends on whom you ask

moparisthebest: https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat#Matching_Your_Reflected_Message

Ge0rG: so being a component it knows there are no other clients, so it can just match the sending nick and ignore all

Which I'm guessing it's what it does, been awhile, and I didn't write it all in the first place

moparisthebest: sorry, I was still talking of your reverse gateway.

Yes I am too

I know that biboumi fails hard on reflection

moparisthebest: then I don't understand what you mean. Maybe it's just too late, I will try on Monday

Biboumi is a muc though, my thing just uses mucs

Ge0rG: If you are guaranteed no other clients are connected to the same account on a muc you don't have to worry about matching

moparisthebest [20:58]: > An interesting side effect to it that I didn't even plan is you can join from multiple IRC clients with the same Nick and it all just works That just doesn't fit with what you just said

Ah yes so it must only display on recieve and never send

Would you link to https://xmpp.org/extensions/xep-0372.html as the specification for 'Reply to (quote) messages with reference to the original message'?

Since it has a lot of TODOs, I'm not sure if I should.

Maybe that would scare more than make it interesting

Link to in what context? References is the way to do that, yes.

We'll be implementing some references stuff in Swift imminently.

Kev, that's great to hear! I'm just doing this: https://github.com/SeveFP/KDE_IM_Requirements/wiki/XMPP-Table (The original is here https://community.kde.org/IM_Survey_Results but I can't edit that, so I'm making it on my own on GitHub) The sentence is from those requirements but from another place, where they are a bit more explained. In the table it just says 'Quotes' but I guess I should say references.

And you've got 393 for just quote formatting.

The "TODO: define character appropriately" still seems like an important part missing from references; I probably wouldn't consider it fit for use until that's fixed.

Kev, yes, I wrote that, but I also wanted to specify that there's a XEP for referencing other messages, since I think is something expected. The XEP is still in need of some work, so I'm not sure if I should put it there, because the audience of that table I'm doing may or may not understand how the process work and will think I'm joking or something like that. I guess you get what I mean.

SamWhited, thank you

SamWhited, by the way, I haven't replied yet, but thank you very much for your answer on the mailing list, very very good and helpful!

Sure thing, I hope it ends up being useful. Their requirements list was a tad vague though, so maybe once they've tightened it up a bit we can help them.

SamWhited, indeed. It seems that the table I'm filling, is based on https://sessellift.wordpress.com/2017/09/05/results-of-the-requirements-survey-for-a-kde-wide-chat-solution/ So I'm trying to match the requirements on the table with the ones on that blogpost.