goffihi there, can I have clarification on #publish-options? As far as I remember, it was an way to configure a node on creation without having to create then configure. But it seems to have changed and to be way to do per-item configuration. I haven't had chance to follow all discussion on @standard, so a summary would be much appreciated, thanks
danielgoffi: it can be both
danielThe fields are registered. And each field defines if it's is a precondition (= node configuration on publish and enforcement) or an override
goffiBut this are 2 different features. Where the fields are registered (and which fields are registered?) ?
goffithe XEP is not clear at all about that. The examples only show publication with items, and there is not notion of node creation.
ZashI don't think autocreation and configuration on publish is a thing that's specified
goffiI though it was #publish-option (and it was not specified indeed, just in example as far as I remember, like many Pubsub features unfortunately)
HolgerIt was all totally underspecified before, but the wording has been clarified and things seem clear to me now: https://xmpp.org/extensions/xep-0060.html#publisher-publish-options
HolgerZash: "If the node does not exist and the service supports the "auto-create" feature, then the service shall auto-create the node with default configuration in all respects except those specified in the preconditions, and the publish succeeds."
goffiyes that how it is implemented in SàT Pubsub
goffibut "Each field MUST specify whether it defines METADATA to be attached to the item, a per-item OVERRIDE of the node configuration, or a PRECONDITION to be checked against the node configuration. " is really confusing, which metadata can we attach?
goffihow to override item, as the text only mention precondition or node configuration on auto-create
goffiI think I'll write on @standard to discuss that, because it needs to be extremly clear and it is definetely not at the moment.
Holgergoffi: Right now there's only a single registered option (access_model), and it's specified to be a PRECONDITION. So OVERRIDE/METADATA are only theoretical options as long as no field is registered with that behavior.
ZashHolger: Is that so?
goffiHolger: where it is registered ? How can I check it ?
goffiI've implemented per-item overriding for years, and I'm since willing to propose a protoXEP for that (no time so far), so I'm willing to know if current publish-option can do it (I've explained how it's done in SàT pubsub at https://www.goffi.org/blog/goffi/S%C3%A0T_DOTCLEAR_IMPORT_BLOG_default_goffi_69%3A2012%2F06%2F24%2FFine-access-tuning-for-PubSub)
Zashgoffi: I would be happier if it was split in three
Holgergoffi: Huh you implemented it. What's the use case?
Holgergoffi: My suggestion would've been to ditch OVERRIDE/METADATA. And if someone needs that feature, re-add it using different syntax.
goffiZash: what do you mean split in three ?
Holgergoffi: Isn't the implementation a great PITA when it comes to RSM / MAM access, for example?
goffiHolger: blog post restricted to some people, similar to Google circles (even if it was done before)
ZashThree forms, where the form decides what tge fields do, not some registry
goffiZash: ah yes, I think it would be better indeed, and in a separate XEP
goffiI need to check SàT Pubsub code, I'm not sure of the behaviour if the node exists (I think the options are just ignored, which is not compliant which current XEP state)
Zashgoffi: You have my support if you were to draft one
goffiZash: I will, but it will take time, I am already drowning in work
Ge0rGYeah, reading that section of 0060 made my head explode. And I'm used to reading protocol specs.
jonaswI think we need a very diligent copy editor, ideally english mother tongue, who goes over those monsters like XEP-0060 and edits everything which is remotely unclear, while being in constant feedback with the community and council
goffidaniel: OK it's a good thing to remove override, and probably it would be nice to remove metadata too, only keeping precondition and config setting.
danieli don't care very much for metadata either
Zashjonasw: we were going to split '60 into smaller pieces
goffinot sure if there is a use case on a per-item basis for metadata. Override there is definitely, but should be separate feature
danieli'd be fine with removing it for now and reintroducing it as a seperate form later if someone needs it
edhelasdaniel I do care of metadata actually
goffiedhelas: on a per-item basis ?
edhelasah for items, meh, no
goffifor node it's needed I think we all agree on that
zinid> ideally english mother tongue
They tend to use some rare wording which is only possible to translate with a dictionary 🙂
danielremoving METADATA entirly changes the wording *a lot*. I'd rather only do that if we agree that this is the right thing
jonaswif we remove it in a way so that we can bring it back in an addendum && we don’t have any depending XEPs currently, I don’t see any issue.
edhelasdaniel in which cases you want to remove metadata ? I'm a bit lost
Ge0rGI want that whole section burned. It doesn't make any sense.
danieledhelas, publish-options. we are talking about publish-options
Ge0rGRemoving metadata and override from the XEP would suffice for me, though.
danielremoving metadata and override and maybe the ability to register additional fields would make the wording a lot more straight forward
edhelasyeah registering fields could be quite nice and make it more flexible
HolgerNah. No registering.
goffiregistering is not useful there, and bring a lot of complications
jonaswno registering, but honoring <required/> so that implementations know when an option is critical?
HolgerOnly node config preconditions. That makes it straightforward to understand and implement.
jonaswthat seems like a good compromise and allows later XEPs to extend things
HolgerAnd we make it work for all node config options in one go.l
Holgerjonasw: <required/> what?
goffithat would make my current implementation nearly compliant, just need to check the precondition
jonaswHolger, publish-options is a Data Form, right?
jonaswData Forms specifies the <required/> child for fields
jonaswusers of publish-options could make it clear that a field MUST be understood or the request MUST be rejected with that
jonaswwhile other unknown fields may be safely discarded
HolgerThe wording already does that.
jonaswjust an idea to open the venue for future extensions without making things too complicated with a registry etc.
goffiCan't we ignore unknow fields if it's not a configuration option ? Else that would make it difficult to extend (new options specified in later XEP will not be usable on old implementations)
goffidaniel: why ?
HolgerWell my suggestion was to reject anything that's not a config option.
danielbecause you have to rely on the fact that they are checked
zinidunknown fields in practice will mean a client bug in 99% cases
jonaswHolger, yeah, tbh, I was still thinking about the other use-cases, not Node Config overrides
goffibut if it's not a configuration options ?
Holgergoffi: What should the publish option do then?
goffizinid: no, it can means a new options introduced in new XEP and not handled in current server
zinidgoffi, then it's fine for the server to return error, so a client doesn't expect the option takes effect
goffiHolger: create node with right config, reject node with bad config, and let in place for unknow config options
danielhow about something simple as https://gultsch.de/files/xep-0060.html#publisher-publish-options
danielexact wording tbd
goffidaniel: happied with that, but worried about unknow fields
Holgergoffi: You can't just ignore unknown options because clients probably want to rely on them being set. See the bookmarks XEP, for example.
Holgergoffi: If anything, you could go for jonasw's route and let the client specify whether the option is <required/>. But meh.
zinidHolger, not to mention that you will get fancy "bug reports" like "I set this knob but it doesn't work!"
danielif you ever want to do something else just define your own form
Holgergoffi: I don't quite see the use case of specifying a publish option without caring whether it actually works.
moparisthebestwhat if you just specify a new XEP 'pubsub-lite' in the time honored XSF tradition of replacing complicated XEPs with simpler ones that everyone actually wants?
Ge0rGmoparisthebest: I'm already waiting for MUC to replace MIX in five years :D
ZashGe0rG: Wow, aren't you the optimist
zinidMUC to replace MIX?
goffiHolger: zinid: daniel: use case => options "serial_ids" to have ids in series instead of uuids. If present I want it to be set I specify in publish option. A server is not managing it, my publish will fail with current wording.
Ge0rGzinid: yes, because MIX is too complicated.
zinidGe0rG, ah, agreed
zinidno way I implement it in ejabberd
danielgoffi, it will already fail with the current wording
danielbecause serial_ids is not registered
ZashMIX looks unlikely to be implemented in Prosody either atm
danielyou can not just invent shit without registering it
goffidaniel: yes I didn't say the opposite, I just say the current wording and one in patch are not future-proof
zinidgoffi, can't you just request the form to check what fields are supported?
goffizinid: ah yes good point
danielgoffi, just create your own form. whats the problem?
goffizinid: but need one more request
Holgergoffi: And it buys you a clear spec with defined behavior.
zinidgoffi, ah, you client developers are afraid of requests 😀
danielcreate a form name it publish-sequential-enforcing-agency-visual-studio-powered
zinidI"m always forgetting this 😉
danieland be done
goffiOK I'm convinced now, I can just request the form
goffiso I'm fully in for daniel's patch
Ge0rGDo we need to bump the namespace version?
edhelasjust bump by .05 and we're good
danielanyone has any suggestions on improving the wording based on https://gultsch.de/files/xep-0060.html#publisher-publish-options
danielGe0rG, is that wording fine with you?
danielyou complained about the entire section before
Ge0rGdaniel: no, it's not fine. You are introducing the term PRECONDITION and kind of implicitly define it in that sentence. It works if you already know what a PRECONDITION is, but otherwise you stumble upon the CAPITAL LETTERS
HolgerHah, after pressing 'reload', I actually see the changes :-) Browser caches yay.
danielGe0rG, suggestions for improvments?
danielusing lower case?
goffiyes lower cae
Ge0rGdaniel: I'm trying to come up with a better wording, bear with me.
zinidargh, I don't understand
ziniddoes this precondition magic means publish-options should borrow all options from node-config?
zinidHolger, ah, so we have a bug in ejabberd 🙂
Holgerzinid: We don't comply with the version suggested a few minutes ago on gultsch.de.
Holgerzinid: Not sure I'd call that a bug :-)
Ge0rGdaniel: maybe the following:
> Each form field denotes a precondition to publishing the request. A pub-sub service advertising support for publishing options MUST check each precondition field against the node configuration of the same name, and it MUST reject the publication upon encountering unknown fields.
Holgerzinid: We do comply with the current XEP-0060 wording.
zinidHolger, well I just didn't know what exactly Daniel has added 🙂
Holgerzinid: Ah ok. This exactly is the change he's suggesting.
Holgerzinid: Currently 0060 says that 'access_model' is the only valid publish option.
zinidHolger, yes, yes I got it 😀
Holgerdaniel: Looks good to me.
goffidaniel: patch put aside, I didn't get you're "16:58][daniel] goffi, just create your own form. whats the problem?", what were you suggesing actually? It's a configuration option, I can't put this in a random form.
danielgoffi, well currently (as published by the XSF) you'd have to register a precondition with the registrar. i'm suggesting instead of doing that just define a form
daniellike send a PR to xep60
danieleither way you'd have to go through the xsf
goffidaniel: I'll sure do for the per-item overridding, and other feature I'm willing to standardize, but serial_ids would just be a setting like any service would add, I think it's a bit overkill to create form or go through XSF for every single config option (in the particular case of serial_ids, it could be generally useful so it may make sense)
daniel > I think it's a bit overkill to create form or go through XSF for every single config option
well that's how xep60 works in that regard. none of my PRs change that
danieli don't understand what exactly it is you are trying to do but either you expect a certain reaction from the server then you have to specify it anyway or you don't in which case just don't use publish-options
Ge0rGMaybe it is METADATA?
Ge0rGmarc: so where are we regarding account-invitation?
goffidaniel: I'm willing to specify node configuration atomically on creation, and publish-option is exactly what I need for that. I was worrying abount new options or vendor specific options, but as zinid rightly said I can request node configuration first, so it's alright.
marcGe0rG, if we do not need fancy feature like token revocation I would proceed with my initial approach and add server-side PARS
Ge0rGmarc: you could have an ad-hoc command to revoke a token :P
marcGe0rG, of course :)
Ge0rGmarc: do you want me to write the XEP or to criticize it once you've written? :P
marcBut I think that's too complex and could be added later
Ge0rGmarc: yeah, revocation is out-of-scope
goffiand XEP-0060 doesn't request to register any single config option by the way (which is a good thing)
Ge0rGmarc: I think we have two user stories: "roster invitation with potential account creation" and "explicit account invitation". I think they should have separate ad-hoc commands, but can share wire format.
marcGe0rG, I agree with the first part
marcNot sure if it makes sense to use different commands
marcWe could just change the data form
marcIf the latter is also possible
Ge0rGmarc: ah, right.
Ge0rGmarc: I remember now.
Ge0rGmarc: but then as an admin, you can't create a one-click roster invitation.
Ge0rGmarc: because you always need to send back the JID entry form.
marcOh, *one-click* is the keyword here
Ge0rGmarc: so maybe having separate ad-hoc commands is more useful after all.
Ge0rG"Send invitation" for mortals, "Send account invitation" for admins
marcGe0rG, and you don't like the idea to provide the inviter name?
Ge0rGmarc: no, for two reasons: a) it is hard to validate independently and b) it's adding complexity to the process
Ge0rGmarc: I could send you an invitation that reads "Daniel Gultsch invited you to ..."
marcGe0rG, but it makes the invitation more personal :D
marcGe0rG, of course you can
Ge0rGmarc: you are sending a link to somebody. Make the message containing that link more personal.
Ge0rGIt's nice and fair for the game to crash once you've used up 90% of your data cap.
Steve Killehas left
Steve Killehas left
Steve Killehas joined
zinidmoparisthebest, I mean I don't remember MITM in xmpp
moparisthebestwell if they do it to HTTP :)
moparisthebestcomcast will soon inject <message> stanzas
moparisthebestUPGRADE YOUR MODEM
zinidstill, no a single case of xmpp mitm
Ge0rGReminds me of the good old times of CTCP PING +++ATH0
Steve Killehas left
Steve Killehas joined
edhelasXML ads injection in the messages stanzas for the non-prenium accounts
Ge0rGedhelas: spam filtering as a premium feature.
Ge0rGThe good thing about it: you can cash in from both sides
edhelasthere is so much business to do
Ge0rGI should do a post about spam filtering on yax.im.
ZashJust figure out a way to get users to pay to view ads and you're golden
moparisthebestI mean we had XHTML-IM for that but now it's dead :'(
edhelasJS over Markdown over XMPP messages
ZashRCE as a service
Ge0rGmoparisthebest: JS is horribly inefficient to mine crypto moneys
moparisthebestGe0rG, what about WebAssembly
ZashSurely there are wasm miners already running in your browser
moparisthebestXEP-0400 Arbitrary WebAssembly over XMPP
Ge0rGmoparisthebest: what about it? Does it support OpenCL?
Ge0rGmarc: right, please read my email and then we agree to not use any action at all.
marcGe0rG, okay, give me some minutes but I'm pretty sure I don't like the concept :D
marcGe0rG, okay, I don't see any argumentation in your mail to continue with meaningless "preauth" without action
marcjust because some other actions are poorly specified?
Ge0rGmarc: it's not meaningless. You can see from the JID that it is clearly a contact JID.
Ge0rGmarc: the actions are so underdefined, that yaxim just ignores the action and derives what to do from the other query parameters.
Ge0rGmarc: the only exception I'm using is `join` for MUCs
Ge0rGif there is a `body=`, send a message, otherwise add to roster.
Ge0rGmarc: how does your client handle <xmpp:email@example.com> ?
Ge0rGmarc: depends on what?
marcIf that's my account, if this contact is already in my roster
Ge0rGmarc: it's not your account. Now what will happen?
marcGe0rG, it probably adds you to my roster
Ge0rGmarc: and what happens on <xmpp:firstname.lastname@example.org?subscribe>? On <xmpp:email@example.com?roster>?
Ge0rGmarc: what if I'm on your roster already? Should you open a chat tab instead? Or the "Edit roster item" dialog?
marcGe0rG, The same argumentation applies to your ?preauth... what if you already subsubcribed? Should you open a chat window for the user?
Ge0rGmarc: can we leave out PARS for a moment, please?
marcGe0rG, this has nothing to do with the 'action' concept
Ge0rGmarc: preauth is not an action, it's a query parameter.
marcGe0rG, yes, but what happens needs to be specified
marcIf you use an "action" or just query parameters
Ge0rGmarc: do we want to write an Informational XEP that mandates what happens to a ?roster action if I'm already on your roster?
Ge0rGmarc: nobody cares enough.
Ge0rGmarc: See, Zash was the only one to answer to my question.
marcGe0rG, yes, nobody cares which is why all clients behave differently which sucks, right?
Ge0rGmarc: there is a defined list of actions. None of them works as I would expect.
Ge0rGmarc: you would have to send two URIs with ?roster and ?subscribe for the full features
marcGe0rG, yes, they don't work I know. But that's not an argument against using something like "?invite;token="
ZashI did whatnow?
Ge0rGZash: you responded to a mail in mid 2016.
Ge0rGmarc: But ?invite won't be supported by any clients at all!
marcGe0rG, correct, ad-hoc commands and QR code generation too ;)
marcAll clients need to be adapted for user-invitation
marcGe0rG, okay, all except yaxim
Ge0rGmarc: the good thing about PARS is that it's 100% backwards compatible
marcGe0rG, no client except yaxim implements PARS, correct?
Ge0rGmarc: right, but most clients implement roster subscription.
Ge0rGmarc: and some even support using xmpp: URIs for that.
marcGe0rG, what's the point here? I would like to implement user-invitation and account creation and I'm okay with that fact that clients and servers need to be adapted
marcGe0rG, I can not invite somebody with PARS and Conversations
marcBecause Conversations doesn't support it
marcIt doesn't generate a QR for me
Ge0rGmarc: you can invite a Conversations user with PARS, but you'll have to add them manually afterwards.
marcGe0rG, yes I know but I can not invite somebody else with Conversations
Ge0rGmarc: so what's your point now?
marcGe0rG, clients have to be adapted
Ge0rGmarc: the good thing about PARS is that only the sending client needs to be changed.
marcGe0rG, yes, that's correct
marcBut that's not important for me if I don't use yaxim but Gajim or Conversations or whatever
marcMy point: implementing an URI for this XEP in a client is not a big deal
Ge0rGmarc: yes. First we need two implementations, then we can make it a proper XEP, then people will follow
marcBecause we have to implement a lot more
Ge0rGmarc: I'd go with Zash's suggestion and propose xmpp:firstname.lastname@example.org?add - my client will ignore the action anyway, because the existing actions are all bad.
marcAnd that's why I started to implement PoC in those clients... there should be a working version for all major Clients after this XEP is done
Ge0rGmarc: but in practice, I've chosen not to create a new action type and just to rely on the receiving client to be smart about it when encountering a JID with query parameters.
marcGe0rG, we should focus on more important things than URI definition. We can discuss the URI thing after all the complicated stuff is done
Ge0rGmarc: so how would I add the preauth token into an IBR?
Ge0rGit needs to be indicated at the beginning and not as a form element.
marcdata form as described in my awesome XEP?
Ge0rGmarc: "described"? :P
marcGe0rG, what's wrong about the form element?
Ge0rGmarc: how does the server know that it needs to return a form element and not just do IBR?
marcGe0rG, it returns the form element if user-invitation is supported
Ge0rGmarc: so now all normal IBR clients will stumble upon that?
marcit also returns <required/> if IBR is allowed with token only
Ge0rGmarc: let's say your server supports both normal IBR and preauth, and uses preauth to add the invitee to the roster.
Ge0rGmarc: let's say your server supports both normal IBR and preauth, and uses preauth to add the inviter to the roster.
Ge0rGmarc: now everyone who wants to IBR with you gets a stupid "invite-token" dialog popup
marcGe0rG, that's correct
marcBut that's also a feature because I didn't have to implement much :D
Ge0rGmarc: it's a feature to annoy all future users because you are lazy?
marcGe0rG, no because it's a PoC
Ge0rGmarc: it's great for a PoC, but we need to make it a protocol now
marcGe0rG, yes, tell me your solution
marcGe0rG, probably we need to change all clients for that, right?
marcGe0rG, just tell me your idea :)
Ge0rGmarc: server announces support for IBR <preauth/> in caps. client requests IBR form, receives normal form, sends registration IQ with a <preauth/> element, done.
Ge0rGmarc: server announces support for IBR <preauth/> in caps. client requests IBR form with a special <preauth/> marker, receives form with <preauth/>, sends registration IQ with a <preauth/> element, done.
marcGe0rG, sounds good, you like the term preauth, hm? :D
marcGe0rG, how does this IBR form request for preauth look like?
Ge0rGmarc: I have put some thought into the name; it's short and it indicates what it is without depending on a certain technology