marcGe0rG, 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
marcGe0rG, the new XEP would cover everything except client-side PARS
Ge0rGmarc: Server-side PARS: this can work for public and private servers, depending on a server-side config.
marcGe0rG, yes, of course
Ge0rGmarc: other than that, yes
marcGe0rG, good :)
ralphmhas joined
Ge0rGhas left
archas left
archas joined
Ge0rGInteresting 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
marcGe0rG, have you thought about token expiration again?
jonaswwhat’s the question about token expiration?
marcjonasw, do they expire on generation or when they're used (account creation)?
marcjonasw, if they expire on generation: does the server generate PARS-only tokens instead?
Ge0rGmarc: "expire" implies a time limit
marcdoes the server generate no tokens at all?
jonaswhuh, how would expiration on generation work, what would that mean? they’re invalid immediately?
marcjonasw, no, the server denies token generation of course...
nycohas left
Steve Killehas left
marcGe0rG, yes, a combination of amount and time is probably the best solution
nycohas joined
marchowever, what shall we do if a user hit this limit?
marc+s
marcI 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
Ge0rGmarc: as I said, I consider a limit on the _generation_ of tokens as inappropriate. I would prefer a limit on token _redemption_ instead.
Ge0rGmarc: 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
marcGe0rG, I don't care about how cheap are token generation is but about UX of the invitee
intosihas left
intosihas joined
Ge0rGmarc: what about the UX of the inviter? 😝
marc-are
marcGe0rG, yes, that's also important but less than of the invitee I think
ZashThey are already deep enough in XMPP that we don't care about their needs!!
marcIf 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
marcAnd you don't want to explain why it didn't work...
marcAlso you have to store the number of used tokens for every user
nycohas left
nycohas joined
ralphmhas joined
Ge0rGmarc: what's the problem you try to solve with the limit on tokens?
marcGe0rG, too many account creations / too many invites
Ge0rGmarc: which one of those?
marcGe0rG, that's almost the same ;)
Ge0rGmarc: no, they are different
marcyes, _almost_ the same ;)
ZashToo many invites -> oh noes, XMPP is becoming too popular, better stop people!
Ge0rGSufficiently different to make a difference in our discussion.
marcGiven that a token should be usable if it is not expired ;)
marcZash, not talking about public servers here
ZashOh no, someone popular is inviting all their friends, better stop them!
moparisthebestshouldn't 100 friends be enough for anyone Zash
Zashmarc: Never assumed you were
Ge0rGZash: "a spammer is inviting their botnet to my server"
marcZash, trolling is not helpful
ZashI'm not
Ge0rGmoparisthebest: 10 friends on the free plan
Ge0rGZash: is it possible to disable users in prosody without deleting them?
ZashGe0rG: Probably useful to keep track of the tree of invitations for such events
Ge0rGZash: yes, very useful
marcZash, Okay, then you agree that limiting invitations may be useful, right?
Zashmarc: Not always.
moparisthebestare you talking about a XEP decision or an implementation decision? this sounds like clearly an implementation decision
marcZash, I said "may be useful"
marcYou don't have to use this option
Ge0rGmoparisthebest: about how to allow that decision within the XEP
marcBut there are good reasons for it
ZashI haven't followed this that closely tho. Limits on which dimentions exactly?
ZashAccount creations per invite/token? Tokens per user? Per time?
marcZash, oh come on... but your first reaction is "Too many invites -> oh noes, XMPP is becoming too popular, better stop people!"
Ge0rGZash [16:06]:
> Account creations per invite/token? Tokens per user? Per time?
This is exactly what I want to know, too
moparisthebestand that's exactly why it should be an implementation decision
Ge0rGmarc: so now what's your user story for limitations?
moparisthebestXEP should just say 'server can refuse to supply more tokens with reason'
marcYes, to me it's an implementation decision.
Zashmarc: 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.
marcZash, but some server operators don't want to have 10000 users
marcZash, that's the reason
ZashBut then, artificial scarcity could possibly drive up the percieved value of an account
marcif you run a public server you don't have to care about it and just open it
Ge0rGmarc: if it's a server implementation decision, it has no place in the XEP 😛
ZashShould be up to local policy, probably
nycohas left
marcGe0rG, the limitation (how many tokens per user, per time, etc.) should be implementation defined
marcGe0rG, we have to decide how to inform the user in a proper way
lovetoxhas joined
Ge0rGmarc: "with an appropriate error response"
ZashIf 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!"
marcGe0rG, exactly :) But _when_, that's the point. You want to throw an error on account creation. I would throw it on token generation
Ge0rGmarc: these are different limits.
jcbrandhas left
marcGe0rG, so you want to make this also implementation defined?
ZashIf tokens expire, how would you communicate that except when it is used?
Ge0rGmarc: no. I want to say you can't avoid errors on account registration
marcZash, for token expiration that's okay
ZashIf the user who created it is still around, they could possibly be notified
marcZash, but if your tokens are valid for 2 hours and don't get accepted because of some other reaons this is confusing
Ge0rGmarc: but token lifetime is not communicated to the user!!!
marcGe0rG, why?
ZashWhich user?
marcGe0rG, should be
Ge0rGmarc: how?
Ge0rGZash: neither
ZashSuppose you could stick a date/timestamp in the token
marcGe0rG, landing page for example?
marcYou could also apply it as parameter to the URI
Ge0rGmarc: the landing page is not hosted by the xmpp server, and URL parameters can be manipulated
marcGe0rG, the server can provide a URL
marcmanipulating the expiration date?
marcAre you serious?
marcNobody cares because it is checked by the server anyway
marcAn expiration date in the URI is the most uncritical part
intosihas left
intosihas joined
Ge0rGmarc: only half-serious.
mrkikohas left
mrkikohas joined
moparisthebestactually is it defined what the URL looks like or contains?
moparisthebestmight be nice if the server doesn't have to actually store anything
marcmoparisthebest, no
moparisthebestis that up to implementation then?
marcdepends on what web site do you use
marcIn my ejabberd implementation you can generate an URL with the invitation token and URI as parameter
marclike url: "https://example.com/i/@URI@" or url: "https://example.com/i/@TOKEN@"
marcIt's up to example.com then how to display the invitation
moparisthebestbut who invents the URL ? (along with any parameters)
marcmoparisthebest, what do you mean by "invents the URL"
moparisthebestcan the URL be https://example.com/i/terrible.php?auth=thaeoutinhtneoauh×tamp=445456456546&inviter=bob@bob.com&tons_of_other_vars=1
marcOf course
moparisthebestso the URL is generated by the server and is implementation defined, good
marcIt's a configuration parameter of the server
Ge0rGmoparisthebest: that's possible, but I could intercept your invitation link and manipulate the params
Ge0rGmoparisthebest: also: long links suck.
marc+1
moparisthebestGe0rG, that's what the HMAC is for :P
marcmoparisthebest, and how do you verify it?
Ge0rGmoparisthebest: your server could just generate an encrypted & signed token that's passed on.
moparisthebestthe reason I ask is because I like the concept of https://modules.prosody.im/mod_http_upload_external.html
moparisthebestso that your xmpp server and your web server don't need to talk, and you don't need to store anything
moparisthebestthey simply share a secret key and done
marcYou could do this
marcBut that's out of scope here
moparisthebestyep excellent, just wanted to ensure you could do it :)
marcAt least in my opinion
Ge0rGmoparisthebest: the invitation token is opaque for the client and can contain anything you want.
moparisthebestthe URL you mean? that's mainly what I was getting at
Ge0rGmoparisthebest: it could be a base64-encoded zlib compressed collection of Shakespeare.
danielhas joined
Ge0rGmoparisthebest: the URL should not be the primary means, if the receiver already supports xmpp: URIs
moparisthebestok, cool, that still works
Ge0rGmoparisthebest: and you can encode your magic token in the xmpp: URI parameter
moparisthebesta neat stateless format might be like base64(inviter@jid\0expiration_timestamp\0hmac)
Ge0rGmarc: so the invitee client still needs to support registration failures.
marcGe0rG, of course
Ge0rGmarc: so technically we don't need to encode a way to reject invitation tokes on ad-hoc
marcGe0rG, technically not but for UX :D
Ge0rGmarc: unless you want to limit the number of tokens, which you already agreed are cheap
Ge0rGmarc: do you think there should be a limitation on the number of PARS token?
uchas left
marcGe0rG, I don't see a reason for PARS token but maybe there are some
marcGe0rG, PARS tokens are not that critical I think
Ge0rGmarc: 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
marcGe0rG, plain PARS is client-side PARS, right?
ralphmhas joined
Ge0rGmarc: no, plain PARS is PARS without ibr support
Ge0rGmarc: but server-side
marcGe0rG, okay... yes I thought about it. Somehow it is nice but somehow ugly
marcThe nice thing is that the inviter can still invite users
Ge0rGC: 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
marcThe bad thing is that invitees receive different invitations
Ge0rGmarc: and I think it does not make sense to limit the number of pending PARS+IBR tokens in that scenario
Ge0rGmarc: yes, unless you limit _registrations_ as opposed to _inivtations_ :P
Ge0rGif you don't limit invitations, all invites from a user look the same
marcGe0rG, yes, you get confused after 30 seconds instead of 10 seconds :p
Ge0rGmarc: I don't understand
Kevhas left
marcGe0rG, you get confused when the registration doesn't work instead of getting a different invitation
Kevhas joined
Ge0rGmarc: except there is no guarantee that the registration link will work
blablahas joined
marcGe0rG, sounds like a broken system by design?
Ge0rGmarc: did you know that TCP is by definition a reliable protocol, and that you still can't rely on it?
blablahas left
marcGe0rG, did you know that a normal user doesn't care about technical issues? ;)
blablahas joined
Ge0rGmarc: what's your point?
Ge0rGmarc: "inviter out of registrations" is one of many possible reasons to reject an account registration.
Ge0rGmarc: on a sane server, no users will ever run into it
marcAn invitation token MUST work if you received one
Ge0rGmarc: what if the server went down due to a nuclear bomb?
Ge0rGstill a MUST?
Ge0rGwhat if the server admin was fed up by dumb arguments and shut it down?
marcGe0rG, well, the server wouldn't respond in this case so it's fine I think
marcProbably the user will blame the ISP
marcThat's fine
Ge0rGmarc: "An invitation token MUST work if you received one" - there is no way on earth to enforce that.
marcGe0rG, I guess you know what I mean with this statement ;)
Ge0rGmarc: especially not if you issue time-limited tokens
Ge0rGmarc: I guess you don't :P
marcGe0rG, time limitations are known to users from many other services
Ge0rGmarc: so you agree that it's normal for a registration not to work always?
Ge0rGnormal in the sense that users will expect this to happen, from time to time
blablahas left
marcGe0rG, if the invitee followed the rules it shouldn't happen
marcGe0rG, and if the server is down for a minute if works after a minute
Ge0rGmarc: except the invitation email got greylisted for a day and the token expired. BOOM.
marcAnd nobody has to generate an other token
Ge0rGmarc: another token wouldn't even help if the inviter is out of invitations :P
marcGe0rG, yes, but that's out of scope sorry
marcGe0rG, depends on your policy
Ge0rGmarc: my point is: you can't enforce in the XEP that an invitaiton token MUST always work.
Ge0rGmarc: and if you accept that truth, you can make the overall flow easier and more consistent by removing a corner case.
Ge0rGnamely the corner case where your server rejects/downgrade the invitation token because of some internal counter.
marcGe0rG, yes, you can not enforce it but we shouldn't introduce confusing behaviour on purpose
Ge0rGmarc: I think it's more confusing if your server returns different invitations based on how often you asked
marcGe0rG, yes, let's block it completely then :D
Ge0rGmarc: I think it's more confusing if your server returns different responses based on how often you asked
marcGe0rG, I don't agree with this statement if you throw a warning or an error or something like that
blablahas left
marcGe0rG, 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
Ge0rGmarc: users get confused by different UI flows, not by different URLs.
marcGe0rG, UI flow for client-side PARS is different because you can not create an account for some reason
Ge0rGmarc: 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.
Ge0rGmarc: you can create an account, just not with the inviter's server.
marcGe0rG, " if other people who got invitations didn't use them"? -> "if all other people who got invitations use them"?
Ge0rGmarc: correct
marcGe0rG, sounds unpredictable for the invitee to me
marcAnd still you have to track the tokens after account creation
marcOr at least some counter for a user
Ge0rGmarc: you have to anyway
marcGe0rG, no, just store the token. If an account is created, remove it
marcNo other information is needed
zinidhas left
Kevhas left
Ge0rGmarc: what if the account registration would trigger another limit?
stefandxmhas joined
marcGe0rG, what limit?
Ge0rGmarc: total number of registrations per day for example
marcGe0rG, that should be included in the account/token generation process
marcGe0rG, of course you can configure your service for bad UX ;)
marcI think an account token should be considered as already registered account
marcFor the "account limitation policy"
Ge0rGmarc: I disagree
Ge0rGmarc: an account-invte token is as good as an already registered account, but a PARS+IBR token is just an option
Ge0rGyou can short-sell options
blablahas left
ralphmhas joined
marcGe0rG, correct, but account invitations shouldn't be blocked by other rules once they are issued IMO
Ge0rGmarc: yes, but account invitations are created by admins anyway.
marcGe0rG, we're talking about account invitations+PARS ;)
marcI think you know this ;)
Ge0rGmarc: wait a moment. I was talking about contact invitations with IBR-fallback
marcGe0rG, hm?
marcIBR = account invitation
Ge0rGmarc: account-invitation = server-admin sends xmpp://newuser@server?token to make the invitee register an account
Ge0rGmarc: contact-invitation = normal user sends xmpp:inviter@server?token;ibr to allow either contact subscription or IBR
marcGe0rG, IBR-fallback = invitier gives invitee the possiblity to create an account even if the server doesn't allow IBR, right?
Ge0rGmarc: right
Kevhas joined
marcGe0rG, yes, we're talking about the same thing with different terms :D
Ge0rGmarc: so you are talking about IBR-fallback?
Ge0rGa.k.a. PARS+IBR
Ge0rGa.k.a. contact-invitation
marcGe0rG, yes
Ge0rGmarc: 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
marcGe0rG, 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
marcSo we have no problem actually
Ge0rGmarc: client-side PARS fallback performs exactly the same task, just at different places.
Ge0rGmarc: server-side PARS+IBR vs PARS-only has different implications
Ge0rGmarc: 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
ZashGe0rG: Huh, only the admin can give out invites?
marcGe0rG, I know and I don't think that's good :)
marcZash, no
Ge0rGZash: only the admin can give out accounts
marcGe0rG, afk, just tell me why we don't use a fallback from PARS+IBR to PARS when a user reaches some IBR-invitation limit
Ge0rGmarc: because IBR-invitation limits don't make sense.
marcGe0rG, and explain me why we should store lots of information about users just to enforce account limitation during IBR
Ge0rGmarc: because account creation is the best moment to limit account creation.
marcGe0rG, why?
marcwhy doesn't it make sense
Ge0rGbecause until an account is created, you don't know whether it will ever be
marcYes, if the invitee uses PARS the inviter can issue more tokens
Ge0rGmarc: so now what you can do as the inviter depends on what your invitees do. Yay.
marcGe0rG, if you implement the policy that way, yes
Ge0rGmarc: 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
marcGe0rG, we have two options: "bad" UX for inviter or invitee
Alexhas left
Ge0rGmarc: that's not true. The bad UX for the invitee is inevitable
Ge0rGmarc: the good thing, it is only bad in corner cases.
ZashDo you have like user stories written down?
Ge0rGI'd like to write the specification down.
marcGe0rG, Yes, it's a corner case for both solution
marc+s
Steve Killehas left
marcand I think for your solution additional data needs to be stored on the server
Ge0rGmarc: maybe, maybe not.
sonnyhas joined
marcGe0rG, :P
efrithas joined
Ge0rGmarc: you need to store a counter on the user account anyway, if you want to limit number/time
marcGe0rG, but that's optional
Ge0rGand adding a counter of user-initiated IBRs is not very expensive
marcGe0rG, in your solution that's required
Ge0rGmarc: no, it's optional. You don't NEED to limit anything.
marcGe0rG, for my solution you use data which are necessary anyway
Ge0rGmarc: but your solution is limiting user behavior at the wrong end of the registration
ralphmhas joined
Ge0rGmarc: anyway, that doesn't matter much for the XEP. Let's move this thing forward.
marcGe0rG, why doesn't it matter?
Ge0rGmarc: because it is an implementation detail, mostly.
Ge0rGmarc: we still need to write an XEP
marcGe0rG, yes, but I would like to have an error response for such things in the ad-hoc command
marcThat's the point ;)
Ge0rGmarc: the ad-hoc command is allowed to fail for whatever reasons deemed inappropriate.
Ge0rGmarc: with standard error messages
marcGe0rG, oh no.. standard error messages
marcThey're not useful at all
Ge0rGmarc: but I still am convinced that it is wrong to let it fail.
archas left
archas joined
lskdjfhas joined
Ge0rGSo 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
edhelasI'm planning to do another PR on 0060 in the upcoming days
sonnyhas joined
edhelasto expose the access_model tag in the metadata
XSF Discussion - 2017-12-13