XSF Discussion - 2020-04-20

MattJ: Any news? - https://github.com/xmpp-observatory/xmppoke-frontend/issues/8#issuecomment-616323674

Neustradamus, is xmpp.net working?

SamWhited: yes, I'll ping you 👌

How do I connect to a IRC via XMPP? I did that bevore but cannot refind instructions nor remember how I did that.

You would use a transport like Biboumi or something.

Zash, how exactly? I used Gajim that time and only remeber that it was easy, nothing else :D.

eevvoor: there are a few public hosted biboumi instances, and you can run your own of course

Ge0rG, ah ok. I will not host my own at the moment.

eevvoor: there is a semi-public one on irc.yax.im that I'm running and I think there was also one on jabberfr

How would I use yours Ge0rG

eevvoor: /join #channel%ircserver@irc.yax.im should work, or ad-hoc-configure irc.yax.im

provided that s2s works for it.

no idea though ;)

No DNS

irc.jabberfr.org responds though

ah right, you'd have to add irc.yax.im CNAME xmpp.yaxim.org for it to work.

...on your xmpp server. security by obscurity.

hm Ge0rG where do I use the /join cmd?

eevvoor: in your xmpp client

ah :D

Ok. it worked. thx Ge0rG, this time I document it for myself.

In case I would need to specify the port, would it be also in the join line?

To configure the port you'll need ad-hoc support I would say

Anyone know of a client library (not web-based) that supports websockets?

MattJ, nbxmpp, from Gajim.

Ah nice, thanks

ok pep. the question was luckily just for curiosity.

flow, just sent a mail regarding list-multi

XEP-0004 forbids arbitrary values there

Hmm, what do people think about a <comment> block in XEPs that isn't rendered by default?

Comment for whom to see?

People working on the XEP

ahh

Potentially useful for detailed rationale, etc.

Sorry I read "block" and "XEP" and I made the wrong connection

MattJ, <!-- ... -->?

It would be nice if we /could/ render these though

e.g. in a different colour

MattJ, I would prefer to render the rationale tbh :x

I think detailed rationale should simply go in the document itself

That could lead to a lot of noise

I don't think XEP-0313 needs a detailed explanation of why it uses list-multi or text-multi

Do you have an example? ✏

hmm

That's just going to be noise for people trying to implement it

MattJ, ah indeed

But for people working on the XEP, or curious in these decisions, it's valuable

Well that can go into a "rationale" section that people can skip

just put it in <!-- .. --> I think ✏

No, I kinda want it inline

Oh but XEP-0122 lets you alter the behavior of list-multi

(ah that was in reply to pep) ✏

https://xmpp.org/extensions/xep-0122.html#usercases-validation.open

Tremble before the tower of complexity!

It would be nice for a HTML rendering with author notes visible

I agree that a 'real' block that's unrendered but renderable would be useful for quite a lot of things.

and we can even render both versions on the site by default

Zash, aha, thanks

https://cerdale.zash.se/upload/aR8BT1lrepN3wuPq/details.html

Nice

Hm, views. Separate renditions / views for users, implementors, authors?

Users? No thanks

User view = just a description of the feature + list of implementatinos

Right

Becasue XEP == Feature now.

MattJ, replied

MattJ: Oh, I was thinking of a JS toggle, rather than a different document.

MattJ, I also think the statement "text-multi is defined to be multiline" to be problematic. text-multi values appears to be explicitly *not* multi lines, as should not contain newlines

Either works for me (Zash's solution doesn't even use JS)

Kev, `<details>` !

"The field enables an entity to gather or provide multiple lines of text. ***"

Whatever :)

"an application that receives multiple <value/> elements for a field of type "text-multi" SHOULD merge the XML character data of the value elements into one text block"

What happens if you put newlines in the individual <value>s?

MattJ: It's fine isn't it? We can use list-multi, just have to have the server generate a form that has all the IDs in it so the client can then choose from them.

Kev: Perfect!

How many unique IDs do you think the MUC logs of this chat room has?

MattJ, that requirement appears strange to me. but irregardless text-multi should be a good fit?

text-multi is just a way of providing a multi-line text field, it's not multiple text entries.

Other than I expect any sensible library is going to return a multiline string from this form, it's "ok"

So I think that's a worse fit than list-multi, TBH.

As long as newlines aren't allowed in message ids...

list-multi does feel cleaner

``` <field var="archive-ids" type="list-multi" label="Archive IDs of messages to retrieve"> <validate xmlns="http://jabber.org/protocol/xdata-validate" datatype="xs:string"> <open/> </validate> </field> ```

MattJ> Other than I expect any sensible library is going to return a multiline string from this form, it's "ok" definetly, although low layers of an API would (and should) probably allows access to the individual values

ahh the requirement above explicitly talks about "an application", everything is fine then ;)

You certainly could get that info in Prosody, for example. But it's a mess, you have to then access that field differently to all the others that are parsed, validated and returned automatically

Would be easier just to split by newline again

But ugly

I think I'm going with list-multi

Luckily we don't have any validation that values are among the offered options \o/

Haha, maybe IDs should be JIDs, then we use jid-multi :D

hm if list-multi says a client is not allowed to add new options

but we never receive a form from the server in the MAM spec anyway

so tecnically we dont add new values

What's about the iq-get?

You do receive a form (but you don't have to)

ah yeah you can request it i remember

You receive the form from the allmighty XEP author when you read the holy text.

I think the fact that you can retrieve a (blank) gather form for MAM query options is a strong argument against list-multi, since you usually would have that field populated in gather forms

Maybe it shouldn't be a list at all, but just a single value? :)

At which point we might as well stick with the current non-form proposal

<p>A special note about the 'ids' field: this field is of type 'list-multi' which typically is used to allow the client to select from a provided list of options. In this form the list of all possible ids MUST NOT be provided by the server, as it is likely to be extremely large. Instead the server MUST include a &xep0122; &lt;validate/&gt; element that signals the list is open to arbitrary values provided by the client.</p>

Seems pragmatic.

Kev> Maybe it shouldn't be a list at all, but just a single value? :) Wouldn't that be an indicator that there is a hole in xep4 which we may want/need to fill?

ahh, TIL <open/> from xep122 is actually defined as what we need

must the <open/> only appear on form retrieval or also on form submission?

retrieval

The entity you're submitting it to should know what the form looks like

so, sending them such metadata would be redundant

yeah I know, I just wondered if there is some spec text on that

IIRC 0004 says that the basic type attrs are optional on submitting, same logic

20% of Council agrees :P

> not sure if my spec laywer would agree to that, but yes ;) layer or lawyer flow ;)

not sure if my spec lawyer would agree to that, but yes ;) ✏

Friendly (and probably only) reminder that you can suggest characters for the XSF to adopt by the end of the week at: https://wiki.xmpp.org/web/Adopt-a-Character or by writing me an email: flo@geekplace.eu

💩

<💡/> 4 chars

<🗪 xmlns=💡/>

`<💬 xmlns=💡 type=🗫><body>Nobody said XML element names are restricted to ASCII</body></💬>

missing a >

Or is that my terminal

Haha

Zash, MattJ: if you want to have a look at what I came up with for Quick Response: https://github.com/xsf/xeps/pull/933

no idea if this is the formally correct way to re-propose a protoXEP that has been rejected before 😀

As an editor I am not sure how to deal with this :p

Let's just say it is

Technically you can treat it as a new protoXEP, it has a different name and 99% different content

Do we need an ACK from the original author

I have some feedback but can't type it up right now

okay I converted it to a draft pr for now

Syndace, thanks

pep., enough of an ack? https://github.com/xsf/xeps/pull/933#issuecomment-616742618

:DD

Did I spell Syndace correctly this time?

yeah

Wrote "Syndance" first :)

Hahaha I like it :D

Syndace, poke me when you remove the WIP state and it's ready to merge

Or another editor

Sure, thanks

I suppose you want to add your own version block as well

Oh wait, you did

Confused by indentation. nm me.

:)

Not sure you want to delete the old one tho, since that was a thing that was proposed

theoretically protoxeps are supposed to be version 0.0.0 anyway afaik

Oh no!

I'm always so confused by our versioning scheme

I don't like it

but I'll wait for an editor to tell be that :)

XEP-0001 doesn't actually say protoXEPs are not versioned

It just seems to say a XEP (experimental) gets published with version 0.1

oh, I think I read something in the readme of the xeps repo

Maybe the xep-README thing contains useful info

2§ XEP Editor Responsabilities: 11. List administration ??

"Set the version to 0.0.1."

for a protoXEP

I would like to note that this file mentions a mercurial repo for XEPs :o

:D

I think I still have a clone of that repo, from ... bitbucket? or whatsitcalled?

Does anybody still have access to editor@xmpp.org?

Zash: do you have any feedback on the content? Did I about grasp what we discussed yesterday?

I got distracted before I got that far :)

Ok, I'm here for a few

same ✏

Syndace, a big one I'd like to comment on is internationalized responses

I think it came up while discussing the previous protoXEP, and it also has come up for me again in Hats, and possibly elsewhere too

hmm yes, I thought it would be weird if you see a frensh message and a frensh button but then on click suddenly there is an english "yes"

and we had a big discussion a while back about multiple <body> tags

(oh boi, french I mean)

I think what I'm converging on is the approach that generally each interaction is confined to one language

and this can be indicated by xml:lang for clarity

A Spanish bot, or a multilingual bot in a Spanish MUC is just going to use Spanish for all interactions

does the bot always know the preferred language of the recipient?

If it's responding, it can know

My argument is that yes, in practice it does

Dunno if you have bots initiating interactions ever

We have basically never used the multiple xml:lang <body> thing, it's basically a lurking security issue at this point

💡️🤖️> Hello Zash, you haven't voted yet. Maybe you wanna do that now? Eh?

It has many problems in practice, and I think it's good to keep things simple, and not add stuff just because we can

I was planning hats (aka Badges, whatever) to offer translations, and I decided to drop it on similar grounds

okay. So what would you propose? Remove all the xml:lang stuff and replace the i18n considerations with "if the entity aims to support multiple languages, it should do so by detecting the preferred language of its communication partner and then using only that one language"?

Syndace, not remove, but only allow one

xml:lang is still allowed everywhere in theory

It should have (optional?) xml:lang

But not support for multiple

Hm, multilingual bot interactions, would that be an informational XEP?

Actually applies to servers

"MattJ> A Spanish bot, or a multilingual bot in a Spanish MUC is just going to use Spanish for all interactions" I'm sorry to be the exception again, but it happens quite often in two different MUCs I'm in that it's not the case :(

There's no "one language defined"

poezio@ is such an example

pep., I'm fine with that

But you wouldn't deploy a Spanish-speaking bot in that room, would you?

I could deploy a french + english bot

MUC deos have that "primary langage" field that we're using now :)

I don't think in this case you are the exception

In reality we all speak different languages, but each room does tend to have a primary (and sometimes a preferred secondary)

and that bot would not just use french or english, it'd used french and english

I really don't think it harms anyone for the bot to be just like anyone else

It can

But it can't mix both in one message

in one <message>?

Yes

my thought process was that bots are probably the only real use-cases of a message with multiple bodies in different languages

why not, I'm not sure I get it

Normala människor don't mix olika språk in the same meddelande!

but if the multiple bodies is a think you'd rather see die (which I can totally understand) then I will remove the support

pep., most bot interactions is responding to humans, right? just respond in the same language and things should be fine.

so !ping would respond pong and !shtrudel would reply kartoffel

easy peasy

:D

That's fine when answering maybe

Not when initiating

(I'm only reading now what's being said above)

anything else matt? 🙂

If you're in any doubt, you should dig up the previous xml:lang discussions

which ones!!

Yes, there was something else, let me check

Somebody(tm) should write an informal XEP about @xml:lang

Oh, I think it was just the naming "allowed response" - it makes it sound like other responses are disallowed

well they probably are

Oh no

if you reply "lol maybe" to memberbot it won't be happy

I don't think that's necessarily the case

My freedom to reply "lol maybe"!!!

Providing shortcuts for common responses, but also allowing freeform responses is definitely a valid use case

Zash, and the bot's freedom not to listen to your "lol maybe"!

true

pep., mutual freedom, mmmmmmmm

and for legacy client's it's a reality you'll have anyway

taking ideas for alternative element names :D

Oh no, that's the hard part!

right xD

maybe just response, there should be no ambiguity as we're using a namespace anyway

Yeah, that sounds good

<{quick-responses}response>

Next you'll be asking about the proper first array index and the lua devs will pipe up and it'll be all out war!

https://wiki.xmpp.org/web/XEP_ideas/@xml:lang !

https://xmpp.org/extensions/xep-0045.html#roomconfig: really stupid question: do I have to submit all fields with values or just the changed fields with their new values?

flow, "yes" ;)

ahh the universally valid answer

flow, as far as I'm concerned you can just submit the changed fields, but I don't think it is actually defined what happens to the rest

the latter?

yes

Other than "default"

which for Prosody at least means "whatever it currently is"

smack currently sends all values, but I see a possiblity to save bytes on the wire!!!

Yeah, I think it's sensible

But I can't say that another server won't reset all the missing fields to their defaults

lets see what ad-hoc commands do…

hmm ex11 and ex12 in xep50 are not helpful ✏

is that really not defined? :(

Syndace, I'm also unsure about whether responses or actions should be limited to the previous message

Responses, probably, I guess... since there is no id

But actions, a bot could (and probably would) put a sensible unique id on each action, that's up to the bot

I obviously had the bot use-case in the back of my mind and I think having responses to messages that are not the last would probably only cause confusion and nothing else

If I push some more commits to the same PR, it might cause another notification, but the 'merge' button could have the same id

You're starting to comfort me that these may be two different use-cases

If it's a textual response then yeah, it's not clear what it's replying to

for actions it's not limited to the last message but the last message that contains actions. A bot _could_ obviously assign unique ids to every action it ever sends out, but that's not guaranteed and if it doesn't things become weird

(without the in-reply-to thing we discussed)

If it doesn't, that's the bot's responsibility. I just gave an example of non-unique ids being fine

It's likely worth mentioning, but I don't think it is necessary to forbid actions on older messages

I also find this weird

but if there's a new message with a new merge button, do you think it's valuable to have the change to trigger the action on the old message?

I wouldn't forbid it

chance*

I don't think we can do much about this until threads or whatever other magical solution

If there's an id and I support it, I'll use it

if it's between people, they'll figure it out

> I don't think we can do much about this well what we can do it say that only the newest actions should be accessible

Syndace, what if they're different?

Why would you prevent this

but I can remove that restriction and add a note that this should be kept in mind

Sure

"There might be cases where.. *handwave-maybe-somebody-will-figure-out-a-solution*"

yeah right, will do that

And hope you get feedback from implementing clients

yeah. first of all I hope it gets accepted as experimental 🙂

the changes we're discussing right now are already too advanced for a protoxep that might just get rejected 😀

:D

It would be a bit weird if two PRs came in and only the second one had a merge button

definitely

hmm that's true

Maybe the merge button can actually be "merge !234" and "merge !345"

yes I'm convinced, for actions it doesn't make sense to limit the messages just because the dev of a bot might mess up the ids

I find the current experimental XEP updating flow a bit weird. An author pushes changes, doesn't open any thread on standards (they're the author after all, they can just push things), I have feedback that I won't be able to get in before it gets pushed. Changes get pushed, new revision, my feedback is heard, another revision

We could have skipped an editor roundtrip in between

I kinda prefer what's happening with MAM atm

What would be a use-case for allowing registering accounts (IBR2) after bind

Quick Response updated, here's the rendered version: https://syndace.com/xeps/inbox/quick-response.html

pep. I'll remove the WIP now I guess, this should be ready to be voted on, even if it's not perfect yet

gogo, I'm merging stuff nao

done

Nit: In general, data that's to be considered "content" ought to be in text elements, and attrs should be used for more metadata-ish things.

ah interesting, was wondering when to use which

I forget if this is mentioned in some XEP but otherwise it's a general XML guideline thing.

I'm unsure if buttons should be removed from the inbox though

Same

#depends

Seems a weird thing to do

If this should be seen as a totally new protoXEP, buttons should probably not be removed. If this is seen as a rework of buttons, then it _is_ buttons ✏

I mean, locally I didn't `rm` buttons but I `mv`ed buttons to quick-response 😀

This is why working on protoXEPs is generally discouraged

Zash, how do you rework refused XEPs?

To repropose them once feedback is integrated

Why couldn't that be done in experimental?

Don't ask me, I'm not part of council rejecting stuff :p

Don't refuse protoXEPs, people wouldn't have to work on them :P

I wasn't on council then

/jk

can the author of a rejected protoXEP ask the editor to remove that rejected protoXEP from inbox?

If so I'd propose that Zash just formally asks pep. to remove buttons and we're good 😀

I'd say leave it. It was voted on, it's good to be able to go back and see what that was.

fair enough

Syndace, can you do that? unrm it

on it

thanks

Zash, on a related note, I want to work on ToS (inbox/tos.html) and if possible keep the name, how to do? :p

oh glob

there we go, feel free to squash obviously

hmm now I wonder whether I should remove all traces of buttons from quick-response

like old version blocks and zash as author

🤷️

whatevs, if that's not an editorial issue leave it at that

Let's not try to determine if this constitutes an original work or a derived work.

I'm fine with that I've got a signed message from the original author

nah it's cool, feel free to merge now

I hope you don't have to wait for the pipeline 😀

I do, to update xmpp.org at least

> this is not always the case due to reasons