-
Neustradamus
MattJ: Any news? - https://github.com/xmpp-observatory/xmppoke-frontend/issues/8#issuecomment-616323674
-
jonas’
Neustradamus, is xmpp.net working?
-
marc
SamWhited: yes, I'll ping you 👌
-
eevvoor
How do I connect to a IRC via XMPP? I did that bevore but cannot refind instructions nor remember how I did that.
-
Zash
You would use a transport like Biboumi or something.
-
eevvoor
Zash, how exactly? I used Gajim that time and only remeber that it was easy, nothing else :D.
-
Ge0rG
eevvoor: there are a few public hosted biboumi instances, and you can run your own of course
-
eevvoor
Ge0rG, ah ok. I will not host my own at the moment.
-
Ge0rG
eevvoor: there is a semi-public one on irc.yax.im that I'm running and I think there was also one on jabberfr
-
eevvoor
How would I use yours Ge0rG
-
Ge0rG
eevvoor: /join #channel%ircserver@irc.yax.im should work, or ad-hoc-configure irc.yax.im
-
Ge0rG
provided that s2s works for it.
-
Ge0rG
no idea though ;)
-
MattJ
No DNS
-
MattJ
irc.jabberfr.org responds though
-
Ge0rG
ah right, you'd have to add irc.yax.im CNAME xmpp.yaxim.org for it to work.
-
Ge0rG
...on your xmpp server. security by obscurity.
-
eevvoor
hm Ge0rG where do I use the /join cmd?
-
Ge0rG
eevvoor: in your xmpp client
-
eevvoor
ah :D
-
eevvoor
Ok. it worked. thx Ge0rG, this time I document it for myself.
-
eevvoor
In case I would need to specify the port, would it be also in the join line?
-
pep.
To configure the port you'll need ad-hoc support I would say
-
MattJ
Anyone know of a client library (not web-based) that supports websockets?
-
Link Mauve
MattJ, nbxmpp, from Gajim.
-
MattJ
Ah nice, thanks
-
eevvoor
ok pep. the question was luckily just for curiosity.
-
MattJ
flow, just sent a mail regarding list-multi
-
MattJ
XEP-0004 forbids arbitrary values there
-
MattJ
Hmm, what do people think about a <comment> block in XEPs that isn't rendered by default?
-
pep.
Comment for whom to see?
-
MattJ
People working on the XEP
-
pep.
ahh
-
MattJ
Potentially useful for detailed rationale, etc.
-
pep.
Sorry I read "block" and "XEP" and I made the wrong connection
-
jonas’
MattJ, <!-- ... -->?
-
MattJ
It would be nice if we /could/ render these though
-
MattJ
e.g. in a different colour
-
pep.
MattJ, I would prefer to render the rationale tbh :x
-
jonas’
I think detailed rationale should simply go in the document itself
-
MattJ
That could lead to a lot of noise
-
MattJ
I don't think XEP-0313 needs a detailed explanation of why it uses list-multi or text-multi
-
pep.
Do you have an example ?✎ -
pep.
Do you have an example? ✏
-
pep.
hmm
-
MattJ
That's just going to be noise for people trying to implement it
-
jonas’
MattJ, ah indeed
-
jonas’
just put it in <✎ -
MattJ
But for people working on the XEP, or curious in these decisions, it's valuable
-
pep.
Well that can go into a "rationale" section that people can skip
-
jonas’
just put it in <!-- .. --> I think ✏
-
MattJ
No, I kinda want it inline
-
jonas’
MattJ, so put it inline?✎ -
Zash
Oh but XEP-0122 lets you alter the behavior of list-multi
-
jonas’
(ah that was in reply to pep) ✏
-
Zash
https://xmpp.org/extensions/xep-0122.html#usercases-validation.open
-
Zash
Tremble before the tower of complexity!
-
MattJ
It would be nice for a HTML rendering with author notes visible
-
Kev
I agree that a 'real' block that's unrendered but renderable would be useful for quite a lot of things.
-
MattJ
and we can even render both versions on the site by default
-
MattJ
Zash, aha, thanks
-
Zash
https://cerdale.zash.se/upload/aR8BT1lrepN3wuPq/details.html
-
MattJ
Nice
-
Zash
Hm, views. Separate renditions / views for users, implementors, authors?
-
MattJ
Users? No thanks
-
Zash
User view = just a description of the feature + list of implementatinos
-
MattJ
Right
-
Zash
Becasue XEP == Feature now.
-
flow
MattJ, replied
-
Kev
MattJ: Oh, I was thinking of a JS toggle, rather than a different document.
-
flow
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
-
MattJ
Either works for me (Zash's solution doesn't even use JS)
-
Zash
Kev, `<details>` !
-
MattJ
"The field enables an entity to gather or provide multiple lines of text. ***"
-
Kev
Whatever :)
-
MattJ
"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"
-
Zash
What happens if you put newlines in the individual <value>s?
-
Kev
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.
-
Zash
Kev: Perfect!
-
Zash
How many unique IDs do you think the MUC logs of this chat room has?
-
flow
MattJ, that requirement appears strange to me. but irregardless text-multi should be a good fit?
-
Kev
text-multi is just a way of providing a multi-line text field, it's not multiple text entries.
-
MattJ
Other than I expect any sensible library is going to return a multiline string from this form, it's "ok"
-
Kev
So I think that's a worse fit than list-multi, TBH.
-
MattJ
As long as newlines aren't allowed in message ids...
-
MattJ
list-multi does feel cleaner
-
Zash
``` <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> ```
-
flow
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
-
flow
ahh the requirement above explicitly talks about "an application", everything is fine then ;)
-
MattJ
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
-
MattJ
Would be easier just to split by newline again
-
MattJ
But ugly
-
MattJ
I think I'm going with list-multi
-
Zash
Luckily we don't have any validation that values are among the offered options \o/
-
Zash
Haha, maybe IDs should be JIDs, then we use jid-multi :D
-
lovetox
hm if list-multi says a client is not allowed to add new options
-
lovetox
but we never receive a form from the server in the MAM spec anyway
-
lovetox
so tecnically we dont add new values
-
Zash
What's about the iq-get?
-
MattJ
You do receive a form (but you don't have to)
-
lovetox
ah yeah you can request it i remember
-
Zash
You receive the form from the allmighty XEP author when you read the holy text.
-
flow
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
-
Kev
Maybe it shouldn't be a list at all, but just a single value? :)
-
MattJ
At which point we might as well stick with the current non-form proposal
-
MattJ
<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; <validate/> element that signals the list is open to arbitrary values provided by the client.</p>
-
Kev
Seems pragmatic.
-
flow
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?
-
flow
ahh, TIL <open/> from xep122 is actually defined as what we need
-
flow
must the <open/> only appear on form retrieval or also on form submission?
-
Zash
retrieval
-
Zash
The entity you're submitting it to should know what the form looks like
-
Zash
so, sending them such metadata would be redundant
-
flow
yeah I know, I just wondered if there is some spec text on that
-
Zash
IIRC 0004 says that the basic type attrs are optional on submitting, same logic
-
flow
not sure if my spec laywer would agree to that, but yes ;)✎ -
Zash
20% of Council agrees :P
-
eevvoor
> not sure if my spec laywer would agree to that, but yes ;) layer or lawyer flow ;)
-
flow
not sure if my spec lawyer would agree to that, but yes ;) ✏
-
flow
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
-
Ge0rG
💩
-
pep.
<💡/> 4 chars
-
Zash
<🗪 xmlns=💡/>
-
Zash
`<💬 xmlns=💡 type=🗫><body>Nobody said XML element names are restricted to ASCII</body></💬>
-
pep.
missing a >
-
pep.
Or is that my terminal
-
Zash
Haha
- rion took a look on the calendar. Doesn't seem to be 1st..
-
Syndace
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
-
Syndace
no idea if this is the formally correct way to re-propose a protoXEP that has been rejected before 😀
-
pep.
As an editor I am not sure how to deal with this :p
-
MattJ
Let's just say it is
-
Syndace
Technically you can treat it as a new protoXEP, it has a different name and 99% different content
-
pep.
Do we need an ACK from the original author
-
MattJ
I have some feedback but can't type it up right now
-
Syndace
okay I converted it to a draft pr for now
-
pep.
Syndace, thanks
-
Zash
pep., enough of an ack? https://github.com/xsf/xeps/pull/933#issuecomment-616742618
-
pep.
:DD
-
Zash
Did I spell Syndace correctly this time?
-
pep.
yeah
-
Zash
Wrote "Syndance" first :)
-
Syndace
Hahaha I like it :D
-
pep.
Syndace, poke me when you remove the WIP state and it's ready to merge
-
pep.
Or another editor
-
Syndace
Sure, thanks
-
Zash
I suppose you want to add your own version block as well
-
Zash
Oh wait, you did
-
Zash
Confused by indentation. nm me.
-
Syndace
:)
-
Zash
Not sure you want to delete the old one tho, since that was a thing that was proposed
-
Syndace
theoretically protoxeps are supposed to be version 0.0.0 anyway afaik
-
Zash
Oh no!
-
pep.
I'm always so confused by our versioning scheme
-
pep.
I don't like it
-
Syndace
but I'll wait for an editor to tell be that :)
-
pep.
XEP-0001 doesn't actually say protoXEPs are not versioned
-
pep.
It just seems to say a XEP (experimental) gets published with version 0.1
-
Syndace
oh, I think I read something in the readme of the xeps repo
-
pep.
Maybe the xep-README thing contains useful info
-
pep.
2§ XEP Editor Responsabilities: 11. List administration ??
-
pep.
"Set the version to 0.0.1."
-
pep.
for a protoXEP
-
pep.
I would like to note that this file mentions a mercurial repo for XEPs :o
-
Syndace
:D
-
Zash
I think I still have a clone of that repo, from ... bitbucket? or whatsitcalled?
-
pep.
Does anybody still have access to editor@xmpp.org?
-
Syndace
Zash: do you have any feedback on the content? Did I about grasp what we discussed yesterday?
-
Zash
I got distracted before I got that far :)
-
MattJ
Ok, I'm here for a few
-
Syndace
sane✎ -
Syndace
same ✏
-
MattJ
Syndace, a big one I'd like to comment on is internationalized responses
-
MattJ
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
-
Syndace
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"
-
MattJ
and we had a big discussion a while back about multiple <body> tags
-
Syndace
(oh boi, french I mean)
-
MattJ
I think what I'm converging on is the approach that generally each interaction is confined to one language
-
MattJ
and this can be indicated by xml:lang for clarity
-
MattJ
A Spanish bot, or a multilingual bot in a Spanish MUC is just going to use Spanish for all interactions
-
Syndace
does the bot always know the preferred language of the recipient?
-
Zash
If it's responding, it can know
-
MattJ
My argument is that yes, in practice it does
-
Zash
Dunno if you have bots initiating interactions ever
-
MattJ
We have basically never used the multiple xml:lang <body> thing, it's basically a lurking security issue at this point
-
Zash
💡️🤖️> Hello Zash, you haven't voted yet. Maybe you wanna do that now? Eh?
-
MattJ
It has many problems in practice, and I think it's good to keep things simple, and not add stuff just because we can
-
MattJ
I was planning hats (aka Badges, whatever) to offer translations, and I decided to drop it on similar grounds
-
Syndace
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"?
-
Zash
Syndace, not remove, but only allow one
-
Zash
xml:lang is still allowed everywhere in theory
-
MattJ
It should have (optional?) xml:lang
-
MattJ
But not support for multiple
-
Zash
Hm, multilingual bot interactions, would that be an informational XEP?
-
Zash
Actually applies to servers
-
pep.
"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 :(
-
pep.
There's no "one language defined"
-
pep.
poezio@ is such an example
-
MattJ
pep., I'm fine with that
-
MattJ
But you wouldn't deploy a Spanish-speaking bot in that room, would you?
-
pep.
I could deploy a french + english bot
-
Zash
MUC deos have that "primary langage" field that we're using now :)
-
MattJ
I don't think in this case you are the exception
-
MattJ
In reality we all speak different languages, but each room does tend to have a primary (and sometimes a preferred secondary)
-
pep.
and that bot would not just use french or english, it'd used french and english
-
MattJ
I really don't think it harms anyone for the bot to be just like anyone else
-
MattJ
It can
-
MattJ
But it can't mix both in one message
-
pep.
in one <message>?
-
MattJ
Yes
-
Syndace
my thought process was that bots are probably the only real use-cases of a message with multiple bodies in different languages
-
pep.
why not, I'm not sure I get it
-
Zash
Normala människor don't mix olika språk in the same meddelande!
-
Syndace
but if the multiple bodies is a think you'd rather see die (which I can totally understand) then I will remove the support
-
Zash
pep., most bot interactions is responding to humans, right? just respond in the same language and things should be fine.
-
Zash
so !ping would respond pong and !shtrudel would reply kartoffel
-
Zash
easy peasy
-
pep.
:D
-
pep.
That's fine when answering maybe
-
pep.
Not when initiating
-
pep.
(I'm only reading now what's being said above)
-
Syndace
anything else matt? 🙂
-
MattJ
If you're in any doubt, you should dig up the previous xml:lang discussions
-
pep.
which ones!!
-
MattJ
Yes, there was something else, let me check
-
pep.
Somebody(tm) should write an informal XEP about @xml:lang
- pep. adds that to XEP ideas
-
MattJ
Oh, I think it was just the naming "allowed response" - it makes it sound like other responses are disallowed
-
Syndace
well they probably are
-
Zash
Oh no
-
Syndace
if you reply "lol maybe" to memberbot it won't be happy
-
MattJ
I don't think that's necessarily the case
-
Zash
My freedom to reply "lol maybe"!!!
-
MattJ
Providing shortcuts for common responses, but also allowing freeform responses is definitely a valid use case
-
pep.
Zash, and the bot's freedom not to listen to your "lol maybe"!
-
Syndace
true
-
Zash
pep., mutual freedom, mmmmmmmm
-
MattJ
and for legacy client's it's a reality you'll have anyway
-
Syndace
taking ideas for alternative element names :D
-
MattJ
Oh no, that's the hard part!
-
Syndace
right xD
-
Syndace
maybe just response, there should be no ambiguity as we're using a namespace anyway
-
MattJ
Yeah, that sounds good
-
Zash
<{quick-responses}response>
-
moparisthebest
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!
-
pep.
https://wiki.xmpp.org/web/XEP_ideas/@xml:lang !
-
flow
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?
-
MattJ
flow, "yes" ;)
-
flow
ahh the universally valid answer
-
MattJ
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
-
pep.
the latter?
-
pep.
yes
-
MattJ
Other than "default"
-
MattJ
which for Prosody at least means "whatever it currently is"
-
flow
smack currently sends all values, but I see a possiblity to save bytes on the wire!!!
-
MattJ
Yeah, I think it's sensible
-
MattJ
But I can't say that another server won't reset all the missing fields to their defaults
-
flow
lets see what ad-hoc commands do…
-
flow
hmm ex11 and ex12 in xep50 not helpful✎ -
flow
hmm ex11 and ex12 in xep50 are not helpful ✏
-
flow
is that really not defined? :(
-
MattJ
Syndace, I'm also unsure about whether responses or actions should be limited to the previous message
-
MattJ
Responses, probably, I guess... since there is no id
-
MattJ
But actions, a bot could (and probably would) put a sensible unique id on each action, that's up to the bot
-
Syndace
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
-
MattJ
If I push some more commits to the same PR, it might cause another notification, but the 'merge' button could have the same id
-
pep.
You're starting to comfort me that these may be two different use-cases
-
MattJ
If it's a textual response then yeah, it's not clear what it's replying to
-
Syndace
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
-
MattJ
(without the in-reply-to thing we discussed)
-
MattJ
If it doesn't, that's the bot's responsibility. I just gave an example of non-unique ids being fine
-
MattJ
It's likely worth mentioning, but I don't think it is necessary to forbid actions on older messages
-
pep.
I also find this weird
-
Syndace
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?
-
pep.
I wouldn't forbid it
-
Syndace
chance*
-
pep.
I don't think we can do much about this until threads or whatever other magical solution
-
pep.
If there's an id and I support it, I'll use it
-
pep.
if it's between people, they'll figure it out
-
Syndace
> 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
-
pep.
Syndace, what if they're different?
-
pep.
Why would you prevent this
-
Syndace
but I can remove that restriction and add a note that this should be kept in mind
-
pep.
Sure
-
pep.
"There might be cases where.. *handwave-maybe-somebody-will-figure-out-a-solution*"
-
Syndace
yeah right, will do that
-
pep.
And hope you get feedback from implementing clients
-
Syndace
yeah. first of all I hope it gets accepted as experimental 🙂
-
Syndace
the changes we're discussing right now are already too advanced for a protoxep that might just get rejected 😀
-
pep.
:D
-
MattJ
It would be a bit weird if two PRs came in and only the second one had a merge button
-
pep.
definitely
-
Syndace
hmm that's true
-
pep.
Maybe the merge button can actually be "merge !234" and "merge !345"
-
Syndace
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
-
pep.
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
-
pep.
We could have skipped an editor roundtrip in between
-
pep.
I kinda prefer what's happening with MAM atm
-
pep.
What would be a use-case for allowing registering accounts (IBR2) after bind
-
Syndace
Quick Response updated, here's the rendered version: https://syndace.com/xeps/inbox/quick-response.html
-
Syndace
pep. I'll remove the WIP now I guess, this should be ready to be voted on, even if it's not perfect yet
-
pep.
gogo, I'm merging stuff nao
-
Syndace
done
-
Zash
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.
-
Syndace
ah interesting, was wondering when to use which
-
Zash
I forget if this is mentioned in some XEP but otherwise it's a general XML guideline thing.
-
pep.
I'm unsure if buttons should be removed from the inbox though
-
Zash
Same
-
Syndace
#depends
-
Zash
Seems a weird thing to do
-
Syndace
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 _os_ buttons✎ -
Syndace
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 ✏
-
Syndace
I mean, locally I didn't `rm` buttons but I `mv`ed buttons to quick-response 😀
-
Zash
This is why working on protoXEPs is generally discouraged
-
pep.
Zash, how do you rework refused XEPs?
-
pep.
To repropose them once feedback is integrated
-
Zash
Why couldn't that be done in experimental?
-
pep.
Don't ask me, I'm not part of council rejecting stuff :p
-
pep.
Don't refuse protoXEPs, people wouldn't have to work on them :P
-
Zash
I wasn't on council then
-
pep.
/jk
-
Syndace
can the author of a rejected protoXEP ask the editor to remove that rejected protoXEP from inbox?
-
Syndace
If so I'd propose that Zash just formally asks pep. to remove buttons and we're good 😀
-
Zash
I'd say leave it. It was voted on, it's good to be able to go back and see what that was.
-
Syndace
fair enough
-
pep.
Syndace, can you do that? unrm it
-
Syndace
on it
-
pep.
thanks
-
pep.
Zash, on a related note, I want to work on ToS (inbox/tos.html) and if possible keep the name, how to do? :p
-
Zash
oh glob
-
Syndace
there we go, feel free to squash obviously
-
Syndace
hmm now I wonder whether I should remove all traces of buttons from quick-response
-
Syndace
like old version blocks and zash as author
-
Zash
🤷️
-
Syndace
whatevs, if that's not an editorial issue leave it at that
-
Zash
Let's not try to determine if this constitutes an original work or a derived work.
-
pep.
I'm fine with that I've got a signed message from the original author
-
Syndace
nah it's cool, feel free to merge now
-
Syndace
I hope you don't have to wait for the pipeline 😀
-
pep.
I do, to update xmpp.org at least
-
Zash
> this is not always the case due to reasons