-
jonasw
edhelas, https://github.com/horazont/aioxmpp/issues/90
-
jonasw
some notes on that topic^
-
jonasw
edhelas, https://github.com/horazont/aioxmpp/issues/90
-
edhelas
thx
-
edhelas
https://blog.apnic.net/2017/12/12/internet-protocols-changing/
-
edhelas
XMPP over UDP for when ?
-
marc
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
-
marc
Ge0rG, the new XEP would cover everything except client-side PARS
-
Ge0rG
marc: Server-side PARS: this can work for public and private servers, depending on a server-side config.
-
marc
Ge0rG, yes, of course
-
Ge0rG
marc: other than that, yes
-
marc
Ge0rG, good :)
-
Ge0rG
Interesting in the context of xmpp.net: https://bitrot.sh/post/12-12-2017-osint-ssl-on-xmpp-shodan/
-
marc
Ge0rG, have you thought about token expiration again?
-
jonasw
what’s the question about token expiration?
-
marc
jonasw, do they expire on generation or when they're used (account creation)?
-
marc
jonasw, if they expire on generation: does the server generate PARS-only tokens instead?
-
Ge0rG
marc: "expire" implies a time limit
-
marc
does the server generate no tokens at all?
-
jonasw
huh, how would expiration on generation work, what would that mean? they’re invalid immediately?
-
marc
jonasw, no, the server denies token generation of course...
-
marc
Ge0rG, yes, a combination of amount and time is probably the best solution
-
marc
however, what shall we do if a user hit this limit?
-
marc
+s
-
marc
I would prefer an error message like "You generated too many invitations. This feature will be available again on DATE"
-
Ge0rG
marc: as I said, I consider a limit on the _generation_ of tokens as inappropriate. I would prefer a limit on token _redemption_ instead.
-
Ge0rG
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.
-
marc
Ge0rG, I don't care about how cheap are token generation is but about UX of the invitee
-
Ge0rG
marc: what about the UX of the inviter? 😝
-
marc
-are
-
marc
Ge0rG, yes, that's also important but less than of the invitee I think
-
Zash
They are already deep enough in XMPP that we don't care about their needs!!
-
marc
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
-
marc
And you don't want to explain why it didn't work...
-
marc
Also you have to store the number of used tokens for every user
-
Ge0rG
marc: what's the problem you try to solve with the limit on tokens?
-
marc
Ge0rG, too many account creations / too many invites
-
Ge0rG
marc: which one of those?
-
marc
Ge0rG, that's almost the same ;)
-
Ge0rG
marc: no, they are different
-
marc
yes, _almost_ the same ;)
-
Zash
Too many invites -> oh noes, XMPP is becoming too popular, better stop people!
-
Ge0rG
Sufficiently different to make a difference in our discussion.
-
marc
Given that a token should be usable if it is not expired ;)
-
marc
Zash, not talking about public servers here
-
Zash
Oh no, someone popular is inviting all their friends, better stop them!
-
moparisthebest
shouldn't 100 friends be enough for anyone Zash
-
Zash
marc: Never assumed you were
-
Ge0rG
Zash: "a spammer is inviting their botnet to my server"
-
marc
Zash, trolling is not helpful
-
Zash
I'm not
-
Ge0rG
moparisthebest: 10 friends on the free plan
-
Ge0rG
Zash: is it possible to disable users in prosody without deleting them?
-
Zash
Ge0rG: Probably useful to keep track of the tree of invitations for such events
-
Ge0rG
Zash: yes, very useful
-
marc
Zash, Okay, then you agree that limiting invitations may be useful, right?
-
Zash
marc: Not always.
-
moparisthebest
are you talking about a XEP decision or an implementation decision? this sounds like clearly an implementation decision
-
marc
Zash, I said "may be useful"
-
marc
You don't have to use this option
-
Ge0rG
moparisthebest: about how to allow that decision within the XEP
-
marc
But there are good reasons for it
-
Zash
I haven't followed this that closely tho. Limits on which dimentions exactly?
-
Zash
Account creations per invite/token? Tokens per user? Per time?
-
marc
Zash, oh come on... but your first reaction is "Too many invites -> oh noes, XMPP is becoming too popular, better stop people!"
-
Ge0rG
Zash [16:06]: > Account creations per invite/token? Tokens per user? Per time? This is exactly what I want to know, too
-
moparisthebest
and that's exactly why it should be an implementation decision
-
Ge0rG
marc: so now what's your user story for limitations?
-
moparisthebest
XEP should just say 'server can refuse to supply more tokens with reason'
-
marc
Yes, to me it's an implementation decision.
-
Zash
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.
-
marc
Zash, but some server operators don't want to have 10000 users
-
marc
Zash, that's the reason
-
Zash
But then, artificial scarcity could possibly drive up the percieved value of an account
-
marc
if you run a public server you don't have to care about it and just open it
-
Ge0rG
marc: if it's a server implementation decision, it has no place in the XEP 😛
-
Zash
Should be up to local policy, probably
-
marc
Ge0rG, the limitation (how many tokens per user, per time, etc.) should be implementation defined
-
marc
Ge0rG, we have to decide how to inform the user in a proper way
-
Ge0rG
marc: "with an appropriate error response"
-
Zash
If there's a TTL involved, is it not up to the UI to be clear about that?
-
Zash
"This is a time limited offer, get them while their hot!"
-
marc
Ge0rG, exactly :) But _when_, that's the point. You want to throw an error on account creation. I would throw it on token generation
-
Ge0rG
marc: these are different limits.
-
marc
Ge0rG, so you want to make this also implementation defined?
-
Zash
If tokens expire, how would you communicate that except when it is used?
-
Ge0rG
marc: no. I want to say you can't avoid errors on account registration
-
marc
Zash, for token expiration that's okay
-
Zash
If the user who created it is still around, they could possibly be notified
-
marc
Zash, but if your tokens are valid for 2 hours and don't get accepted because of some other reaons this is confusing
-
Ge0rG
marc: but token lifetime is not communicated to the user!!!
-
marc
Ge0rG, why?
-
Zash
Which user?
-
marc
Ge0rG, should be
-
Ge0rG
marc: how?
-
Ge0rG
Zash: neither
-
Zash
Suppose you could stick a date/timestamp in the token
-
marc
Ge0rG, landing page for example?
-
marc
You could also apply it as parameter to the URI
-
Ge0rG
marc: the landing page is not hosted by the xmpp server, and URL parameters can be manipulated
-
marc
Ge0rG, the server can provide a URL
-
marc
manipulating the expiration date?
-
marc
Are you serious?
-
marc
Nobody cares because it is checked by the server anyway
-
marc
An expiration date in the URI is the most uncritical part
-
Ge0rG
marc: only half-serious.
-
moparisthebest
actually is it defined what the URL looks like or contains?
-
moparisthebest
might be nice if the server doesn't have to actually store anything
-
marc
moparisthebest, no
-
moparisthebest
is that up to implementation then?
-
marc
depends on what web site do you use
-
marc
In my ejabberd implementation you can generate an URL with the invitation token and URI as parameter
-
marc
like url: "https://example.com/i/@URI@" or url: "https://example.com/i/@TOKEN@"
-
marc
It's up to example.com then how to display the invitation
-
moparisthebest
but who invents the URL ? (along with any parameters)
-
marc
moparisthebest, what do you mean by "invents the URL"
-
moparisthebest
can the URL be https://example.com/i/terrible.php?auth=thaeoutinhtneoauh×tamp=445456456546&inviter=bob@bob.com&tons_of_other_vars=1
-
marc
Of course
-
moparisthebest
so the URL is generated by the server and is implementation defined, good
-
marc
It's a configuration parameter of the server
-
Ge0rG
moparisthebest: that's possible, but I could intercept your invitation link and manipulate the params
-
Ge0rG
moparisthebest: also: long links suck.
-
marc
+1
-
moparisthebest
Ge0rG, that's what the HMAC is for :P
-
marc
moparisthebest, and how do you verify it?
-
Ge0rG
moparisthebest: your server could just generate an encrypted & signed token that's passed on.
-
moparisthebest
the reason I ask is because I like the concept of https://modules.prosody.im/mod_http_upload_external.html
-
moparisthebest
so that your xmpp server and your web server don't need to talk, and you don't need to store anything
-
moparisthebest
they simply share a secret key and done
-
marc
You could do this
-
marc
But that's out of scope here
-
moparisthebest
yep excellent, just wanted to ensure you could do it :)
-
marc
At least in my opinion
-
Ge0rG
moparisthebest: the invitation token is opaque for the client and can contain anything you want.
-
moparisthebest
the URL you mean? that's mainly what I was getting at
-
Ge0rG
moparisthebest: it could be a base64-encoded zlib compressed collection of Shakespeare.
-
Ge0rG
moparisthebest: the URL should not be the primary means, if the receiver already supports xmpp: URIs
-
moparisthebest
ok, cool, that still works
-
Ge0rG
moparisthebest: and you can encode your magic token in the xmpp: URI parameter
-
moparisthebest
a neat stateless format might be like base64(inviter@jid\0expiration_timestamp\0hmac)
-
Ge0rG
marc: so the invitee client still needs to support registration failures.
-
marc
Ge0rG, of course
-
Ge0rG
marc: so technically we don't need to encode a way to reject invitation tokes on ad-hoc
-
marc
Ge0rG, technically not but for UX :D
-
Ge0rG
marc: unless you want to limit the number of tokens, which you already agreed are cheap
-
Ge0rG
marc: do you think there should be a limitation on the number of PARS token?
-
marc
Ge0rG, I don't see a reason for PARS token but maybe there are some
-
marc
Ge0rG, PARS tokens are not that critical I think
-
Ge0rG
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
-
marc
Ge0rG, plain PARS is client-side PARS, right?
-
Ge0rG
marc: no, plain PARS is PARS without ibr support
-
Ge0rG
marc: but server-side
-
marc
Ge0rG, okay... yes I thought about it. Somehow it is nice but somehow ugly
-
marc
The nice thing is that the inviter can still invite users
-
Ge0rG
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
-
marc
The bad thing is that invitees receive different invitations
-
Ge0rG
marc: and I think it does not make sense to limit the number of pending PARS+IBR tokens in that scenario
-
Ge0rG
marc: yes, unless you limit _registrations_ as opposed to _inivtations_ :P
-
Ge0rG
if you don't limit invitations, all invites from a user look the same
-
marc
Ge0rG, yes, you get confused after 30 seconds instead of 10 seconds :p
-
Ge0rG
marc: I don't understand
-
marc
Ge0rG, you get confused when the registration doesn't work instead of getting a different invitation
-
Ge0rG
marc: except there is no guarantee that the registration link will work
-
marc
Ge0rG, sounds like a broken system by design?
-
Ge0rG
marc: did you know that TCP is by definition a reliable protocol, and that you still can't rely on it?
-
marc
Ge0rG, did you know that a normal user doesn't care about technical issues? ;)
-
Ge0rG
marc: what's your point?
-
Ge0rG
marc: "inviter out of registrations" is one of many possible reasons to reject an account registration.
-
Ge0rG
marc: on a sane server, no users will ever run into it
-
marc
An invitation token MUST work if you received one
-
Ge0rG
marc: what if the server went down due to a nuclear bomb?
-
Ge0rG
still a MUST?
-
Ge0rG
what if the server admin was fed up by dumb arguments and shut it down?
-
marc
Ge0rG, well, the server wouldn't respond in this case so it's fine I think
-
marc
Probably the user will blame the ISP
-
marc
That's fine
-
Ge0rG
marc: "An invitation token MUST work if you received one" - there is no way on earth to enforce that.
-
marc
Ge0rG, I guess you know what I mean with this statement ;)
-
Ge0rG
marc: especially not if you issue time-limited tokens
-
Ge0rG
marc: I guess you don't :P
-
marc
Ge0rG, time limitations are known to users from many other services
-
Ge0rG
marc: so you agree that it's normal for a registration not to work always?
-
Ge0rG
normal in the sense that users will expect this to happen, from time to time
-
marc
Ge0rG, if the invitee followed the rules it shouldn't happen
-
marc
Ge0rG, and if the server is down for a minute if works after a minute
-
Ge0rG
marc: except the invitation email got greylisted for a day and the token expired. BOOM.
-
marc
And nobody has to generate an other token
-
Ge0rG
marc: another token wouldn't even help if the inviter is out of invitations :P
-
marc
Ge0rG, yes, but that's out of scope sorry
-
marc
Ge0rG, depends on your policy
-
Ge0rG
marc: my point is: you can't enforce in the XEP that an invitaiton token MUST always work.
-
Ge0rG
marc: and if you accept that truth, you can make the overall flow easier and more consistent by removing a corner case.
-
Ge0rG
namely the corner case where your server rejects/downgrade the invitation token because of some internal counter.
-
marc
Ge0rG, yes, you can not enforce it but we shouldn't introduce confusing behaviour on purpose
-
Ge0rG
marc: I think it's more confusing if your server returns different invitations based on how often you asked
-
marc
Ge0rG, yes, let's block it completely then :D
-
Ge0rG
marc: I think it's more confusing if your server returns different responses based on how often you asked
-
marc
Ge0rG, I don't agree with this statement if you throw a warning or an error or something like that
-
marc
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
-
marc
+it
-
Ge0rG
marc: users get confused by different UI flows, not by different URLs.
-
marc
Ge0rG, UI flow for client-side PARS is different because you can not create an account for some reason
-
Ge0rG
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.
-
Ge0rG
marc: you can create an account, just not with the inviter's server.
-
marc
Ge0rG, " if other people who got invitations didn't use them"? -> "if all other people who got invitations use them"?
-
Ge0rG
marc: correct
-
marc
Ge0rG, sounds unpredictable for the invitee to me
-
marc
And still you have to track the tokens after account creation
-
marc
Or at least some counter for a user
-
Ge0rG
marc: you have to anyway
-
marc
Ge0rG, no, just store the token. If an account is created, remove it
-
marc
No other information is needed
-
Ge0rG
marc: what if the account registration would trigger another limit?
-
marc
Ge0rG, what limit?
-
Ge0rG
marc: total number of registrations per day for example
-
marc
Ge0rG, that should be included in the account/token generation process
-
marc
Ge0rG, of course you can configure your service for bad UX ;)
-
marc
I think an account token should be considered as already registered account
-
marc
For the "account limitation policy"
-
Ge0rG
marc: I disagree
-
Ge0rG
marc: an account-invte token is as good as an already registered account, but a PARS+IBR token is just an option
-
Ge0rG
you can short-sell options
-
marc
Ge0rG, correct, but account invitations shouldn't be blocked by other rules once they are issued IMO
-
Ge0rG
marc: yes, but account invitations are created by admins anyway.
-
marc
Ge0rG, we're talking about account invitations+PARS ;)
-
marc
I think you know this ;)
-
Ge0rG
marc: wait a moment. I was talking about contact invitations with IBR-fallback
-
marc
Ge0rG, hm?
-
marc
IBR = account invitation
-
Ge0rG
marc: account-invitation = server-admin sends xmpp://newuser@server?token to make the invitee register an account
-
Ge0rG
marc: contact-invitation = normal user sends xmpp:inviter@server?token;ibr to allow either contact subscription or IBR
-
marc
Ge0rG, IBR-fallback = invitier gives invitee the possiblity to create an account even if the server doesn't allow IBR, right?
-
Ge0rG
marc: right
-
marc
Ge0rG, yes, we're talking about the same thing with different terms :D
-
Ge0rG
marc: so you are talking about IBR-fallback?
-
Ge0rG
a.k.a. PARS+IBR
-
Ge0rG
a.k.a. contact-invitation
-
marc
Ge0rG, yes
-
Ge0rG
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
-
marc
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
-
marc
So we have no problem actually
-
Ge0rG
marc: client-side PARS fallback performs exactly the same task, just at different places.
-
Ge0rG
marc: server-side PARS+IBR vs PARS-only has different implications
-
Ge0rG
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
-
Zash
Ge0rG: Huh, only the admin can give out invites?
-
marc
Ge0rG, I know and I don't think that's good :)
-
marc
Zash, no
-
Ge0rG
Zash: only the admin can give out accounts
-
marc
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
-
Ge0rG
marc: because IBR-invitation limits don't make sense.
-
marc
Ge0rG, and explain me why we should store lots of information about users just to enforce account limitation during IBR
-
Ge0rG
marc: because account creation is the best moment to limit account creation.
-
marc
Ge0rG, why?
-
marc
why doesn't it make sense
-
Ge0rG
because until an account is created, you don't know whether it will ever be
-
marc
Yes, if the invitee uses PARS the inviter can issue more tokens
-
Ge0rG
marc: so now what you can do as the inviter depends on what your invitees do. Yay.
-
marc
Ge0rG, if you implement the policy that way, yes
-
Ge0rG
marc: that's bad UX!
-
marc
Ge0rG, we have two options: "bad" UX for inviter or invitee
-
Ge0rG
marc: that's not true. The bad UX for the invitee is inevitable
-
Ge0rG
marc: the good thing, it is only bad in corner cases.
-
Zash
Do you have like user stories written down?
-
Ge0rG
I'd like to write the specification down.
-
marc
Ge0rG, Yes, it's a corner case for both solution
-
marc
+s
-
marc
and I think for your solution additional data needs to be stored on the server
-
Ge0rG
marc: maybe, maybe not.
-
marc
Ge0rG, :P
-
Ge0rG
marc: you need to store a counter on the user account anyway, if you want to limit number/time
-
marc
Ge0rG, but that's optional
-
Ge0rG
and adding a counter of user-initiated IBRs is not very expensive
-
marc
Ge0rG, in your solution that's required
-
Ge0rG
marc: no, it's optional. You don't NEED to limit anything.
-
marc
Ge0rG, for my solution you use data which are necessary anyway
-
Ge0rG
marc: but your solution is limiting user behavior at the wrong end of the registration
-
Ge0rG
marc: anyway, that doesn't matter much for the XEP. Let's move this thing forward.
-
marc
Ge0rG, why doesn't it matter?
-
Ge0rG
marc: because it is an implementation detail, mostly.
-
Ge0rG
marc: we still need to write an XEP
-
marc
Ge0rG, yes, but I would like to have an error response for such things in the ad-hoc command
-
marc
That's the point ;)
-
Ge0rG
marc: the ad-hoc command is allowed to fail for whatever reasons deemed inappropriate.
-
Ge0rG
marc: with standard error messages
-
marc
Ge0rG, oh no.. standard error messages
-
marc
They're not useful at all
-
Ge0rG
marc: but I still am convinced that it is wrong to let it fail.
-
Ge0rG
So I've been writing a blog post about fighting spam today, instead of writing the invitation XEP.
-
edhelas
I'm planning to do another PR on 0060 in the upcoming days
-
edhelas
to expose the access_model tag in the metadata