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?
HolgerZash: Sure?
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
Holgergoffi: https://github.com/xsf/xeps/pull/556
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
efrithas left
goffiZash: I will, but it will take time, I am already drowning in work
Alexhas left
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
edhelassorry, misunderstanding
goffifor node it's needed I think we all agree on that
zinidhas left
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
Holgeragrees ;-)
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.
goffiagrees too
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
sonnyhas left
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
jonaswah yes
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?
HolgerYes.
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.
HolgerUh.
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)
danielgoffi, no
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
danielwhy?
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.
Holgerzinid: Exactly.
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
goffi:)
zinidI"m always forgetting this 😉
danieland be done
goffiOK I'm convinced now, I can just request the form
Guushas left
goffiso I'm fully in for daniel's patch
Ge0rGDo we need to bump the namespace version?
danielno
zinidYES
zinid😀
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
jonaswdaniel, wfm
archas left
archas joined
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?
lskdjfhas left
danielusing lower case?
goffiyes lower cae
gofficase
Ge0rGdaniel: I'm trying to come up with a better wording, bear with me.
sonnyhas joined
lskdjfhas left
jjrhhas left
zinidargh, I don't understand
ziniddoes this precondition magic means publish-options should borrow all options from node-config?
Holgerzinid: Yes.
danielzinid: yes
zinidhas left
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.
sonnyhas left
zinidHolger, well I just didn't know what exactly Daniel has added 🙂
Guushas left
Holgerzinid: Ah ok. This exactly is the change he's suggesting.
daniel`<F5>`
Holgerzinid: Currently 0060 says that 'access_model' is the only valid publish option.
zinidHolger, yes, yes I got it 😀
Holgerdaniel: Looks good to me.
sonnyhas joined
sonnyhas left
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.
lskdjfhas left
lskdjfhas left
lskdjfhas left
lskdjfhas joined
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
sonnyhas left
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
jerehas joined
sonnyhas left
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.
sonnyhas joined
sonnyhas joined
jjrhhas left
sonnyhas joined
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
jjrhhas left
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.
marcGe0rG, why?
tim@boese-ban.dehas left
jjrhhas left
Ge0rGmarc: because you always need to send back the JID entry form.
marcOh, *one-click* is the keyword here
zinidhas left
jjrhhas left
Ge0rGmarc: so maybe having separate ad-hoc commands is more useful after all.
Alexhas joined
Ge0rG"Send invitation" for mortals, "Send account invitation" for admins
marcGe0rG, and you don't like the idea to provide the inviter name?
jabberatdemohas joined
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.
marcGe0rG, but I'm okay with it, let's remove the possiblity to provide the inviter name
marcBut I would like to have nice admin options then :p
Ge0rGmarc: also, see §5.4
marcGe0rG, I know
marcGe0rG, but I could copy 5.4 into the new XEP ;)
Ge0rGI can't link to §5.4 because somebody f***ed up the anchor. Bummer.
Ge0rGmarc: technically, it is okay to have an optional name parameter in the xmpp: URI, but it shouldn't require the inviter to input text
Ge0rGI think we need some notion of "screen name", maybe stored in account vcard, and used as the default MUC nickname and for such invitations
marcGe0rG, I wouldn't store it into the URI but yeah
Kevhas left
marcGe0rG, "screen name" independent of this XEP?
Ge0rGmarc: yes
Ge0rGmarc: one day, I'll change yaxim new account creation to ask for a screenname, auto-generate a slugified JID from that and going with a secure auto-created password
marcGe0rG, there is a nickname field in vcard, isn't it?
Ge0rGmarc: I'm not sure screen name == nickname or rather real name
Ge0rGmaybe something in between.
Ge0rGmarc: so if you enter "Crazy Batshit" as your screenname, it would suggest "crazy.batshit@yax.im" as your JID, and fall back to "crazy.batshit.5632@yax.im" if the former is already registered.
marcGe0rG, sounds like a good idea
Ge0rGmarc: of course :P
Ge0rGmarc: I'm obsessed with Easy XMPP for over a year now.
jonaswhow does twitter do that?
marcGe0rG, hopefully easy-invitation will be rolled-out in the near future
marcGe0rG, I'm okay with two commands: user-invitation and "account-creation"
Guushas left
@Alacerhas left
marcuser-invitation allows PARS or account creation with one click
jabberatdemohas left
marcaccount-creation is for admins with some options to generate an account for somebody
marcadmin or other privileged pro-users
jonaswisn’t there an account creation adhoc already?
Ge0rGmarc: user-invitation --> `xmpp:georg@yax.im?preauth=FOOBAR;ibr` --> PARS or account registration
account-creation --> form(username) --> `xmpp://username@server?preauth=FOOBAR`
Ge0rGjonasw: yes, but there you must pre-set a password
jonaswah ok
Ge0rGjonasw: we want to have one-click account setup for the invitee
marcGe0rG, I wouldn't make username required for account-creation but yeah looks good to me
intosihas left
marcAnd probably we need an appropriate URI action parameter
marcNot sure if 'register' or 'roster' should be used
marcOr something like 'invite'
Ge0rGmarc: hm. If you don't need a pre-defined jid for account creation, you can fallback to the PARS URI as well
marcGe0rG, Nobody suggested to use an action name with value nor the name "preauth"
Ge0rGmarc: preauth is not an action, it's a query parameter.
marcGe0rG, and what's the action? nothing?
jcbrandhas left
Ge0rGmarc: yes
jcbrandhas joined
marcThat's not better in my opinion :)
marcI would prefer something like ?invite;preauth=...
marcOr ?invite;token=...
marcIf not even using ?roster
marcWhich makes sense for PARS-only IMO
jonaswis this bikeshedding or actual protocol discussion?
Ge0rGmarc: please respond to my mail from a year ago.
jonaswIf marc doesn’t have archives on his local machine, forging an email which is in fact a reply to that will be massively tricky :)
Ge0rGmarc: technically, the correct format for a query-less URI would be `xmpp:georg@yax.im?;preauth=FOOBAR`
Tobiashas joined
Ge0rGjonasw: I can bounce my original mail, allowing to respond properly.
marcGe0rG, why is this URI query-less?
marcpreauth is part of the query component
Lancehas joined
Ge0rGSorry, "action-less"
Ge0rGmarc: I care more about short URIs and small QR codes.
Ge0rGI'm sure somebody from Council will -1 me on that protocol violation, one day.
marcGe0rG, a few char more or less...
jonaswisn’t that all just conventions
jcbrandhas left
jonaswisn’t that all just convention?
marc+s
Ge0rGjonasw: yeah
Ge0rGmarc: did you know there are some email clients that break links longer than 72 characters?
jonaswhides in shame
Ge0rGmarc: if you are marc_the_nice_guy@jabber.some-important-domain.com and have a long PARS token, you might be out of luck already.
Ge0rGThere's a reason why my XMPP service is yax.im :P
marcGe0rG, tbh no and I wouldn't care about it ^^
Ge0rGmarc: why do you care about the right query action, then?
marcGe0rG, because there is some sort of system for the XMPP URIs and we shouldn't break it IMO
Ge0rGmarc: it's already broken.
marcGe0rG, because of your XEP?
Ge0rGmarc: no, before that. I've written about it being broken. Nobody cared.
marcGe0rG, so let's care from now on ;)
moparisthebestso ejabberd guys, seems like it could be vulnerable to https://robotattack.org/ depending on ciphers chosen, I tested conversations.im and it is safe because it only supports PFS ciphers
Ge0rGmarc: did you read my mail?
moparisthebesterlang is specifically called out as being vulnerable fyi
marcGe0rG, https://mail.jabber.org/pipermail/standards/2016-June/031138.html this one?
Ge0rGmarc: yeah
marcGe0rG, I'll read it later.. I hope it's worth ;)
Ge0rGmarc: Good. We can continue the discussion afterwards, then. Or tomorro.
Ge0rGmarc: Good. We can continue the discussion afterwards, then. Or tomorrow.
jonaswlolwtf, tls is still doing the broken PKCS padding?
jonaswI thought this was just some funny anecdote in the lectures
moparisthebestjonasw, nah it always comes back to bite everyone :P
moparisthebestwho's ejabberd dev in here, zinid ?
jonaswHolger, too
Ge0rGmarc: but it's good that you see the same problems I encountered. You are on the right track ;)
jerehas left
jerehas joined
zinidmoparisthebest, ejabberd doesn't use erlang's native ssl support, it uses openssl
moparisthebestoh, excellent, good to know, thanks zinid
zinidand I'm not sure what this attack is about, I'm not a cryptobitch
moparisthebestyea no need to get bogged down in details, just should be concerned if you are vulnerable or not
jonaswTL;DR: they managed to sign something using facebooks SSL private key they supposedly stole. game over.
zinidwhat's the point in all this TLS stuff, if vulnerabilites are being found every month
zinidonly leads to false sense of protection
moparisthebestdo you have something better? :P
moparisthebestat least it's widely used and studied
Guushas left
zinidmoparisthebest, well, the point is: if I didn't use TLS, I would be vulnerable to heartbleeding, where the whole system can be borked
zinidnot sure what I gain from using TLS in this case
zinid*I wouldn't be vulnerable
jonaswzinid, yeah, tls could use replacement by something much simpler. I think TLS 1.3 is on the right path with dropping support for a lot of legacy things. Not RSA though.
danielhas left
Ge0rGzinid: you get protection against all passive attacks, and also some protection against FSB and NSA
Ge0rGI think we should standardize on Curve25519, because DJB is an awesome m*****f****r
zinidGe0rG, I think FSB and NSA already collected all vulnerabilities of openssl like that one with heartbleeding
moparisthebestyea most of the TLS problems are with legacy support, they realized that and dropped all legacy from TLS 1.3
Ge0rGzinid: heartbleed looked way too much like a plausible-deniability backdoor, yeah.
moparisthebestbut zinid it's a choice between plaintext and no protection all the time, or TLS and best protection possible most of the time
Lancehas left
jonaswmoparisthebest, although the argument that heartbleed may do more damage than plaintexting everything is plausible
zinidmoparisthebest, but I don't remember a single case of MITM attack, but I remember a lot of openssl fuckups
zinidjonasw, exactly
moparisthebestreally? because some networks do MITM as normal matter of business
Ge0rGIt's nice and fair for the game to crash once you've used up 90% of your data cap.
edhelashas joined
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
sezuanhas left
sezuanhas joined
Ge0rGReminds me of the good old times of CTCP PING +++ATH0
mimi89999has joined
archas left
archas joined
archas left
archas joined
Guushas left
uchas joined
Steve Killehas left
danielhas left
danielhas joined
sezuanhas left
sezuanhas joined
archas left
archas joined
goffihas left
Steve Killehas joined
Tobiashas joined
jcbrandhas joined
Guushas left
la|r|mahas joined
jubalhhas joined
lumihas joined
intosihas joined
@Alacerhas left
@Alacerhas joined
lskdjfhas left
lskdjfhas 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
danielhas left
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
danielhas joined
moparisthebestto catch up to the web with all it's features we just need a XEP to send arbitrary javascript to clients so they'll execute it
moparisthebestI mean we had XHTML-IM for that but now it's dead :'(
danielhas left
danielhas joined
edhelasJS over Markdown over XMPP messages
ZashRCE as a service
jjrhhas left
intosihas left
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?
moparisthebestprobably?
Guushas left
archas left
archas joined
sonnyhas joined
archas left
danielhas left
matlaghas left
archas joined
danielhas left
jjrhhas left
jjrhhas left
zinidhas left
ralphmhas left
jcbrandhas left
SamWhitedhas left
debaclehas left
jerehas joined
sonnyhas left
lskdjfhas left
lskdjfhas joined
sonnyhas left
lovetoxhas joined
Ge0rGmarc: right, please read my email and then we agree to not use any action at all.
sonnyhas left
Alexhas left
marcGe0rG, okay, give me some minutes but I'm pretty sure I don't like the concept :D
sonnyhas left
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.
jcbrandhas joined
Ge0rGmarc: the only exception I'm using is `join` for MUCs
Ge0rGif there is a `body=`, send a message, otherwise add to roster.
sonnyhas joined
sonnyhas joined
Ge0rGmarc: how does your client handle <xmpp:georg@yax.im> ?
marcGe0rG, depends
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
archas left
archas joined
Ge0rGmarc: and what happens on <xmpp:georg@yax.im?subscribe>? On <xmpp:georg@yax.im?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
Alexhas joined
Ge0rGmarc: where?
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?
zinidhas left
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
archas left
archas joined
marcGe0rG, yes, they don't work I know. But that's not an argument against using something like "?invite;token="
marcIs it?
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
Ge0rGmarc: no
marcGe0rG, okay, all except yaxim
Ge0rGmarc: NO!
marcGe0rG, why?
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:georg@yax.im?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
marcGe0rG, right?
Ge0rGmarc: right.
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?
marc:(
marc:D
Ge0rGmarc: "described"? :P
marcwell,...
marc:D
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
Ge0rGhas left
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?
Ge0rGmarc: No?
marcGe0rG, just tell me your idea :)
sonnyhas joined
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.
zinidhas left
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
Ge0rGmarc: I suppose this won't break IBR even if the server doesn't support PARS, and it lets the server know that the client intends to do preauth on this IBR
Ge0rGso it can provide different fields in the response
Ge0rGI think this is different from the typical data-forms flow which is intended for the user to enter more data. But I might be wrong and the standards@ ML will correct me.
marcGe0rG, sounds reasonable
Ge0rGmarc: does the above XML look good to you?
marcGe0rG, yes, except for the term "pars"
Ge0rGmarc: in the namespace?
marcyes
Ge0rGcall it `paac` then, for pre-authenticated account creation :P
Ge0rGmarc: I'd be fine with renaming the namespace to urn:xmpp:preauth:0 as well
marchaha
marc:D
Ge0rGEven if it would break existing yaxim installations :P
archas left
marchowever, 'pars' doesn't fit for account creation :)
archas joined
Ge0rGmarc: but pars defines the <preauth/> element, and there is nothing wrong with element reuse :P
marcaahh, that sounds wrong to me ^^
Ge0rGmarc: let's skip over it and solve the next problem.
Ge0rGwe are bike shedding again.
blablahas left
jubalhhas joined
marcGe0rG, correct... I don't see other problems that a server operator may want to limit the number of account creations per user on a time basis or something like that
marcSo we should think about it
Ge0rGmarc: those limitations can be implemented on the server, no need to change the wire format
zinidhas left
marcGe0rG, yes, I just don't like the idea that the server generates different types of tokens when a user hits the limit
Ge0rGmarc: I thought we were over that already?
marcGe0rG, it just bugs me ;)
zinidhas left
Ge0rGmarc: no, I mean that you have different ad-hoc commands for IBR and PARS tokens.
marcGe0rG, Oh, I thought we have IBR+PARS (where IBR might be disabled if the user hits a limit) and IBR-only
archas left
marcGe0rG, so we have PARS and IBR-only?
Ge0rGmarc: we have PARS+IBR and IBR-only
marcGe0rG, correct
marcBut what happens if the user hits a limit?
Ge0rGmarc: I'm not sure what the right solution would be.
marcNo PARS and IBR at all?
marcOr just PARS?
Ge0rGmarc: I think that sending a PARS-only token is better than no token.
Ge0rGmarc: also PARS+IBR doesn't mean all of the receipients are going to IBR immediately
marcGe0rG, yes, probably but it bugs me that the user won't this
Ge0rGmarc: so let's say I try to generate 100 PARS+IBR tokens. Should I be throttled after 50? Or only after 50 of the tokens have been used?
marcups... won't know this
Ge0rGWhat if I don't understand how "Send invitation" works and my first 50 tokens get lost?
marcThat's a good question
Ge0rGmarc: I think the only sensible solution is to limit registrations, not token issuance
Ge0rGmarc: so your 51st friend will get a "this token is invalid" response to IBR
marcGe0rG, wow, but that's strange isn't it?
Ge0rGmarc: is it?
marcYou generate a valid token and somehow it doesn't work although the token isn't expired
Ge0rGmarc: do you have unlimited IBR on your server?
marcGe0rG, I have no IBR at all
Ge0rGmarc: my server will block out after three registrations from the same IP
archas joined
marcGe0rG, I would limit the token generation either based on time or amount or both...
marcEvery token has an expiration date..
Ge0rGmarc: yes, but that's independent of your potential abuse scenario
marcGe0rG, why? A user is not allowed to invite more than X people, for example?
Ge0rGmarc: your ad-hoc command could also return a text field that explains the token validity
Ge0rGmarc: if a user is allowed to invite X people, and he generated X invitations already that all were lost. What then?
Ge0rGmarc: another ad-hoc command to reset pending invitations?
marcGe0rG, well, this depends on server operations anyway. But you could allow token generation after all tokens were expired?
Ge0rGmarc: so the user is blocked for two weeks?
Alexhas left
marcGe0rG, depends on your lifetime?
Ge0rGmarc: yes. Maybe it's two days. But how is that useful?
marcGe0rG, maybe not more then X tokens in a hour?
Ge0rGmarc: maybe, but I still think that you should limit account registrations instead.
Ge0rGmarc: and even if you don't, you can easily link all the new accounts to the initial abuser.
Ge0rGmarc: think about it some more, I'm out for tonight.
marcGe0rG, I don't know. If a token doesn't work and is valid with respect to the expiration date it is confusing and wrong IMO
Ge0rGP.S: protocol design is hard.
marcNo, good protocol design it hard ;)
lumihas joined
la|r|mahas left
Guushas left
moparisthebest[04:11:00 PM] marc: Ge0rG, depends on your lifetime?
[04:11:16 PM] Ge0rG: marc: yes. Maybe it's two days.
moparisthebestwow context matters
efrithas joined
archas left
archas joined
sonnyhas left
Alexhas joined
goffihas joined
danielhas left
jcbrandhas left
efrithas left
jerehas joined
Tobiashas joined
archas left
archas joined
archas left
ralphmhas joined
archas joined
jerehas joined
jerehas joined
jubalhhas joined
matlaghas left
marchas left
moparisthebesthas left
archas left
archas joined
archas left
blablahas left
Bunnehhas left
archas joined
jubalhhas left
Bunnehhas joined
intosihas joined
Bunnehhas left
Bunnehhas joined
Steve Killehas left
lumihas joined
jerehas joined
moparisthebesthas joined
marchas left
jubalhhas joined
zinidhas joined
edhelasis there a proper way today to know if a remote MUC has been disconnected ? (like the service went down…)
intosihas left
intosihas joined
zinidedhelas: ping your nick
Steve Killehas joined
lumihas joined
zinidhas left
mimi89999has joined
Ge0rGAnd pray that none of your clients disconnects or lags in that time
XSF Discussion - 2017-12-12