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 :)
ralphmhas joined
Ge0rGhas left
archas left
archas joined
Ge0rG
Interesting in the context of xmpp.net: https://bitrot.sh/post/12-12-2017-osint-ssl-on-xmpp-shodan/
Steve Killehas left
Tobiashas joined
archas left
archas joined
tim@boese-ban.dehas left
lumihas joined
nycohas joined
Syndacehas left
Syndacehas joined
Kevhas left
danielhas left
danielhas joined
ralphmhas joined
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...
nycohas left
Steve Killehas left
marc
Ge0rG, yes, a combination of amount and time is probably the best solution
nycohas joined
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"
intosihas left
intosihas joined
ralphmhas joined
Kevhas joined
Kevhas left
lumihas left
ralphmhas joined
valohas left
valohas joined
la|r|mahas joined
ralphmhas left
zinidhas left
sonnyhas left
ralphmhas joined
Alexhas joined
intosihas left
intosihas joined
nycohas left
SamWhitedhas joined
SamWhitedhas joined
nycohas joined
la|r|mahas left
la|r|mahas joined
la|r|mahas left
la|r|mahas left
la|r|mahas left
zinidhas left
zinidhas left
zinidhas joined
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.
intosihas left
intosihas joined
stefandxmhas left
Holgerhas left
marc
Ge0rG, I don't care about how cheap are token generation is but about UX of the invitee
intosihas left
intosihas joined
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
danielhas left
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
nycohas left
nycohas joined
ralphmhas joined
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
nycohas left
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
lovetoxhas joined
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.
jcbrandhas left
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
intosihas left
intosihas joined
Ge0rG
marc: only half-serious.
mrkikohas left
mrkikohas joined
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.
danielhas joined
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?
uchas left
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?
ralphmhas joined
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
Kevhas left
marc
Ge0rG, you get confused when the registration doesn't work instead of getting a different invitation
Kevhas joined
Ge0rG
marc: except there is no guarantee that the registration link will work
blablahas joined
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?
blablahas left
marc
Ge0rG, did you know that a normal user doesn't care about technical issues? ;)
blablahas joined
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
blablahas left
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
blablahas left
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
Kevhas left
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
zinidhas left
Kevhas left
Ge0rG
marc: what if the account registration would trigger another limit?
stefandxmhas joined
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
blablahas left
ralphmhas joined
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
Kevhas joined
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!
xnyhpshas left
lskdjfhas joined
la|r|mahas left
intosihas left
intosihas joined
Lancehas joined
uchas left
mimi89999has left
mimi89999has left
uchas left
intosihas left
intosihas joined
mimi89999has joined
uchas joined
Lancehas left
mimi89999has left
mimi89999has left
uchas left
mimi89999has left
uchas left
uchas joined
mimi89999has joined
jjrhhas left
lumihas joined
jubalhhas left
marchas left
ralphmhas joined
Holgerhas left
sonnyhas left
jerehas joined
danielhas left
nycohas joined
intosihas left
intosihas joined
jjrhhas left
jjrhhas left
@Alacerhas left
danielhas left
Tobiashas joined
tuxhas joined
Zashhas left
danielhas left
goffihas left
nycohas left
intosihas left
nycohas joined
sonnyhas left
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas left
lskdjfhas left
lskdjfhas left
lskdjfhas left
lskdjfhas joined
Kevhas left
Holgerhas left
lskdjfhas joined
zinidhas left
ralphmhas joined
sezuanhas left
zinidhas left
Steve Killehas left
zinidhas left
Steve Killehas left
lskdjfhas left
lskdjfhas joined
sonnyhas joined
archas left
archas joined
lskdjfhas joined
blablahas joined
lskdjfhas joined
jubalhhas joined
lskdjfhas left
lskdjfhas left
lskdjfhas left
lskdjfhas left
lskdjfhas left
lskdjfhas left
Zashhas left
lskdjfhas joined
Syndacehas joined
Syndacehas joined
lskdjfhas left
lskdjfhas left
nycohas left
nycohas joined
Tobiashas joined
jubalhhas left
lskdjfhas left
jerehas joined
jerehas joined
lskdjfhas left
Tobiashas joined
lskdjfhas left
lskdjfhas joined
Tobiashas left
Tobiashas joined
Alexhas left
lskdjfhas left
Alexhas joined
nycohas left
nycohas joined
ralphmhas joined
jerehas joined
jerehas joined
Steve Killehas joined
ralphmhas left
jerehas left
jerehas joined
marc
Ge0rG, we have two options: "bad" UX for inviter or invitee
Alexhas left
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
Steve Killehas left
marc
and I think for your solution additional data needs to be stored on the server
Ge0rG
marc: maybe, maybe not.
sonnyhas joined
marc
Ge0rG, :P
efrithas joined
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
ralphmhas joined
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.
archas left
archas joined
lskdjfhas joined
Ge0rG
So I've been writing a blog post about fighting spam today, instead of writing the invitation XEP.
lskdjfhas left
sonnyhas left
jcbrandhas joined
lskdjfhas left
nycohas left
lskdjfhas left
sonnyhas left
sonnyhas joined
nycohas joined
lskdjfhas left
lskdjfhas left
jcbrandhas left
jcbrandhas left
danielhas left
danielhas left
lskdjfhas left
danielhas left
danielhas left
mrkikohas left
mrkikohas joined
lskdjfhas joined
lskdjfhas left
lskdjfhas left
archas left
archas joined
jonaswhas left
debaclehas left
jerehas joined
ralphmhas joined
la|r|mahas joined
ralphmhas joined
archas left
archas joined
goffihas joined
lskdjfhas left
ralphmhas joined
jcbrandhas joined
jcbrandhas left
jcbrandhas joined
lskdjfhas joined
jcbrandhas left
danielhas left
lskdjfhas left
tuxhas left
archas left
jubalhhas joined
archas joined
archas left
archas joined
waqashas joined
jubalhhas left
zinidhas left
archas left
archas joined
sonnyhas joined
lskdjfhas left
Ge0rGhas left
lskdjfhas joined
uchas joined
ralphmhas joined
jerehas joined
jerehas joined
archas left
archas joined
sonnyhas joined
archas left
archas joined
uchas joined
ralphmhas left
nycohas left
nycohas joined
jerehas joined
jerehas joined
Ge0rGhas left
danielhas left
goffihas left
ralphmhas joined
Holgerhas left
lskdjfhas joined
lskdjfhas left
lskdjfhas left
danielhas left
Ge0rGhas joined
danielhas joined
jubalhhas joined
ralphmhas left
jubalhhas left
moparisthebesthas joined
Holgerhas left
jjrhhas left
marchas left
archas left
archas joined
marchas left
Kevhas joined
lumihas joined
edhelashas left
edhelashas joined
lumihas joined
sonnyhas joined
sonnyhas joined
sonnyhas left
sonnyhas joined
lskdjfhas joined
lskdjfhas left
jerehas joined
jubalhhas joined
sonnyhas joined
sonnyhas joined
Kevhas left
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
lskdjfhas left
lskdjfhas left
sonnyhas left
sonnyhas joined
Ge0rGhas left
edhelas
I'm planning to do another PR on 0060 in the upcoming days