XSF Discussion - 2017-12-12

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

goffi: it can be both

The fields are registered. And each field defines if it's is a precondition (= node configuration on publish and enforcement) or an override

But this are 2 different features. Where the fields are registered (and which fields are registered?) ?

the XEP is not clear at all about that. The examples only show publication with items, and there is not notion of node creation.

I don't think autocreation and configuration on publish is a thing that's specified

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)

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

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."

yes that how it is implemented in SàT Pubsub

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?

how to override item, as the text only mention precondition or node configuration on auto-create

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.

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.

Holger: Is that so?

Zash: Sure?

Holger: where it is registered ? How can I check it ?

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)

goffi: I would be happier if it was split in three

goffi: https://xmpp.org/extensions/xep-0060.html#registrar-formtypes-publish

goffi: Huh you implemented it. What's the use case?

goffi: My suggestion would've been to ditch OVERRIDE/METADATA. And if someone needs that feature, re-add it using different syntax.

Zash: what do you mean split in three ?

goffi: Isn't the implementation a great PITA when it comes to RSM / MAM access, for example?

Holger: blog post restricted to some people, similar to Google circles (even if it was done before)

Three forms, where the form decides what tge fields do, not some registry

Zash: ah yes, I think it would be better indeed, and in a separate XEP

goffi: https://github.com/xsf/xeps/pull/556

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)

goffi: You have my support if you were to draft one

Zash: I will, but it will take time, I am already drowning in work

Yeah, reading that section of 0060 made my head explode. And I'm used to reading protocol specs.

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

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.

i don't care very much for metadata either

jonasw: we were going to split '60 into smaller pieces

not sure if there is a use case on a per-item basis for metadata. Override there is definitely, but should be separate feature

i'd be fine with removing it for now and reintroducing it as a seperate form later if someone needs it

daniel I do care of metadata actually

edhelas: on a per-item basis ?

ah for items, meh, no

sorry, misunderstanding

for node it's needed I think we all agree on that

> ideally english mother tongue They tend to use some rare wording which is only possible to translate with a dictionary 🙂

removing METADATA entirly changes the wording *a lot*. I'd rather only do that if we agree that this is the right thing

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.

daniel in which cases you want to remove metadata ? I'm a bit lost

I want that whole section burned. It doesn't make any sense.

edhelas, publish-options. we are talking about publish-options

Removing metadata and override from the XEP would suffice for me, though.

removing metadata and override and maybe the ability to register additional fields would make the wording a lot more straight forward

yeah registering fields could be quite nice and make it more flexible

Nah. No registering.

registering is not useful there, and bring a lot of complications

no registering, but honoring <required/> so that implementations know when an option is critical?

Only node config preconditions. That makes it straightforward to understand and implement.

that seems like a good compromise and allows later XEPs to extend things

ah yes

And we make it work for all node config options in one go.l

jonasw: <required/> what?

that would make my current implementation nearly compliant, just need to check the precondition

Holger, publish-options is a Data Form, right?

Yes.

Data Forms specifies the <required/> child for fields

users of publish-options could make it clear that a field MUST be understood or the request MUST be rejected with that

while other unknown fields may be safely discarded

The wording already does that.

Uh.

just an idea to open the venue for future extensions without making things too complicated with a registry etc.

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)

goffi, no

daniel: why ?

Well my suggestion was to reject anything that's not a config option.

because you have to rely on the fact that they are checked

unknown fields in practice will mean a client bug in 99% cases

Holger, yeah, tbh, I was still thinking about the other use-cases, not Node Config overrides

but if it's not a configuration options ?

goffi: What should the publish option do then?

zinid: no, it can means a new options introduced in new XEP and not handled in current server

goffi, then it's fine for the server to return error, so a client doesn't expect the option takes effect

Holger: create node with right config, reject node with bad config, and let in place for unknow config options

how about something simple as https://gultsch.de/files/xep-0060.html#publisher-publish-options

exact wording tbd

daniel: happied with that, but worried about unknow fields

why?

goffi: You can't just ignore unknown options because clients probably want to rely on them being set. See the bookmarks XEP, for example.

goffi: If anything, you could go for jonasw's route and let the client specify whether the option is <required/>. But meh.

Holger, not to mention that you will get fancy "bug reports" like "I set this knob but it doesn't work!"

if you ever want to do something else just define your own form

goffi: I don't quite see the use case of specifying a publish option without caring whether it actually works.

zinid: Exactly.

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?

moparisthebest: I'm already waiting for MUC to replace MIX in five years :D

Ge0rG: Wow, aren't you the optimist

MUC to replace MIX?

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.

zinid: yes, because MIX is too complicated.

Ge0rG, ah, agreed

no way I implement it in ejabberd

goffi, it will already fail with the current wording

because serial_ids is not registered

MIX looks unlikely to be implemented in Prosody either atm

you can not just invent shit without registering it

daniel: yes I didn't say the opposite, I just say the current wording and one in patch are not future-proof

goffi, can't you just request the form to check what fields are supported?

zinid: ah yes good point

goffi, just create your own form. whats the problem?

zinid: but need one more request

goffi: And it buys you a clear spec with defined behavior.

goffi, ah, you client developers are afraid of requests 😀

create a form name it publish-sequential-enforcing-agency-visual-studio-powered

:)

I"m always forgetting this 😉

and be done

OK I'm convinced now, I can just request the form

so I'm fully in for daniel's patch

Do we need to bump the namespace version?

no

YES

😀

just bump by .05 and we're good

anyone has any suggestions on improving the wording based on https://gultsch.de/files/xep-0060.html#publisher-publish-options

daniel, wfm

Ge0rG, is that wording fine with you?

you complained about the entire section before

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

Hah, after pressing 'reload', I actually see the changes :-) Browser caches yay.

Ge0rG, suggestions for improvments?

using lower case?

yes lower cae

case

daniel: I'm trying to come up with a better wording, bear with me.

argh, I don't understand

does this precondition magic means publish-options should borrow all options from node-config?

zinid: Yes.

zinid: yes

Holger, ah, so we have a bug in ejabberd 🙂

zinid: We don't comply with the version suggested a few minutes ago on gultsch.de.

zinid: Not sure I'd call that a bug :-)

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.

zinid: We do comply with the current XEP-0060 wording.

Holger, well I just didn't know what exactly Daniel has added 🙂

zinid: Ah ok. This exactly is the change he's suggesting.

`<F5>`

zinid: Currently 0060 says that 'access_model' is the only valid publish option.

Holger, yes, yes I got it 😀

daniel: Looks good to me.

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.

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

like send a PR to xep60

either way you'd have to go through the xsf

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)

> 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

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

Maybe it is METADATA?

marc: so where are we regarding account-invitation?

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.

Ge0rG, if we do not need fancy feature like token revocation I would proceed with my initial approach and add server-side PARS

marc: you could have an ad-hoc command to revoke a token :P

Ge0rG, of course :)

marc: do you want me to write the XEP or to criticize it once you've written? :P

But I think that's too complex and could be added later

marc: yeah, revocation is out-of-scope

and XEP-0060 doesn't request to register any single config option by the way (which is a good thing)

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.

Ge0rG, I agree with the first part

Not sure if it makes sense to use different commands

We could just change the data form

If the latter is also possible

marc: ah, right.

marc: I remember now.

marc: but then as an admin, you can't create a one-click roster invitation.

Ge0rG, why?

marc: because you always need to send back the JID entry form.

Oh, *one-click* is the keyword here

marc: so maybe having separate ad-hoc commands is more useful after all.

"Send invitation" for mortals, "Send account invitation" for admins

Ge0rG, and you don't like the idea to provide the inviter name?

marc: no, for two reasons: a) it is hard to validate independently and b) it's adding complexity to the process

marc: I could send you an invitation that reads "Daniel Gultsch invited you to ..."

Ge0rG, but it makes the invitation more personal :D

Ge0rG, of course you can

marc: you are sending a link to somebody. Make the message containing that link more personal.

xmpp:romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;name=Romeo+Montague

a) is not a good argument anymore ;)

marc: xmpp:romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;name=Tybalt+Capulet

marc: what now?

Ge0rG, that's an example of your PARS XEP

that's the point ;)

marc: that's been almost a year :P

Ge0rG, :P

Ge0rG, but I'm okay with it, let's remove the possiblity to provide the inviter name

But I would like to have nice admin options then :p

marc: also, see §5.4

Ge0rG, I know

Ge0rG, but I could copy 5.4 into the new XEP ;)

I can't link to §5.4 because somebody f***ed up the anchor. Bummer.

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

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

Ge0rG, I wouldn't store it into the URI but yeah

Ge0rG, "screen name" independent of this XEP?

marc: yes

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

Ge0rG, there is a nickname field in vcard, isn't it?

marc: I'm not sure screen name == nickname or rather real name

maybe something in between.

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.

Ge0rG, sounds like a good idea

marc: of course :P

marc: I'm obsessed with Easy XMPP for over a year now.

how does twitter do that?

Ge0rG, hopefully easy-invitation will be rolled-out in the near future

Ge0rG, I'm okay with two commands: user-invitation and "account-creation"

user-invitation allows PARS or account creation with one click

account-creation is for admins with some options to generate an account for somebody

admin or other privileged pro-users

isn’t there an account creation adhoc already?

marc: user-invitation --> `xmpp:georg@yax.im?preauth=FOOBAR;ibr` --> PARS or account registration account-creation --> form(username) --> `xmpp://username@server?preauth=FOOBAR`

jonasw: yes, but there you must pre-set a password

ah ok

jonasw: we want to have one-click account setup for the invitee

Ge0rG, I wouldn't make username required for account-creation but yeah looks good to me

And probably we need an appropriate URI action parameter

Not sure if 'register' or 'roster' should be used

Or something like 'invite'

marc: hm. If you don't need a pre-defined jid for account creation, you can fallback to the PARS URI as well

marc: https://xmpp.org/registrar/querytypes.html#register

marc: so it would be `xmpp://username@server?register;preauth=FOOBAR`

Ge0rG, yeah but maybe you have more options on account-creation and it doesn't cost anything to make this field optional

Ge0rG, yes, for account-creation ?register make sense

Ge0rG, not sure if it makes sense for PARS

because it doesn't lead necessarily to account creation

marc: it doesn't.

Ge0rG, yes :)

But preauth is not a good action name IMO

marc: I'd leave away the action name from PARS links for brevity.

marc: there are actions for "roster" and "subscribe". Both are vaguely wrong.

Ge0rG, I know but 'preauth' could be anything

And to be compatible with other action names I would like to use an other name

And actually action name don't have a value

+s

marc: https://mail.jabber.org/pipermail/standards/2016-June/031138.html

Ge0rG, Nobody suggested to use an action name with value nor the name "preauth"

marc: preauth is not an action, it's a query parameter.

Ge0rG, and what's the action? nothing?

marc: yes

That's not better in my opinion :)

I would prefer something like ?invite;preauth=...

Or ?invite;token=...

If not even using ?roster

Which makes sense for PARS-only IMO

is this bikeshedding or actual protocol discussion?

marc: please respond to my mail from a year ago.

If marc doesn’t have archives on his local machine, forging an email which is in fact a reply to that will be massively tricky :)

marc: technically, the correct format for a query-less URI would be `xmpp:georg@yax.im?;preauth=FOOBAR`

jonasw: I can bounce my original mail, allowing to respond properly.

Ge0rG, why is this URI query-less?

preauth is part of the query component

Sorry, "action-less"

marc: I care more about short URIs and small QR codes.

I'm sure somebody from Council will -1 me on that protocol violation, one day.

Ge0rG, a few char more or less...

isn’t that all just convention? ✏

+s

jonasw: yeah

marc: did you know there are some email clients that break links longer than 72 characters?

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.

There's a reason why my XMPP service is yax.im :P

Ge0rG, tbh no and I wouldn't care about it ^^

marc: why do you care about the right query action, then?

Ge0rG, because there is some sort of system for the XMPP URIs and we shouldn't break it IMO

marc: it's already broken.

Ge0rG, because of your XEP?

marc: no, before that. I've written about it being broken. Nobody cared.

Ge0rG, so let's care from now on ;)

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

marc: did you read my mail?

erlang is specifically called out as being vulnerable fyi

Ge0rG, https://mail.jabber.org/pipermail/standards/2016-June/031138.html this one?

marc: yeah

Ge0rG, I'll read it later.. I hope it's worth ;)

marc: Good. We can continue the discussion afterwards, then. Or tomorrow. ✏

lolwtf, tls is still doing the broken PKCS padding?

I thought this was just some funny anecdote in the lectures

jonasw, nah it always comes back to bite everyone :P

who's ejabberd dev in here, zinid ?

Holger, too

marc: but it's good that you see the same problems I encountered. You are on the right track ;)

moparisthebest, ejabberd doesn't use erlang's native ssl support, it uses openssl

oh, excellent, good to know, thanks zinid

and I'm not sure what this attack is about, I'm not a cryptobitch

yea no need to get bogged down in details, just should be concerned if you are vulnerable or not

TL;DR: they managed to sign something using facebooks SSL private key they supposedly stole. game over.

what's the point in all this TLS stuff, if vulnerabilites are being found every month

only leads to false sense of protection

do you have something better? :P

at least it's widely used and studied

moparisthebest, well, the point is: if I didn't use TLS, I would be vulnerable to heartbleeding, where the whole system can be borked

not sure what I gain from using TLS in this case

*I wouldn't be vulnerable

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.

zinid: you get protection against all passive attacks, and also some protection against FSB and NSA

I think we should standardize on Curve25519, because DJB is an awesome m*****f****r

Ge0rG, I think FSB and NSA already collected all vulnerabilities of openssl like that one with heartbleeding

yea most of the TLS problems are with legacy support, they realized that and dropped all legacy from TLS 1.3

zinid: heartbleed looked way too much like a plausible-deniability backdoor, yeah.

but zinid it's a choice between plaintext and no protection all the time, or TLS and best protection possible most of the time

moparisthebest, although the argument that heartbleed may do more damage than plaintexting everything is plausible

moparisthebest, but I don't remember a single case of MITM attack, but I remember a lot of openssl fuckups

jonasw, exactly

really? because some networks do MITM as normal matter of business

openssl is particularly bad too

s/networks/ISPs/

https://forums.xfinity.com/t5/Customer-Service/Are-you-aware-Comcast-is-injecting-400-lines-of-JavaScript-into/td-p/3009551

they even RFC'd it https://tools.ietf.org/html/rfc6108

moparisthebest: I just was going to paste that.

It's especially awesome for remote APIs

I bet

tl;dr everything should be TLS all the time, no exceptions :'(

https://news.ycombinator.com/item?id=15892282 ;)

It's nice and fair for the game to crash once you've used up 90% of your data cap.

moparisthebest, I mean I don't remember MITM in xmpp

well if they do it to HTTP :)

comcast will soon inject <message> stanzas

UPGRADE YOUR MODEM

still, no a single case of xmpp mitm

Reminds me of the good old times of CTCP PING +++ATH0

XML ads injection in the messages stanzas for the non-prenium accounts

edhelas: spam filtering as a premium feature.

The good thing about it: you can cash in from both sides

there is so much business to do

I should do a post about spam filtering on yax.im.

Just figure out a way to get users to pay to view ads and you're golden

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

I mean we had XHTML-IM for that but now it's dead :'(

JS over Markdown over XMPP messages

RCE as a service

moparisthebest: JS is horribly inefficient to mine crypto moneys

Ge0rG, what about WebAssembly

Surely there are wasm miners already running in your browser

XEP-0400 Arbitrary WebAssembly over XMPP

moparisthebest: what about it? Does it support OpenCL?

probably?

marc: right, please read my email and then we agree to not use any action at all.

Ge0rG, okay, give me some minutes but I'm pretty sure I don't like the concept :D

Ge0rG, okay, I don't see any argumentation in your mail to continue with meaningless "preauth" without action

just because some other actions are poorly specified?

marc: it's not meaningless. You can see from the JID that it is clearly a contact JID.

marc: the actions are so underdefined, that yaxim just ignores the action and derives what to do from the other query parameters.

marc: the only exception I'm using is `join` for MUCs

if there is a `body=`, send a message, otherwise add to roster.

marc: how does your client handle <xmpp:georg@yax.im> ?

Ge0rG, depends

marc: depends on what?

If that's my account, if this contact is already in my roster

marc: it's not your account. Now what will happen?

Ge0rG, it probably adds you to my roster

marc: and what happens on <xmpp:georg@yax.im?subscribe>? On <xmpp:georg@yax.im?roster>?

marc: what if I'm on your roster already? Should you open a chat tab instead? Or the "Edit roster item" dialog?

Ge0rG, The same argumentation applies to your ?preauth... what if you already subsubcribed? Should you open a chat window for the user?

marc: can we leave out PARS for a moment, please?

Ge0rG, this has nothing to do with the 'action' concept

marc: preauth is not an action, it's a query parameter.

Ge0rG, yes, but what happens needs to be specified

If you use an "action" or just query parameters

marc: where?

marc: do we want to write an Informational XEP that mandates what happens to a ?roster action if I'm already on your roster?

marc: nobody cares enough.

marc: See, Zash was the only one to answer to my question.

Ge0rG, yes, nobody cares which is why all clients behave differently which sucks, right?

marc: there is a defined list of actions. None of them works as I would expect.

marc: you would have to send two URIs with ?roster and ?subscribe for the full features

Ge0rG, yes, they don't work I know. But that's not an argument against using something like "?invite;token="

Is it?

I did whatnow?

Zash: you responded to a mail in mid 2016.

marc: But ?invite won't be supported by any clients at all!

Ge0rG, correct, ad-hoc commands and QR code generation too ;)

All clients need to be adapted for user-invitation

marc: no

Ge0rG, okay, all except yaxim

marc: NO!

Ge0rG, why?

marc: the good thing about PARS is that it's 100% backwards compatible

Ge0rG, no client except yaxim implements PARS, correct?

marc: right, but most clients implement roster subscription.

marc: and some even support using xmpp: URIs for that.

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

Ge0rG, I can not invite somebody with PARS and Conversations

Because Conversations doesn't support it

It doesn't generate a QR for me

marc: you can invite a Conversations user with PARS, but you'll have to add them manually afterwards.

Ge0rG, yes I know but I can not invite somebody else with Conversations

marc: so what's your point now?

Ge0rG, clients have to be adapted

marc: the good thing about PARS is that only the sending client needs to be changed.

Ge0rG, yes, that's correct

But that's not important for me if I don't use yaxim but Gajim or Conversations or whatever

My point: implementing an URI for this XEP in a client is not a big deal

marc: yes. First we need two implementations, then we can make it a proper XEP, then people will follow

Because we have to implement a lot more

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.

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

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.

Ge0rG, we should focus on more important things than URI definition. We can discuss the URI thing after all the complicated stuff is done

Ge0rG, right?

marc: right.

marc: so how would I add the preauth token into an IBR?

it needs to be indicated at the beginning and not as a form element.

data form as described in my awesome XEP?

:(

:D

marc: "described"? :P

well,...

:D

Ge0rG, what's wrong about the form element?

marc: how does the server know that it needs to return a form element and not just do IBR?

Ge0rG, it returns the form element if user-invitation is supported

marc: so now all normal IBR clients will stumble upon that?

it also returns <required/> if IBR is allowed with token only

marc: let's say your server supports both normal IBR and preauth, and uses preauth to add the inviter to the roster. ✏

marc: now everyone who wants to IBR with you gets a stupid "invite-token" dialog popup

Ge0rG, that's correct

But that's also a feature because I didn't have to implement much :D

marc: it's a feature to annoy all future users because you are lazy?

Ge0rG, no because it's a PoC

marc: it's great for a PoC, but we need to make it a protocol now

Ge0rG, yes, tell me your solution

Ge0rG, probably we need to change all clients for that, right?

marc: No?

Ge0rG, just tell me your idea :)

marc: server announces support for IBR <preauth/> in caps. client requests IBR form, receives normal form, sends registration IQ with a <preauth/> element, done.

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.

Ge0rG, sounds good, you like the term preauth, hm? :D

Ge0rG, how does this IBR form request for preauth look like?

marc: I have put some thought into the name; it's short and it indicates what it is without depending on a certain technology

<iq type='get' id='reg1' to='shakespeare.lit'> <query xmlns='jabber:iq:register'><preauth xmlns='urn:xmpp:pars:0'/></query> </iq>

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

so it can provide different fields in the response

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.

Ge0rG, sounds reasonable

marc: does the above XML look good to you?

Ge0rG, yes, except for the term "pars"

marc: in the namespace?

yes

call it `paac` then, for pre-authenticated account creation :P

marc: I'd be fine with renaming the namespace to urn:xmpp:preauth:0 as well

haha

:D

Even if it would break existing yaxim installations :P

however, 'pars' doesn't fit for account creation :)

marc: but pars defines the <preauth/> element, and there is nothing wrong with element reuse :P

aahh, that sounds wrong to me ^^

marc: let's skip over it and solve the next problem.

we are bike shedding again.

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

So we should think about it

marc: those limitations can be implemented on the server, no need to change the wire format

Ge0rG, yes, I just don't like the idea that the server generates different types of tokens when a user hits the limit

marc: I thought we were over that already?

Ge0rG, it just bugs me ;)

marc: no, I mean that you have different ad-hoc commands for IBR and PARS tokens.

Ge0rG, Oh, I thought we have IBR+PARS (where IBR might be disabled if the user hits a limit) and IBR-only

Ge0rG, so we have PARS and IBR-only?

marc: we have PARS+IBR and IBR-only

Ge0rG, correct

But what happens if the user hits a limit?

marc: I'm not sure what the right solution would be.

No PARS and IBR at all?

Or just PARS?

marc: I think that sending a PARS-only token is better than no token.

marc: also PARS+IBR doesn't mean all of the receipients are going to IBR immediately

Ge0rG, yes, probably but it bugs me that the user won't this

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?

ups... won't know this

What if I don't understand how "Send invitation" works and my first 50 tokens get lost?

That's a good question

marc: I think the only sensible solution is to limit registrations, not token issuance

marc: so your 51st friend will get a "this token is invalid" response to IBR

Ge0rG, wow, but that's strange isn't it?

marc: is it?

You generate a valid token and somehow it doesn't work although the token isn't expired

marc: do you have unlimited IBR on your server?

Ge0rG, I have no IBR at all

marc: my server will block out after three registrations from the same IP

Ge0rG, I would limit the token generation either based on time or amount or both...

Every token has an expiration date..

marc: yes, but that's independent of your potential abuse scenario

Ge0rG, why? A user is not allowed to invite more than X people, for example?

marc: your ad-hoc command could also return a text field that explains the token validity

marc: if a user is allowed to invite X people, and he generated X invitations already that all were lost. What then?

marc: another ad-hoc command to reset pending invitations?

Ge0rG, well, this depends on server operations anyway. But you could allow token generation after all tokens were expired?

marc: so the user is blocked for two weeks?

Ge0rG, depends on your lifetime?

marc: yes. Maybe it's two days. But how is that useful?

Ge0rG, maybe not more then X tokens in a hour?

marc: maybe, but I still think that you should limit account registrations instead.

marc: and even if you don't, you can easily link all the new accounts to the initial abuser.

marc: think about it some more, I'm out for tonight.

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

P.S: protocol design is hard.

No, good protocol design it hard ;)

‎[04:11:00 PM] ‎marc‎: Ge0rG, depends on your lifetime? ‎[04:11:16 PM] ‎Ge0rG‎: marc: yes. Maybe it's two days.

wow context matters

is there a proper way today to know if a remote MUC has been disconnected ? (like the service went down…)

edhelas: ping your nick

And pray that none of your clients disconnects or lags in that time