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?
Shellhas joined
serge90has left
Kev
text-multi is just a way of providing a multi-line text field, it's not multiple text entries.
serge90has joined
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
Jeybehas left
Jeybehas joined
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>
```
goffihas left
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
Shellhas left
Shellhas joined
APachhas left
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
waqashas joined
Zash
Luckily we don't have any validation that values are among the offered options \o/
serge90has left
serge90has joined
Zash
Haha, maybe IDs should be JIDs, then we use jid-multi :D
serge90has left
serge90has joined
mukt2has joined
lovetox
hm if list-multi says a client is not allowed to add new options
serge90has left
lovetox
but we never receive a form from the server in the MAM spec anyway
lovetox
so tecnically we dont add new values
serge90has joined
bearhas joined
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.
serge90has left
serge90has joined
mukt2has left
Jeybehas left
serge90has left
krauqhas left
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
serge90has joined
krauqhas joined
bearhas left
serge90has left
serge90has joined
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
serge90has left
serge90has joined
adiaholic_has left
adiaholic_has joined
mukt2has joined
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>
serge90has left
serge90has joined
pdurbinhas joined
Kev
Seems pragmatic.
nycohas left
serge90has left
serge90has joined
pdurbinhas left
Mikaelahas left
Mikaelahas joined
Mikaelahas left
Mikaelahas joined
serge90has left
serge90has joined
mukt2has left
Mikaelahas left
Mikaelahas joined
Shellhas left
serge90has left
serge90has joined
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?
mukt2has joined
flow
ahh, TIL <open/> from xep122 is actually defined as what we need
serge90has left
serge90has joined
j.rhas left
nycohas joined
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 ;)✎
serge90has left
serge90has joined
bearhas joined
Zash
20% of Council agrees :P
andyhas left
andyhas joined
serge90has left
serge90has joined
goffihas joined
serge90has left
serge90has joined
goffihas left
goffihas joined
j.rhas joined
serge90has left
serge90has joined
stpeterhas joined
stpeterhas left
xeckshas left
xeckshas joined
bearhas left
serge90has left
serge90has joined
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 ;) ✏
serge90has left
serge90has joined
serge90has left
serge90has joined
jubalhhas left
serge90has left
serge90has joined
serge90has left
serge90has joined
serge90has left
serge90has joined
Steve Killehas left
serge90has left
serge90has joined
Steve Killehas joined
j.rhas left
j.rhas joined
mukt2has left
bearhas joined
serge90has left
mukt2has joined
werdanhas joined
jubalhhas joined
mukt2has left
mukt2has joined
pdurbinhas joined
jubalhhas left
pdurbinhas left
lovetoxhas left
mukt2has left
Wojtekhas joined
sonnyhas left
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
sonnyhas joined
adiaholic_has left
adiaholic_has joined
Ge0rG
💩
archas left
archas joined
jubalhhas joined
pep.
<💡/> 4 chars
xeckshas left
Jeybehas joined
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
lovetoxhas joined
xeckshas joined
lovetoxhas left
bearhas left
nycohas left
archas left
archas joined
riontook a look on the calendar. Doesn't seem to be 1st..
Nekithas left
davidhas left
davidhas joined
APachhas joined
mukt2has joined
Steve Killehas left
Neustradamushas left
Neustradamushas joined
Steve Killehas joined
waqashas left
waqashas joined
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
krauqhas left
krauqhas joined
MattJ
I have some feedback but can't type it up right now
bearhas joined
Syndace
okay I converted it to a draft pr for now
pep.
Syndace, thanks
mukt2has left
Nekithas joined
ajhas joined
lorddavidiiihas left
lorddavidiiihas joined
bearhas left
ajhas left
lovetoxhas joined
jubalhhas left
j.rhas left
goffihas left
goffihas joined
jubalhhas joined
goffihas left
goffihas joined
j.rhas joined
goffihas left
goffihas joined
bearhas joined
goffihas left
goffihas joined
pdurbinhas joined
goffihas left
goffihas joined
mukt2has joined
goffihas left
goffihas joined
pdurbinhas left
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
APachhas left
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 :)
bearhas left
Jeybehas left
Vaulorhas left
Sevehas left
Sevehas joined
Vaulorhas joined
Shellhas joined
APachhas joined
Jeybehas joined
stpeterhas joined
stpeterhas left
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
Wojtekhas left
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?
jubalhhas left
Jeybehas left
xsfhas joined
Jeybehas joined
pep.
Does anybody still have access to editor@xmpp.org?
Wojtekhas joined
Syndace
Zash: do you have any feedback on the content? Did I about grasp what we discussed yesterday?
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
DebXWoodyhas left
Nekithas left
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
bearhas left
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>
Maxhas left
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 !
Maxhas joined
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
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
werdanhas left
Maxhas left
bearhas joined
Maxhas joined
pdurbinhas joined
archas left
archas joined
jubalhhas joined
Tobiashas left
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
gavhas left
mukt2has left
Mikaelahas left
pdurbinhas left
Mikaelahas joined
gavhas joined
mukt2has joined
Nekithas joined
wurstsalathas left
wurstsalathas joined
adiaholic_has left
adiaholic_has joined
pep.
What would be a use-case for allowing registering accounts (IBR2) after bind
krauqhas left
murabitohas left
murabitohas joined
adiaholic_has left
Jeybehas left
Jeybehas joined
wurstsalathas left
Jeybehas left
Jeybehas joined
murabitohas left
murabitohas joined
manohas joined
manohas left
archas left
archas joined
Jeybehas left
archas left
archas joined
Jeybehas joined
robertooohas left
Jeybehas left
krauqhas joined
jubalhhas left
mukt2has left
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
Mikaelahas left
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?
mimi89999has left
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