marcHey, is somebody working on a XEP for user invitation? (see mod_invite of prosody)
Flowmarc, MUC invitation? or "roster"? or?
Ge0rGmarc: have a look at [xep 379]
FlowI was just about to mention that :)
marcIt doesn't create an account on a server, right?
marcIt is just for adding a contact to the roster if I understand it correctly
marcmod_invite generates an invitation token and let's an user create an account on a non-public server
marcGe0rG, correct? Just noticed that it's your XEP :)
Ge0rGmarc: it's right.
Ge0rGmarc: I'd like to leverage it for account invitations though
Ge0rGno idea how
marcI'm working on a POC for account invitations and would like to make a XEP for that
marcInvitations are too "complicated" at the moment IMO, at least for the normal "whatsapp user" :)
Ge0rGmarc: so true
marcIt shouldn' take more than a minute to create an account and start a conversation
marcIs somebody on 34c3 for some hacking? Will there be a XSF/XMPP assembly?
Ge0rGmarc: I think so, there should be something in the SCAM section on the wiki
marcGe0rG, yes, thanks!
Steve Killehas left
jonaswmarc, I agree
jonaswI’d be very interested in your ideas of the flow
jonaswideally there would be something with a token in the URI which allows users to register immediately with a server from within the client even if the server doesn’t allow registrations otherwise.
Ge0rGwhat jonasw said.
Ge0rGlike a PARS token, but for IBR instead of for presence subscription
Ge0rGbonus points for allowing the token to also function as a PARS
jonaswI’d also like to have Pre-Authenticated MUC Join :)
jonasw(for members-only MUCs)
Ge0rGjonasw: what's wrong with mediated invitations?
jonaswwhen I don’t know the JID yet?
Ge0rGjonasw: any reason why PARS can't do it for MUC join presence?
jonaswGe0rG, members-only, you’d have to add the user
pep.You'd still have to add the user somehow right? To generate the token
jonaswpep., no, you generate the token and sedn the token to the user via an out-of-band mean. The whole point is that at the time of invitation, the user might not yet have an XMPP account.
pep.Yeah I got that part. nvm I didn't get Ge0rG's sentence in the first place
pep.I'd also be interested in whatever this leads to :)
GuusOne day for the deadline to apply for Board and Council. The current candidacy list is to short! If you're interested, please sign up now!
Link MauveYou mean sign up tomorrow?
marcjonasw, done ;)
> Ge0rG, members-only, you’d have to add the user
The user adds the token to the join presence and is added instantly
marcIf I have some time these days I'll make a small video of how it works (implemented in Gajim+Conversations)
Ge0rGWhat's the membership election deadline? I don't want to risk getting kicked out of council because I forgot my membership application
Ge0rGmarc: of how what works?
marcWell, still some missing parts and all very hackish but the idea should work very well
marcGe0rG, the invitation "flow" :D
Ge0rGmarc: yay for more "Easy XMPP"!
GuusGe0rG: November 21st
marcYes, I would really see "easy xmpp"
Ge0rGmade some videos of PARS back then
Ge0rGmarc: that's also a category on the wiki
marcOtherwise XMPP will never be accepted by end-users
Ge0rGmarc: that's what I'm saying for years now
marcGe0rG, I guess you'll help me with my XEP and the implementation then ;)
Ge0rGmarc: yes I will.
marcGe0rG, nice :)
Ge0rGmarc: also related https://github.com/ge0rg/easy-xmpp-invitation
marcQR codes are nice for invitation, I already use it
Ge0rGmarc: I think we can extend the http invitation link with an account creation token that allows you to register on a specific server
marcI already have this somehow
marcAfk, Ge0rG looking forward to work with you on this topic :)
Ge0rGI wish I had more time to actually implement things in yaxim
jonaswGe0rG, now I get it, right
jonaswrequires support by the MUC service
jonaswand PARS needs some more acceptance
Ge0rGjonasw: yes, do you see another way? Additional handshake with the inviting client?
Ge0rGjonasw: PARS is blocked by lack of private pep storage
Ge0rGjonasw: in one of the widely deployed OSS servers
jonaswI’m also not convinced that PEP is the right place for this.
jonaswI mean to push the topic further soon, I’m still lagging behind from vacation.
Ge0rGjonasw: whatever works on prosody 0.10 and will convince daniel is fine with me
Ge0rGjonasw: bonus points for solving MUC and account creation invitations in the same track
jonaswnot sure this shouldn’t be different XEPs
jonaswbut I think people complained that yet-another-custom-IQ-protocol is not desirabel
Ge0rGjonasw: as opposed to what?
jonaswI re-read the thread from april
jonaswI think the arguments for private PEP are convincing
jonasw(it allows easy client-side handling and server integration at the same time)
jonaswit would be great to have the token in the roster, too.... that’d allow clients to purge all entries created by a certain token
Ge0rGThe only issue I have is the "unlimited count" for pars tokens
jonaswunlimited count is fine for me.
Ge0rGI can live with it, and having it in the roster is a great idea
jonaswlovely roster extensions which break things
jonaswpity people didn’t follow my suggestion for generic roster extensions
jonaswthat would be handy now
Ge0rGI wanted to have some identifier for auto added roster items, the token can well be used for that
Flowjonasw, why roster extensions when you can use private PEP?
Ge0rGFlow: do you want to duplicate the roster structure in pep?
Flowlike a private PEP shadow roster with all you metadata from the extension
FlowI'm not 100% decided which approach is better
jonaswFlow, would probably work, yeah. except that you’d really want multiple items in that and PEP services aren’t good at that
Flowbut then again, thinks will probably break if you extends the roster
jonaswI doubt that they will
Flowso there is only this approach left
jonaswadding elements in foreign namespaces shouldn’t break things.
jonaswor the approach the MIX people went for
jonaswwhich is equally bad or even worse
KevRoster extensions are a sensible thing that we've been talking about for about a decade.
jonaswKev, why don’t we have them and why is MIX inventing its own probably not really extensible protocol for that?
2) I'm not sure what you're suggesting as the alternative. MIX is injecting a roster extension.
Ge0rGIf we do roster extensions, can't we put MUCs there too?
jonaswKev, re 2: right, I was confused I think
KevOff out, back later.
Flowjonasw, I think that it will cause a lot of trouble if clients see entities in the roster but don't understand the metadata found in the extension
Flowor maybe no trouble, but confusion at least
jonaswFlow, right, for PARS tokens it would be irrelevant though
jonaswit doesn’t do harm if it’s ignored
Ge0rGFlow: do you think it will also break for normal roster items with extensions, as opposed to things like mix?
marcGe0rG, my invitation is based on an adhoc command for token generation, the inviter can chosse contacts to be shared
marcthese contacts are then added to the roster of the new account
jonaswI am now embarrased that I didn’t think of Ad-Hoc commands.
marcsounds not too complicated to me
jonaswmarc, sounds like a solid approach
marcjonasw, cool, thanks! So I'm going to further improve my POC
jonaswsince the account will be on exactly that server, it can of course handle the presence subcsription, no need for PARS
jonaswmarc, I’ll be happy to proof-read things and guide you through the XEP process.
marcand I think there is no privacy implication
marcsince the inviter could send the jids to the invitee later as well
jonaswthere may be if the token is lost, in the sense that all contact information which was shared server-side is exposed.
marcyes, until the token expires
marcjonasw, thanks for the offer!
marcbut even in this case there is only the information that somebody invited an unknown person and shared some contacts
Ge0rGI think all we need is an opaque token, the server can implement any amount of logic when it's passed on
marcwell, shared contacts could be disabled by the provider if this is an issue
Ge0rGAnd we need a robust out of band mechanism to transport it
marcI use XMPP URI and QR codes at the moment
marcworks like a charm
marcthis enables me in-app invitation
marcas fallback it generates an URL
Ge0rGMaybe contact sharing should be separated
Ge0rGmarc: what's the URI format?
marcGe0rG, well, it's not "defined" but something like xmpp:example.com?account;invite_toke=TOKEN
Ge0rGCould be integrated into the landing page
marcyep, together with the QR code
Ge0rGMight need some information about the inviter, but then that's easy to fake
marcWell, my idea was, if that's required, that the server provides a simple REST API to gather information about the invitation
marcThis could be done via the token as well
marcWell, for the landing page, of course
marcInformation included in the URI would be nice but could be faked
Ge0rGInvitation links from third party systems are opaque as well, so this is not a priority for me. Having a rest API means we need a way to determine the url from the server name, which is not trivial
marcThe landing page and the REST stuff is all optional and out of the scope of this XEP
marcIf the landing page web server is implemented in the xmpp server itself, no REST API etc. is needed
marcJust for the case the landing page uses another service like lighttpd
Ge0rGmarc: then the ad hoc command needs a way to find out the landing page link
jonaswcan simply be returned in the result IIRC
Ge0rGWhat happens if I send a "chat" message to the full proxy JID of a MIX participant?
jonaswGe0rG, I think it’d behave just like a message sent to the actual JID of a MIX participant, except that it is relayed through the MIX