jdev - 2020-04-10

jonas’ aioxmpp output now part of the Openfire Travis build: https://travis-ci.org/github/igniterealtime/Openfire/jobs/673309693

loads of output - would love to get guidance on a) how to run only integration tests, b) how to interpret output

so what is the suggested way of using priority right now

Gajim allows the user to set his own priority if he wants

per default i would use 0

then Gajim adjusts automatically the priority according to show value

means away = 50, dnd = 100

does this still make sense in todays enviorment?

Carbons kinda obsoleted priority.

yeah i thought so, but it maybe still can be useful?

so you would suggest always use 0, expect user for some reason override

lovetox, for optional priority there is a recommendation as well https://docs.modernxmpp.org/client/design/#deprecated-options

yeah thanks

lovetox, either way increasing the prio for away and dnd looks wrong way round, no?

did not look it up in the code

i just wanted to give an example

Ah.

Anyway I would think the advantage of setting prio depending on status might be interop with old-school (non-carbons) use cases. OTOH the advantage of everyone sticking to prio=0 will usually emulate carbon behavior for incoming messages (if they're sent to the bare JID).

The advantage of producing correct English sentences exists does not.

but is that something you would add as opt-in (shwo prio adjustments)

or would it be the default to do that ✏

actually you are online with 3 resources, all have prio 0 :D

I tried to explain why I'm unsure. Not very helpful I know 🙂 In the end I'd probably stick to prio=0 by default as that's what everyone recommends for modern clients. Probably due to the "emulate carbons" idea.

i guess i keep the feature, but default to prio 0

And for normal end-user clients I'd definitely not expose prio knobs to users, but I guess Gajim is still also a power-user client.

So yeah "keep feature but default to 0" sounds sensible to me.

Guus, so, the output is roughly like this: ERROR: […] followed by an (often not immediately useful) traceback, followed by a debug log which includes the verbatim bytes sent and received over the XML stream

best to be read from bottom to top, since the top part often contains pre-test negotiation

in the first case, aioxmpp receives <item-not-found/> in response to a disco#info query, which is at least wierd

aioxmpp.e2etest.provision.client14.XMLStream: DEBUG: RECV b'<iq type="error" id=":rnZ16HksNXwLMrtNoyAx" from="1dphv93k5z@example.org" to="1dphv93k5z@example.org/1dphv93k5z"><query xmlns="http://jabber.org/protocol/disco#info"></query><error code="404" type="cancel"><item-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>'

as to running only e2e tests … that’s a good question, I don’t think that’s supported. I’m also not sure it’s immediately useful, since the normal tests should pass too (and are orders of magnitude faster than the e2etests, so they are often neglegible in runtime). The advantage of running all tests is that if another test fails, it may be an indicator that something is broken in the environment which may cause false-positives in the e2etests

Guus, more detailed discussion we probably better take into some 1:1 chat

but this should already be useful; item-not-found in response to a disco#info without a node is at least weird

jonas’ sure - or in open_chat - we're currently doing more aioxmpp ci setup there.

https://xmpp.org/extensions/xep-0100.html#addressing is there something more elaborate

this simply does not work for IRC transports

its very hard for a client to provide some good UI how a user can join a irc channel

what i would want is the server returns a form with fields server and channel

Hold on why is an Informational XEP specifying protocol?

user puts it in, and server returns a JID that i can join or add to the roster

lovetox, isn't that https://xmpp.org/extensions/xep-0100.html#addressing-iqgateway ?

Oh, only one field?

yes exactly

very extendable !!

Should at least be fine in single-server-mode, but then you probably don't need more than standard MUC UI

lovetox, tbh, for jabbercat I simply intended to implement the biboumi syntax.

there is no other IRC gateway anyways nowadays

:)

maybe you and the biboumi folks could conspire to write a XEP?

that’d be good

advertise single vs. multi-server mode, specify the addressing format

i think irc could be really nice integrated into a client

agreed

only with a good gateway though

(hence, basing on biboumi)

the only thing thats a bit clunky now is joining a channel

normal user has no way of discoverying the syntax, i could of course hardcode it

but meh

I guess the Matrix bridge has the same problem

i just wanted to write that

and basically every federated protocol that has groupchat caps

lovetox, there are more clunky things than just joining a channel tbh

From something like `<feature var="urn:xmpp:gateways:muc-like-using-percent-to-separate-hostname-from-channel"/>` to some dataform-in-disco to something like that XEP-0100 protocol but better.

NickServ for one..

I wouldn't want to impose that on a user who isn't experienced with IRC

How's that managed by biboumi? (So long since I set it up I've forgotten)

And then maybe it's a biboumi thing, the persistency stuff. it's nice but it's also confusing. Users leaving channels and not getting why they're still getting messages from the IRC server

Broadcasts?

"but I'm not joined on any channels on this server anymore!" ("yes.. you are..")

ircv3.net standardises sasl to identify with an irc network. But maybe not for creating an account

Or you mean some bug where biboumi gets out of sync with your resources?

Zash, no yeah notices

Or reconnections, I think that also generates noise. While it's good to know, that will confuse people

pulkomandy, yeah biboumi is missing sasl support. But not every IRC server supports that either tbh..

And I don't know about account creation indeed

Also ghosting etc.

You can't really escape the NickServ!!

Is "NickServ" standardized or discoverable?

Could you map it to ad-hoc or something?

Implementation detail?

I think it's just the most common nick out there? Unsure

There has to be an irc server somewhere that goes otherwise, probably...

of course for a full integrated bridge there would be more to do

sasl seems to be the way(tm), all implementation "just" need support

this is the way

Was QuakeNet also using NickServ? I seem to remember something different

Or maybe it was just the Ops bots?

channel bots etc.

Q

Which were named Q, L

k

But if it was me working on this I'd go with ircv3 specs as the things I expect from servers. For other servers maybe have a degraded/failsafe mode?

Well here you go

pulkomandy, is there a discovery mechanism to know if the sasl you're attempting will work?

I guess you negociate sasl anyway

They have a "capability negociation" thing in the ircv3 spec. But I didn't read it

sasl seems to be listed there

pulkomandy, > (١٠.٠٤.٢٠٢٠ ١٧:١٤:٤٥) pulkomandy: But if it was me working on this I'd go with ircv3 specs as the things I expect from servers. For other servers maybe have a degraded/failsafe mode?