hi 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
daniel
goffi: it can be both
daniel
The fields are registered. And each field defines if it's is a precondition (= node configuration on publish and enforcement) or an override
goffi
But this are 2 different features. Where the fields are registered (and which fields are registered?) ?
goffi
the XEP is not clear at all about that. The examples only show publication with items, and there is not notion of node creation.
Zash
I don't think autocreation and configuration on publish is a thing that's specified
goffi
I though it was #publish-option (and it was not specified indeed, just in example as far as I remember, like many Pubsub features unfortunately)
Holger
It 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
Holger
Zash: "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."
goffi
yes that how it is implemented in SàT Pubsub
goffi
but "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?
goffi
how to override item, as the text only mention precondition or node configuration on auto-create
goffi
I think I'll write on @standard to discuss that, because it needs to be extremly clear and it is definetely not at the moment.
Holger
goffi: 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.
Zash
Holger: Is that so?
Holger
Zash: Sure?
goffi
Holger: where it is registered ? How can I check it ?
goffi
I'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)
Zash
goffi: I would be happier if it was split in three
goffi: Huh you implemented it. What's the use case?
Holger
goffi: My suggestion would've been to ditch OVERRIDE/METADATA. And if someone needs that feature, re-add it using different syntax.
goffi
Zash: what do you mean split in three ?
Holger
goffi: Isn't the implementation a great PITA when it comes to RSM / MAM access, for example?
goffi
Holger: blog post restricted to some people, similar to Google circles (even if it was done before)
Zash
Three forms, where the form decides what tge fields do, not some registry
goffi
Zash: ah yes, I think it would be better indeed, and in a separate XEP
Holger
goffi: https://github.com/xsf/xeps/pull/556
goffi
I 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)
Zash
goffi: You have my support if you were to draft one
efrithas left
goffi
Zash: I will, but it will take time, I am already drowning in work
Alexhas left
Ge0rG
Yeah, reading that section of 0060 made my head explode. And I'm used to reading protocol specs.
jonasw
I 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
goffi
daniel: 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.
daniel
i don't care very much for metadata either
Zash
jonasw: we were going to split '60 into smaller pieces
goffi
not sure if there is a use case on a per-item basis for metadata. Override there is definitely, but should be separate feature
daniel
i'd be fine with removing it for now and reintroducing it as a seperate form later if someone needs it
edhelas
daniel I do care of metadata actually
goffi
edhelas: on a per-item basis ?
edhelas
ah for items, meh, no
edhelas
sorry, misunderstanding
goffi
for 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 🙂
daniel
removing METADATA entirly changes the wording *a lot*. I'd rather only do that if we agree that this is the right thing
Holgeragrees ;-)
jonasw
if 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
edhelas
daniel in which cases you want to remove metadata ? I'm a bit lost
Ge0rG
I want that whole section burned. It doesn't make any sense.
daniel
edhelas, publish-options. we are talking about publish-options
Ge0rG
Removing metadata and override from the XEP would suffice for me, though.
daniel
removing metadata and override and maybe the ability to register additional fields would make the wording a lot more straight forward
edhelas
yeah registering fields could be quite nice and make it more flexible
sonnyhas left
Holger
Nah. No registering.
goffi
registering is not useful there, and bring a lot of complications
jonasw
no registering, but honoring <required/> so that implementations know when an option is critical?
Holger
Only node config preconditions. That makes it straightforward to understand and implement.
jonasw
that seems like a good compromise and allows later XEPs to extend things
jonasw
ah yes
Holger
And we make it work for all node config options in one go.l
Holger
jonasw: <required/> what?
goffi
that would make my current implementation nearly compliant, just need to check the precondition
jonasw
Holger, publish-options is a Data Form, right?
Holger
Yes.
jonasw
Data Forms specifies the <required/> child for fields
jonasw
users of publish-options could make it clear that a field MUST be understood or the request MUST be rejected with that
jonasw
while other unknown fields may be safely discarded
Holger
The wording already does that.
Holger
Uh.
jonasw
just an idea to open the venue for future extensions without making things too complicated with a registry etc.
goffi
Can'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)
daniel
goffi, no
goffi
daniel: why ?
Holger
Well my suggestion was to reject anything that's not a config option.
daniel
because you have to rely on the fact that they are checked
zinid
unknown fields in practice will mean a client bug in 99% cases
jonasw
Holger, yeah, tbh, I was still thinking about the other use-cases, not Node Config overrides
goffi
but if it's not a configuration options ?
Holger
goffi: What should the publish option do then?
goffi
zinid: no, it can means a new options introduced in new XEP and not handled in current server
zinid
goffi, then it's fine for the server to return error, so a client doesn't expect the option takes effect
goffi
Holger: create node with right config, reject node with bad config, and let in place for unknow config options
daniel
how about something simple as https://gultsch.de/files/xep-0060.html#publisher-publish-options
daniel
exact wording tbd
goffi
daniel: happied with that, but worried about unknow fields
daniel
why?
Holger
goffi: You can't just ignore unknown options because clients probably want to rely on them being set. See the bookmarks XEP, for example.
Holger
goffi: If anything, you could go for jonasw's route and let the client specify whether the option is <required/>. But meh.
zinid
Holger, not to mention that you will get fancy "bug reports" like "I set this knob but it doesn't work!"
daniel
if you ever want to do something else just define your own form
Holger
goffi: I don't quite see the use case of specifying a publish option without caring whether it actually works.
Holger
zinid: Exactly.
moparisthebest
what 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?
Ge0rG
moparisthebest: I'm already waiting for MUC to replace MIX in five years :D
Zash
Ge0rG: Wow, aren't you the optimist
zinid
MUC to replace MIX?
goffi
Holger: 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.
Ge0rG
zinid: yes, because MIX is too complicated.
zinid
Ge0rG, ah, agreed
zinid
no way I implement it in ejabberd
daniel
goffi, it will already fail with the current wording
daniel
because serial_ids is not registered
Zash
MIX looks unlikely to be implemented in Prosody either atm
daniel
you can not just invent shit without registering it
goffi
daniel: yes I didn't say the opposite, I just say the current wording and one in patch are not future-proof
zinid
goffi, can't you just request the form to check what fields are supported?
goffi
zinid: ah yes good point
daniel
goffi, just create your own form. whats the problem?
goffi
zinid: but need one more request
Holger
goffi: And it buys you a clear spec with defined behavior.
zinid
goffi, ah, you client developers are afraid of requests 😀
daniel
create a form name it publish-sequential-enforcing-agency-visual-studio-powered
goffi
:)
zinid
I"m always forgetting this 😉
daniel
and be done
goffi
OK I'm convinced now, I can just request the form
Guushas left
goffi
so I'm fully in for daniel's patch
Ge0rG
Do we need to bump the namespace version?
daniel
no
zinid
YES
zinid
😀
edhelas
just bump by .05 and we're good
daniel
anyone has any suggestions on improving the wording based on https://gultsch.de/files/xep-0060.html#publisher-publish-options
jonasw
daniel, wfm
archas left
archas joined
daniel
Ge0rG, is that wording fine with you?
daniel
you complained about the entire section before
Ge0rG
daniel: 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
Holger
Hah, after pressing 'reload', I actually see the changes :-) Browser caches yay.
daniel
Ge0rG, suggestions for improvments?
lskdjfhas left
daniel
using lower case?
goffi
yes lower cae
goffi
case
Ge0rG
daniel: I'm trying to come up with a better wording, bear with me.
sonnyhas joined
lskdjfhas left
jjrhhas left
zinid
argh, I don't understand
zinid
does this precondition magic means publish-options should borrow all options from node-config?
Holger
zinid: Yes.
daniel
zinid: yes
zinidhas left
zinid
Holger, ah, so we have a bug in ejabberd 🙂
Holger
zinid: We don't comply with the version suggested a few minutes ago on gultsch.de.
Holger
zinid: Not sure I'd call that a bug :-)
Ge0rG
daniel: 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.
Holger
zinid: We do comply with the current XEP-0060 wording.
sonnyhas left
zinid
Holger, well I just didn't know what exactly Daniel has added 🙂
Guushas left
Holger
zinid: Ah ok. This exactly is the change he's suggesting.
daniel
`<F5>`
Holger
zinid: Currently 0060 says that 'access_model' is the only valid publish option.
zinid
Holger, yes, yes I got it 😀
Holger
daniel: Looks good to me.
sonnyhas joined
sonnyhas left
goffi
daniel: 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
daniel
goffi, 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
daniel
like send a PR to xep60
sonnyhas left
daniel
either way you'd have to go through the xsf
goffi
daniel: 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
daniel
i 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
Ge0rG
Maybe it is METADATA?
Ge0rG
marc: so where are we regarding account-invitation?
goffi
daniel: 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
marc
Ge0rG, if we do not need fancy feature like token revocation I would proceed with my initial approach and add server-side PARS
Ge0rG
marc: you could have an ad-hoc command to revoke a token :P
jjrhhas left
marc
Ge0rG, of course :)
Ge0rG
marc: do you want me to write the XEP or to criticize it once you've written? :P
marc
But I think that's too complex and could be added later
Ge0rG
marc: yeah, revocation is out-of-scope
goffi
and XEP-0060 doesn't request to register any single config option by the way (which is a good thing)
Ge0rG
marc: 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.
marc
Ge0rG, I agree with the first part
marc
Not sure if it makes sense to use different commands
marc
We could just change the data form
marc
If the latter is also possible
Ge0rG
marc: ah, right.
Ge0rG
marc: I remember now.
Ge0rG
marc: but then as an admin, you can't create a one-click roster invitation.
marc
Ge0rG, why?
tim@boese-ban.dehas left
jjrhhas left
Ge0rG
marc: because you always need to send back the JID entry form.
marc
Oh, *one-click* is the keyword here
zinidhas left
jjrhhas left
Ge0rG
marc: so maybe having separate ad-hoc commands is more useful after all.
Alexhas joined
Ge0rG
"Send invitation" for mortals, "Send account invitation" for admins
marc
Ge0rG, and you don't like the idea to provide the inviter name?
jabberatdemohas joined
Ge0rG
marc: no, for two reasons: a) it is hard to validate independently and b) it's adding complexity to the process
Ge0rG
marc: I could send you an invitation that reads "Daniel Gultsch invited you to ..."
marc
Ge0rG, but it makes the invitation more personal :D
marc
Ge0rG, of course you can
Ge0rG
marc: you are sending a link to somebody. Make the message containing that link more personal.
Ge0rG, but I'm okay with it, let's remove the possiblity to provide the inviter name
marc
But I would like to have nice admin options then :p
Ge0rG
marc: also, see §5.4
marc
Ge0rG, I know
marc
Ge0rG, but I could copy 5.4 into the new XEP ;)
Ge0rG
I can't link to §5.4 because somebody f***ed up the anchor. Bummer.
Ge0rG
marc: technically, it is okay to have an optional name parameter in the xmpp: URI, but it shouldn't require the inviter to input text
Ge0rG
I think we need some notion of "screen name", maybe stored in account vcard, and used as the default MUC nickname and for such invitations
marc
Ge0rG, I wouldn't store it into the URI but yeah
Kevhas left
marc
Ge0rG, "screen name" independent of this XEP?
Ge0rG
marc: yes
Ge0rG
marc: 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
marc
Ge0rG, there is a nickname field in vcard, isn't it?
Ge0rG
marc: I'm not sure screen name == nickname or rather real name
Ge0rG
maybe something in between.
Ge0rG
marc: 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.
marc
Ge0rG, sounds like a good idea
Ge0rG
marc: of course :P
Ge0rG
marc: I'm obsessed with Easy XMPP for over a year now.
jonasw
how does twitter do that?
marc
Ge0rG, hopefully easy-invitation will be rolled-out in the near future
marc
Ge0rG, I'm okay with two commands: user-invitation and "account-creation"
Guushas left
@Alacerhas left
marc
user-invitation allows PARS or account creation with one click
jabberatdemohas left
marc
account-creation is for admins with some options to generate an account for somebody
marc
admin or other privileged pro-users
jonasw
isn’t there an account creation adhoc already?
Ge0rG
marc: user-invitation --> `xmpp:georg@yax.im?preauth=FOOBAR;ibr` --> PARS or account registration
account-creation --> form(username) --> `xmpp://username@server?preauth=FOOBAR`
Ge0rG
jonasw: yes, but there you must pre-set a password
jonasw
ah ok
Ge0rG
jonasw: we want to have one-click account setup for the invitee
marc
Ge0rG, I wouldn't make username required for account-creation but yeah looks good to me
intosihas left
marc
And probably we need an appropriate URI action parameter
marc
Not sure if 'register' or 'roster' should be used
marc
Or something like 'invite'
Ge0rG
marc: hm. If you don't need a pre-defined jid for account creation, you can fallback to the PARS URI as well
marc: did you know there are some email clients that break links longer than 72 characters?
jonaswhides in shame
Ge0rG
marc: 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.
Ge0rG
There's a reason why my XMPP service is yax.im :P
marc
Ge0rG, tbh no and I wouldn't care about it ^^
Ge0rG
marc: why do you care about the right query action, then?
marc
Ge0rG, because there is some sort of system for the XMPP URIs and we shouldn't break it IMO
Ge0rG
marc: it's already broken.
marc
Ge0rG, because of your XEP?
Ge0rG
marc: no, before that. I've written about it being broken. Nobody cared.
marc
Ge0rG, so let's care from now on ;)
moparisthebest
so 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
Ge0rG
marc: did you read my mail?
moparisthebest
erlang is specifically called out as being vulnerable fyi
marc
Ge0rG, https://mail.jabber.org/pipermail/standards/2016-June/031138.html this one?
Ge0rG
marc: yeah
marc
Ge0rG, I'll read it later.. I hope it's worth ;)
Ge0rG
marc: Good. We can continue the discussion afterwards, then. Or tomorro.✎
Ge0rG
marc: Good. We can continue the discussion afterwards, then. Or tomorrow. ✏
jonasw
lolwtf, tls is still doing the broken PKCS padding?
jonasw
I thought this was just some funny anecdote in the lectures
moparisthebest
jonasw, nah it always comes back to bite everyone :P
moparisthebest
who's ejabberd dev in here, zinid ?
jonasw
Holger, too
Ge0rG
marc: but it's good that you see the same problems I encountered. You are on the right track ;)
jerehas left
jerehas joined
zinid
moparisthebest, ejabberd doesn't use erlang's native ssl support, it uses openssl
moparisthebest
oh, excellent, good to know, thanks zinid
zinid
and I'm not sure what this attack is about, I'm not a cryptobitch
moparisthebest
yea no need to get bogged down in details, just should be concerned if you are vulnerable or not
jonasw
TL;DR: they managed to sign something using facebooks SSL private key they supposedly stole. game over.
zinid
what's the point in all this TLS stuff, if vulnerabilites are being found every month
zinid
only leads to false sense of protection
moparisthebest
do you have something better? :P
moparisthebest
at least it's widely used and studied
Guushas left
zinid
moparisthebest, well, the point is: if I didn't use TLS, I would be vulnerable to heartbleeding, where the whole system can be borked
zinid
not sure what I gain from using TLS in this case
zinid
*I wouldn't be vulnerable
jonasw
zinid, 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
Ge0rG
zinid: you get protection against all passive attacks, and also some protection against FSB and NSA
Ge0rG
I think we should standardize on Curve25519, because DJB is an awesome m*****f****r
zinid
Ge0rG, I think FSB and NSA already collected all vulnerabilities of openssl like that one with heartbleeding
moparisthebest
yea most of the TLS problems are with legacy support, they realized that and dropped all legacy from TLS 1.3
Ge0rG
zinid: heartbleed looked way too much like a plausible-deniability backdoor, yeah.
moparisthebest
but 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
jonasw
moparisthebest, although the argument that heartbleed may do more damage than plaintexting everything is plausible
zinid
moparisthebest, but I don't remember a single case of MITM attack, but I remember a lot of openssl fuckups
zinid
jonasw, exactly
moparisthebest
really? because some networks do MITM as normal matter of business
they even RFC'd it https://tools.ietf.org/html/rfc6108
Ge0rG
moparisthebest: I just was going to paste that.
Ge0rG
It's especially awesome for remote APIs
moparisthebest
I bet
moparisthebest
tl;dr everything should be TLS all the time, no exceptions :'(
Ge0rG
https://news.ycombinator.com/item?id=15892282 ;)
edhelashas left
Ge0rG
It'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
zinid
moparisthebest, I mean I don't remember MITM in xmpp
moparisthebest
well if they do it to HTTP :)
moparisthebest
comcast will soon inject <message> stanzas
moparisthebest
UPGRADE YOUR MODEM
zinid
still, no a single case of xmpp mitm
sezuanhas left
sezuanhas joined
Ge0rG
Reminds 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
edhelas
XML ads injection in the messages stanzas for the non-prenium accounts
Ge0rG
edhelas: spam filtering as a premium feature.
Ge0rG
The good thing about it: you can cash in from both sides
edhelas
there is so much business to do
danielhas left
Ge0rG
I should do a post about spam filtering on yax.im.
Zash
Just figure out a way to get users to pay to view ads and you're golden
danielhas joined
moparisthebest
to 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
moparisthebest
I mean we had XHTML-IM for that but now it's dead :'(
danielhas left
danielhas joined
edhelas
JS over Markdown over XMPP messages
Zash
RCE as a service
jjrhhas left
intosihas left
Ge0rG
moparisthebest: JS is horribly inefficient to mine crypto moneys
moparisthebest
Ge0rG, what about WebAssembly
Zash
Surely there are wasm miners already running in your browser
moparisthebest
XEP-0400 Arbitrary WebAssembly over XMPP
Ge0rG
moparisthebest: what about it? Does it support OpenCL?
moparisthebest
probably?
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
Ge0rG
marc: right, please read my email and then we agree to not use any action at all.
sonnyhas left
Alexhas left
marc
Ge0rG, okay, give me some minutes but I'm pretty sure I don't like the concept :D
sonnyhas left
marc
Ge0rG, okay, I don't see any argumentation in your mail to continue with meaningless "preauth" without action
marc
just because some other actions are poorly specified?
Ge0rG
marc: it's not meaningless. You can see from the JID that it is clearly a contact JID.
Ge0rG
marc: the actions are so underdefined, that yaxim just ignores the action and derives what to do from the other query parameters.
jcbrandhas joined
Ge0rG
marc: the only exception I'm using is `join` for MUCs
Ge0rG
if there is a `body=`, send a message, otherwise add to roster.
sonnyhas joined
sonnyhas joined
Ge0rG
marc: how does your client handle <xmpp:georg@yax.im> ?
marc
Ge0rG, depends
Ge0rG
marc: depends on what?
marc
If that's my account, if this contact is already in my roster
Ge0rG
marc: it's not your account. Now what will happen?
marc
Ge0rG, it probably adds you to my roster
archas left
archas joined
Ge0rG
marc: and what happens on <xmpp:georg@yax.im?subscribe>? On <xmpp:georg@yax.im?roster>?
Ge0rG
marc: what if I'm on your roster already? Should you open a chat tab instead? Or the "Edit roster item" dialog?
marc
Ge0rG, The same argumentation applies to your ?preauth... what if you already subsubcribed? Should you open a chat window for the user?
Ge0rG
marc: can we leave out PARS for a moment, please?
marc
Ge0rG, this has nothing to do with the 'action' concept
Ge0rG
marc: preauth is not an action, it's a query parameter.
marc
Ge0rG, yes, but what happens needs to be specified
marc
If you use an "action" or just query parameters
Alexhas joined
Ge0rG
marc: where?
Ge0rG
marc: do we want to write an Informational XEP that mandates what happens to a ?roster action if I'm already on your roster?
Ge0rG
marc: nobody cares enough.
Ge0rG
marc: See, Zash was the only one to answer to my question.
marc
Ge0rG, yes, nobody cares which is why all clients behave differently which sucks, right?
zinidhas left
Ge0rG
marc: there is a defined list of actions. None of them works as I would expect.
Ge0rG
marc: you would have to send two URIs with ?roster and ?subscribe for the full features
archas left
archas joined
marc
Ge0rG, yes, they don't work I know. But that's not an argument against using something like "?invite;token="
marc
Is it?
Zash
I did whatnow?
Ge0rG
Zash: you responded to a mail in mid 2016.
Ge0rG
marc: But ?invite won't be supported by any clients at all!
marc
Ge0rG, correct, ad-hoc commands and QR code generation too ;)
marc
All clients need to be adapted for user-invitation
Ge0rG
marc: no
marc
Ge0rG, okay, all except yaxim
Ge0rG
marc: NO!
marc
Ge0rG, why?
Ge0rG
marc: the good thing about PARS is that it's 100% backwards compatible
marc
Ge0rG, no client except yaxim implements PARS, correct?
Ge0rG
marc: right, but most clients implement roster subscription.
Ge0rG
marc: and some even support using xmpp: URIs for that.
marc
Ge0rG, 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
marc
Ge0rG, I can not invite somebody with PARS and Conversations
marc
Because Conversations doesn't support it
marc
It doesn't generate a QR for me
Ge0rG
marc: you can invite a Conversations user with PARS, but you'll have to add them manually afterwards.
marc
Ge0rG, yes I know but I can not invite somebody else with Conversations
Ge0rG
marc: so what's your point now?
marc
Ge0rG, clients have to be adapted
Ge0rG
marc: the good thing about PARS is that only the sending client needs to be changed.
marc
Ge0rG, yes, that's correct
marc
But that's not important for me if I don't use yaxim but Gajim or Conversations or whatever
marc
My point: implementing an URI for this XEP in a client is not a big deal
Ge0rG
marc: yes. First we need two implementations, then we can make it a proper XEP, then people will follow
marc
Because we have to implement a lot more
Ge0rG
marc: 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.
marc
And 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
Ge0rG
marc: 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.
marc
Ge0rG, we should focus on more important things than URI definition. We can discuss the URI thing after all the complicated stuff is done
marc
Ge0rG, right?
Ge0rG
marc: right.
Ge0rG
marc: so how would I add the preauth token into an IBR?
Ge0rG
it needs to be indicated at the beginning and not as a form element.
marc
data form as described in my awesome XEP?
marc
:(
marc
:D
Ge0rG
marc: "described"? :P
marc
well,...
marc
:D
marc
Ge0rG, what's wrong about the form element?
Ge0rG
marc: how does the server know that it needs to return a form element and not just do IBR?
marc
Ge0rG, it returns the form element if user-invitation is supported
Ge0rG
marc: so now all normal IBR clients will stumble upon that?
marc
it also returns <required/> if IBR is allowed with token only
Ge0rGhas left
Ge0rG
marc: let's say your server supports both normal IBR and preauth, and uses preauth to add the invitee to the roster.✎
Ge0rG
marc: let's say your server supports both normal IBR and preauth, and uses preauth to add the inviter to the roster. ✏
Ge0rG
marc: now everyone who wants to IBR with you gets a stupid "invite-token" dialog popup
marc
Ge0rG, that's correct
marc
But that's also a feature because I didn't have to implement much :D
Ge0rG
marc: it's a feature to annoy all future users because you are lazy?
marc
Ge0rG, no because it's a PoC
Ge0rG
marc: it's great for a PoC, but we need to make it a protocol now
marc
Ge0rG, yes, tell me your solution
marc
Ge0rG, probably we need to change all clients for that, right?
Ge0rG
marc: No?
marc
Ge0rG, just tell me your idea :)
sonnyhas joined
Ge0rG
marc: server announces support for IBR <preauth/> in caps. client requests IBR form, receives normal form, sends registration IQ with a <preauth/> element, done.
Ge0rG
marc: 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
marc
Ge0rG, sounds good, you like the term preauth, hm? :D
marc
Ge0rG, how does this IBR form request for preauth look like?
Ge0rG
marc: I have put some thought into the name; it's short and it indicates what it is without depending on a certain technology
marc: 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
Ge0rG
so it can provide different fields in the response
Ge0rG
I 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.
marc
Ge0rG, sounds reasonable
Ge0rG
marc: does the above XML look good to you?
marc
Ge0rG, yes, except for the term "pars"
Ge0rG
marc: in the namespace?
marc
yes
Ge0rG
call it `paac` then, for pre-authenticated account creation :P
Ge0rG
marc: I'd be fine with renaming the namespace to urn:xmpp:preauth:0 as well
marc
haha
marc
:D
Ge0rG
Even if it would break existing yaxim installations :P
archas left
marc
however, 'pars' doesn't fit for account creation :)
archas joined
Ge0rG
marc: but pars defines the <preauth/> element, and there is nothing wrong with element reuse :P
marc
aahh, that sounds wrong to me ^^
Ge0rG
marc: let's skip over it and solve the next problem.
Ge0rG
we are bike shedding again.
blablahas left
jubalhhas joined
marc
Ge0rG, 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
marc
So we should think about it
Ge0rG
marc: those limitations can be implemented on the server, no need to change the wire format
zinidhas left
marc
Ge0rG, yes, I just don't like the idea that the server generates different types of tokens when a user hits the limit
Ge0rG
marc: I thought we were over that already?
marc
Ge0rG, it just bugs me ;)
zinidhas left
Ge0rG
marc: no, I mean that you have different ad-hoc commands for IBR and PARS tokens.
marc
Ge0rG, Oh, I thought we have IBR+PARS (where IBR might be disabled if the user hits a limit) and IBR-only
archas left
marc
Ge0rG, so we have PARS and IBR-only?
Ge0rG
marc: we have PARS+IBR and IBR-only
marc
Ge0rG, correct
marc
But what happens if the user hits a limit?
Ge0rG
marc: I'm not sure what the right solution would be.
marc
No PARS and IBR at all?
marc
Or just PARS?
Ge0rG
marc: I think that sending a PARS-only token is better than no token.
Ge0rG
marc: also PARS+IBR doesn't mean all of the receipients are going to IBR immediately
marc
Ge0rG, yes, probably but it bugs me that the user won't this
Ge0rG
marc: 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?
marc
ups... won't know this
Ge0rG
What if I don't understand how "Send invitation" works and my first 50 tokens get lost?
marc
That's a good question
Ge0rG
marc: I think the only sensible solution is to limit registrations, not token issuance
Ge0rG
marc: so your 51st friend will get a "this token is invalid" response to IBR
marc
Ge0rG, wow, but that's strange isn't it?
Ge0rG
marc: is it?
marc
You generate a valid token and somehow it doesn't work although the token isn't expired
Ge0rG
marc: do you have unlimited IBR on your server?
marc
Ge0rG, I have no IBR at all
Ge0rG
marc: my server will block out after three registrations from the same IP
archas joined
marc
Ge0rG, I would limit the token generation either based on time or amount or both...
marc
Every token has an expiration date..
Ge0rG
marc: yes, but that's independent of your potential abuse scenario
marc
Ge0rG, why? A user is not allowed to invite more than X people, for example?
Ge0rG
marc: your ad-hoc command could also return a text field that explains the token validity
Ge0rG
marc: if a user is allowed to invite X people, and he generated X invitations already that all were lost. What then?
Ge0rG
marc: another ad-hoc command to reset pending invitations?
marc
Ge0rG, well, this depends on server operations anyway. But you could allow token generation after all tokens were expired?
Ge0rG
marc: so the user is blocked for two weeks?
Alexhas left
marc
Ge0rG, depends on your lifetime?
Ge0rG
marc: yes. Maybe it's two days. But how is that useful?
marc
Ge0rG, maybe not more then X tokens in a hour?
Ge0rG
marc: maybe, but I still think that you should limit account registrations instead.
Ge0rG
marc: and even if you don't, you can easily link all the new accounts to the initial abuser.
Ge0rG
marc: think about it some more, I'm out for tonight.
marc
Ge0rG, 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
Ge0rG
P.S: protocol design is hard.
marc
No, 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.
moparisthebest
wow 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
edhelas
is there a proper way today to know if a remote MUC has been disconnected ? (like the service went down…)
intosihas left
intosihas joined
zinid
edhelas: ping your nick
Steve Killehas joined
lumihas joined
zinidhas left
mimi89999has joined
Ge0rG
And pray that none of your clients disconnects or lags in that time