XSF Discussion - 2017-12-13

edhelas, https://github.com/horazont/aioxmpp/issues/90

some notes on that topic^

edhelas, https://github.com/horazont/aioxmpp/issues/90

thx

https://blog.apnic.net/2017/12/12/internet-protocols-changing/

XMPP over UDP for when ?

Ge0rG, just thought about user invitation again, we have to following scenarios, correct? * User invitation: - Client-side PARS (fallback for lazy server operators) - Server-side PARS: For private servers - Server-side PARS or account creation: For private or public servers * Account creation for admins and privileged users

Ge0rG, the new XEP would cover everything except client-side PARS

marc: Server-side PARS: this can work for public and private servers, depending on a server-side config.

Ge0rG, yes, of course

marc: other than that, yes

Ge0rG, good :)

Interesting in the context of xmpp.net: https://bitrot.sh/post/12-12-2017-osint-ssl-on-xmpp-shodan/

Ge0rG, have you thought about token expiration again?

what’s the question about token expiration?

jonasw, do they expire on generation or when they're used (account creation)?

jonasw, if they expire on generation: does the server generate PARS-only tokens instead?

marc: "expire" implies a time limit

does the server generate no tokens at all?

huh, how would expiration on generation work, what would that mean? they’re invalid immediately?

jonasw, no, the server denies token generation of course...

Ge0rG, yes, a combination of amount and time is probably the best solution

however, what shall we do if a user hit this limit?

+s

I would prefer an error message like "You generated too many invitations. This feature will be available again on DATE"

marc: as I said, I consider a limit on the _generation_ of tokens as inappropriate. I would prefer a limit on token _redemption_ instead.

marc: technically, it makes sense to limit the number of pending tokens to some arbitrary but large number, like 100, to prevent the user from DoSing the server. In practice, tokens are cheap compared to roster items, avatars and picture uploads.

Ge0rG, I don't care about how cheap are token generation is but about UX of the invitee

marc: what about the UX of the inviter? 😝

-are

Ge0rG, yes, that's also important but less than of the invitee I think

They are already deep enough in XMPP that we don't care about their needs!!

If you receive a token which is valid for 2 hours and use it after an hour and it doesn't work (because too many tokens were used) this looks like a broken system to the invitee

And you don't want to explain why it didn't work...

Also you have to store the number of used tokens for every user

marc: what's the problem you try to solve with the limit on tokens?

Ge0rG, too many account creations / too many invites

marc: which one of those?

Ge0rG, that's almost the same ;)

marc: no, they are different

yes, _almost_ the same ;)

Too many invites -> oh noes, XMPP is becoming too popular, better stop people!

Sufficiently different to make a difference in our discussion.

Given that a token should be usable if it is not expired ;)

Zash, not talking about public servers here

Oh no, someone popular is inviting all their friends, better stop them!

shouldn't 100 friends be enough for anyone Zash

marc: Never assumed you were

Zash: "a spammer is inviting their botnet to my server"

Zash, trolling is not helpful

I'm not

moparisthebest: 10 friends on the free plan

Zash: is it possible to disable users in prosody without deleting them?

Ge0rG: Probably useful to keep track of the tree of invitations for such events

Zash: yes, very useful

Zash, Okay, then you agree that limiting invitations may be useful, right?

marc: Not always.

are you talking about a XEP decision or an implementation decision? this sounds like clearly an implementation decision

Zash, I said "may be useful"

You don't have to use this option

moparisthebest: about how to allow that decision within the XEP

But there are good reasons for it

I haven't followed this that closely tho. Limits on which dimentions exactly?

Account creations per invite/token? Tokens per user? Per time?

Zash, oh come on... but your first reaction is "Too many invites -> oh noes, XMPP is becoming too popular, better stop people!"

Zash [16:06]: > Account creations per invite/token? Tokens per user? Per time? This is exactly what I want to know, too

and that's exactly why it should be an implementation decision

marc: so now what's your user story for limitations?

XEP should just say 'server can refuse to supply more tokens with reason'

Yes, to me it's an implementation decision.

marc: What I mean is, putting limits in place that prevents someone from getting all their friends into XMPP might not be in our best interest, assuming we want XMPP to be popular.

Zash, but some server operators don't want to have 10000 users

Zash, that's the reason

But then, artificial scarcity could possibly drive up the percieved value of an account

if you run a public server you don't have to care about it and just open it

marc: if it's a server implementation decision, it has no place in the XEP 😛

Should be up to local policy, probably

Ge0rG, the limitation (how many tokens per user, per time, etc.) should be implementation defined

Ge0rG, we have to decide how to inform the user in a proper way

marc: "with an appropriate error response"

If there's a TTL involved, is it not up to the UI to be clear about that?

"This is a time limited offer, get them while their hot!"

Ge0rG, exactly :) But _when_, that's the point. You want to throw an error on account creation. I would throw it on token generation

marc: these are different limits.

Ge0rG, so you want to make this also implementation defined?

If tokens expire, how would you communicate that except when it is used?

marc: no. I want to say you can't avoid errors on account registration

Zash, for token expiration that's okay

If the user who created it is still around, they could possibly be notified

Zash, but if your tokens are valid for 2 hours and don't get accepted because of some other reaons this is confusing

marc: but token lifetime is not communicated to the user!!!

Ge0rG, why?

Which user?

Ge0rG, should be

marc: how?

Zash: neither

Suppose you could stick a date/timestamp in the token

Ge0rG, landing page for example?

You could also apply it as parameter to the URI

marc: the landing page is not hosted by the xmpp server, and URL parameters can be manipulated

Ge0rG, the server can provide a URL

manipulating the expiration date?

Are you serious?

Nobody cares because it is checked by the server anyway

An expiration date in the URI is the most uncritical part

marc: only half-serious.

actually is it defined what the URL looks like or contains?

might be nice if the server doesn't have to actually store anything

moparisthebest, no

is that up to implementation then?

depends on what web site do you use

In my ejabberd implementation you can generate an URL with the invitation token and URI as parameter

like url: "https://example.com/i/@URI@" or url: "https://example.com/i/@TOKEN@"

It's up to example.com then how to display the invitation

but who invents the URL ? (along with any parameters)

moparisthebest, what do you mean by "invents the URL"

can the URL be https://example.com/i/terrible.php?auth=thaeoutinhtneoauh&timestamp=445456456546&inviter=bob@bob.com&tons_of_other_vars=1

Of course

so the URL is generated by the server and is implementation defined, good

It's a configuration parameter of the server

moparisthebest: that's possible, but I could intercept your invitation link and manipulate the params

moparisthebest: also: long links suck.

+1

Ge0rG, that's what the HMAC is for :P

moparisthebest, and how do you verify it?

moparisthebest: your server could just generate an encrypted & signed token that's passed on.

the reason I ask is because I like the concept of https://modules.prosody.im/mod_http_upload_external.html

so that your xmpp server and your web server don't need to talk, and you don't need to store anything

they simply share a secret key and done

You could do this

But that's out of scope here

yep excellent, just wanted to ensure you could do it :)

At least in my opinion

moparisthebest: the invitation token is opaque for the client and can contain anything you want.

the URL you mean? that's mainly what I was getting at

moparisthebest: it could be a base64-encoded zlib compressed collection of Shakespeare.

moparisthebest: the URL should not be the primary means, if the receiver already supports xmpp: URIs

ok, cool, that still works

moparisthebest: and you can encode your magic token in the xmpp: URI parameter

a neat stateless format might be like base64(inviter@jid\0expiration_timestamp\0hmac)

marc: so the invitee client still needs to support registration failures.

Ge0rG, of course

marc: so technically we don't need to encode a way to reject invitation tokes on ad-hoc

Ge0rG, technically not but for UX :D

marc: unless you want to limit the number of tokens, which you already agreed are cheap

marc: do you think there should be a limitation on the number of PARS token?

Ge0rG, I don't see a reason for PARS token but maybe there are some

Ge0rG, PARS tokens are not that critical I think

marc: the IBR tag is a nice-to-have additional feature on top of PARS. If the server is out of invitation codes, I think it makes for a better UX to skip the ibr invitation and to fallback to plain PARS than to break the complete invitation flow

Ge0rG, plain PARS is client-side PARS, right?

marc: no, plain PARS is PARS without ibr support

marc: but server-side

Ge0rG, okay... yes I thought about it. Somehow it is nice but somehow ugly

The nice thing is that the inviter can still invite users

C: request invite token S: is the user allowed? yes -> return PARS+IBR no -> return PARS not supported -> return error C: didn't get token? Fallback to client-side PARS

The bad thing is that invitees receive different invitations

marc: and I think it does not make sense to limit the number of pending PARS+IBR tokens in that scenario

marc: yes, unless you limit _registrations_ as opposed to _inivtations_ :P

if you don't limit invitations, all invites from a user look the same

Ge0rG, yes, you get confused after 30 seconds instead of 10 seconds :p

marc: I don't understand

Ge0rG, you get confused when the registration doesn't work instead of getting a different invitation

marc: except there is no guarantee that the registration link will work

Ge0rG, sounds like a broken system by design?

marc: did you know that TCP is by definition a reliable protocol, and that you still can't rely on it?

Ge0rG, did you know that a normal user doesn't care about technical issues? ;)

marc: what's your point?

marc: "inviter out of registrations" is one of many possible reasons to reject an account registration.

marc: on a sane server, no users will ever run into it

An invitation token MUST work if you received one

marc: what if the server went down due to a nuclear bomb?

still a MUST?

what if the server admin was fed up by dumb arguments and shut it down?

Ge0rG, well, the server wouldn't respond in this case so it's fine I think

Probably the user will blame the ISP

That's fine

marc: "An invitation token MUST work if you received one" - there is no way on earth to enforce that.

Ge0rG, I guess you know what I mean with this statement ;)

marc: especially not if you issue time-limited tokens

marc: I guess you don't :P

Ge0rG, time limitations are known to users from many other services

marc: so you agree that it's normal for a registration not to work always?

normal in the sense that users will expect this to happen, from time to time

Ge0rG, if the invitee followed the rules it shouldn't happen

Ge0rG, and if the server is down for a minute if works after a minute

marc: except the invitation email got greylisted for a day and the token expired. BOOM.

And nobody has to generate an other token

marc: another token wouldn't even help if the inviter is out of invitations :P

Ge0rG, yes, but that's out of scope sorry

Ge0rG, depends on your policy

marc: my point is: you can't enforce in the XEP that an invitaiton token MUST always work.

marc: and if you accept that truth, you can make the overall flow easier and more consistent by removing a corner case.

namely the corner case where your server rejects/downgrade the invitation token because of some internal counter.

Ge0rG, yes, you can not enforce it but we shouldn't introduce confusing behaviour on purpose

marc: I think it's more confusing if your server returns different invitations based on how often you asked

Ge0rG, yes, let's block it completely then :D

marc: I think it's more confusing if your server returns different responses based on how often you asked

Ge0rG, I don't agree with this statement if you throw a warning or an error or something like that

Ge0rG, and if you think that's confusing to the user if they receive different invitations you shouldn't implement client-side PARS as fallback :D

+it

marc: users get confused by different UI flows, not by different URLs.

Ge0rG, UI flow for client-side PARS is different because you can not create an account for some reason

marc: let's assume for a moment that you MUST limit the number of new accounts invited by a given user. Then you will have one confusing UX, either on invitation token generation or on account creation. But the latter only happens if the receiver doesn't have an XMPP account yet and if other people who got invitations didn't use them.

marc: you can create an account, just not with the inviter's server.

Ge0rG, " if other people who got invitations didn't use them"? -> "if all other people who got invitations use them"?

marc: correct

Ge0rG, sounds unpredictable for the invitee to me

And still you have to track the tokens after account creation

Or at least some counter for a user

marc: you have to anyway

Ge0rG, no, just store the token. If an account is created, remove it

No other information is needed

marc: what if the account registration would trigger another limit?

Ge0rG, what limit?

marc: total number of registrations per day for example

Ge0rG, that should be included in the account/token generation process

Ge0rG, of course you can configure your service for bad UX ;)

I think an account token should be considered as already registered account

For the "account limitation policy"

marc: I disagree

marc: an account-invte token is as good as an already registered account, but a PARS+IBR token is just an option

you can short-sell options

Ge0rG, correct, but account invitations shouldn't be blocked by other rules once they are issued IMO

marc: yes, but account invitations are created by admins anyway.

Ge0rG, we're talking about account invitations+PARS ;)

I think you know this ;)

marc: wait a moment. I was talking about contact invitations with IBR-fallback

Ge0rG, hm?

IBR = account invitation

marc: account-invitation = server-admin sends xmpp://newuser@server?token to make the invitee register an account

marc: contact-invitation = normal user sends xmpp:inviter@server?token;ibr to allow either contact subscription or IBR

Ge0rG, IBR-fallback = invitier gives invitee the possiblity to create an account even if the server doesn't allow IBR, right?

marc: right

Ge0rG, yes, we're talking about the same thing with different terms :D

marc: so you are talking about IBR-fallback?

a.k.a. PARS+IBR

a.k.a. contact-invitation

Ge0rG, yes

marc: so with the contact-invitation, there are two possibilities: either the invitee already has an account or not. In the first case, obviously, there is no need to block an "account slot" for them

Ge0rG, if you think client-side PARS fallback doesn't change the UI, PARS+IBR to PARS fallback (both server-side) doesn't change the UI too

So we have no problem actually

marc: client-side PARS fallback performs exactly the same task, just at different places.

marc: server-side PARS+IBR vs PARS-only has different implications

marc: I'm just saying that it's better to overissue tokens and to limit at the moment of registration, than to run out of tokens even though the ones you issued will never be used

Ge0rG: Huh, only the admin can give out invites?

Ge0rG, I know and I don't think that's good :)

Zash, no

Zash: only the admin can give out accounts

Ge0rG, afk, just tell me why we don't use a fallback from PARS+IBR to PARS when a user reaches some IBR-invitation limit

marc: because IBR-invitation limits don't make sense.

Ge0rG, and explain me why we should store lots of information about users just to enforce account limitation during IBR

marc: because account creation is the best moment to limit account creation.

Ge0rG, why?

why doesn't it make sense

because until an account is created, you don't know whether it will ever be

Yes, if the invitee uses PARS the inviter can issue more tokens

marc: so now what you can do as the inviter depends on what your invitees do. Yay.

Ge0rG, if you implement the policy that way, yes

marc: that's bad UX!

Ge0rG, we have two options: "bad" UX for inviter or invitee

marc: that's not true. The bad UX for the invitee is inevitable

marc: the good thing, it is only bad in corner cases.

Do you have like user stories written down?

I'd like to write the specification down.

Ge0rG, Yes, it's a corner case for both solution

+s

and I think for your solution additional data needs to be stored on the server

marc: maybe, maybe not.

Ge0rG, :P

marc: you need to store a counter on the user account anyway, if you want to limit number/time

Ge0rG, but that's optional

and adding a counter of user-initiated IBRs is not very expensive

Ge0rG, in your solution that's required

marc: no, it's optional. You don't NEED to limit anything.

Ge0rG, for my solution you use data which are necessary anyway

marc: but your solution is limiting user behavior at the wrong end of the registration

marc: anyway, that doesn't matter much for the XEP. Let's move this thing forward.

Ge0rG, why doesn't it matter?

marc: because it is an implementation detail, mostly.

marc: we still need to write an XEP

Ge0rG, yes, but I would like to have an error response for such things in the ad-hoc command

That's the point ;)

marc: the ad-hoc command is allowed to fail for whatever reasons deemed inappropriate.

marc: with standard error messages

Ge0rG, oh no.. standard error messages

They're not useful at all

marc: but I still am convinced that it is wrong to let it fail.

So I've been writing a blog post about fighting spam today, instead of writing the invitation XEP.

I'm planning to do another PR on 0060 in the upcoming days

to expose the access_model tag in the metadata