XSF Discussion - 2017-11-04

Hey, is somebody working on a XEP for user invitation? (see mod_invite of prosody)

marc, MUC invitation? or "roster"? or?

marc: have a look at [xep 379]

I was just about to mention that :)

https://xmpp.org/extensions/xep-0379.html

It doesn't create an account on a server, right?

It is just for adding a contact to the roster if I understand it correctly

mod_invite generates an invitation token and let's an user create an account on a non-public server

s/let's/lets

Ge0rG, correct? Just noticed that it's your XEP :)

marc: it's right.

marc: I'd like to leverage it for account invitations though

no idea how

I'm working on a POC for account invitations and would like to make a XEP for that

Invitations are too "complicated" at the moment IMO, at least for the normal "whatsapp user" :)

marc: so true

It shouldn' take more than a minute to create an account and start a conversation

Is somebody on 34c3 for some hacking? Will there be a XSF/XMPP assembly?

marc: I think so, there should be something in the SCAM section on the wiki

Ge0rG, yes, thanks!

marc: https://wiki.xmpp.org/web/34C3

marc, I agree

I’d be very interested in your ideas of the flow

ideally 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.

what jonasw said.

like a PARS token, but for IBR instead of for presence subscription

bonus points for allowing the token to also function as a PARS

yupp

I’d also like to have Pre-Authenticated MUC Join :)

(for members-only MUCs)

jonasw: what's wrong with mediated invitations?

when I don’t know the JID yet?

oh

jonasw: any reason why PARS can't do it for MUC join presence?

Ge0rG, members-only, you’d have to add the user

You'd still have to add the user somehow right? To generate the token

pep., 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.

Yeah I got that part. nvm I didn't get Ge0rG's sentence in the first place

I'd also be interested in whatever this leads to :)

One 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!

You mean sign up tomorrow?

jonasw, done ;)

jonasw [13:38]: > Ge0rG, members-only, you’d have to add the user The user adds the token to the join presence and is added instantly

If I have some time these days I'll make a small video of how it works (implemented in Gajim+Conversations)

And ejabberd

What's the membership election deadline? I don't want to risk getting kicked out of council because I forgot my membership application

marc: of how what works?

Well, still some missing parts and all very hackish but the idea should work very well

Ge0rG, the invitation "flow" :D

marc: yay for more "Easy XMPP"!

Ge0rG: November 21st

Yes, I would really see "easy xmpp"

marc: that's also a category on the wiki

Otherwise XMPP will never be accepted by end-users

marc: that's what I'm saying for years now

Ge0rG, I guess you'll help me with my XEP and the implementation then ;)

marc: yes I will.

Ge0rG, nice :)

marc: also related https://github.com/ge0rg/easy-xmpp-invitation

Ah cool

QR codes are nice for invitation, I already use it

marc: I think we can extend the http invitation link with an account creation token that allows you to register on a specific server

Yes

I already have this somehow

Afk, Ge0rG looking forward to work with you on this topic :)

I wish I had more time to actually implement things in yaxim

Ge0rG, now I get it, right

requires support by the MUC service

and PARS needs some more acceptance

jonasw: yes, do you see another way? Additional handshake with the inviting client?

Ge0rG, no

jonasw: PARS is blocked by lack of private pep storage

*in prosody

jonasw: in one of the widely deployed OSS servers

yes

I’m also not convinced that PEP is the right place for this.

I mean to push the topic further soon, I’m still lagging behind from vacation.

jonasw: whatever works on prosody 0.10 and will convince daniel is fine with me

jonasw: bonus points for solving MUC and account creation invitations in the same track

not sure this shouldn’t be different XEPs

but I think people complained that yet-another-custom-IQ-protocol is not desirabel

jonasw: as opposed to what?

private PEP

Right

I re-read the thread from april

I think the arguments for private PEP are convincing

(it allows easy client-side handling and server integration at the same time)

it would be great to have the token in the roster, too.... that’d allow clients to purge all entries created by a certain token

The only issue I have is the "unlimited count" for pars tokens

unlimited count is fine for me.

I can live with it, and having it in the roster is a great idea

lovely roster extensions which break things

#mix

pity people didn’t follow my suggestion for generic roster extensions

that would be handy now

I wanted to have some identifier for auto added roster items, the token can well be used for that

jonasw, why roster extensions when you can use private PEP?

different things

Flow: do you want to duplicate the roster structure in pep?

like a private PEP shadow roster with all you metadata from the extension

Ge0rG, possibly

I'm not 100% decided which approach is better

Flow, would probably work, yeah. except that you’d really want multiple items in that and PEP services aren’t good at that

but then again, thinks will probably break if you extends the roster

*things

I doubt that they will

so there is only this approach left

adding elements in foreign namespaces shouldn’t break things.

or the approach the MIX people went for

which is equally bad or even worse

Roster extensions are a sensible thing that we've been talking about for about a decade.

Kev, why don’t we have them and why is MIX inventing its own probably not really extensible protocol for that?

1) Reasons 2) I'm not sure what you're suggesting as the alternative. MIX is injecting a roster extension.

If we do roster extensions, can't we put MUCs there too?

Kev, re 2: right, I was confused I think

Off out, back later.

jonasw, 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

or maybe no trouble, but confusion at least

Flow, right, for PARS tokens it would be irrelevant though

jonasw, probably

for sure.

it doesn’t do harm if it’s ignored

Flow: do you think it will also break for normal roster items with extensions, as opposed to things like mix?

Ge0rG, my invitation is based on an adhoc command for token generation, the inviter can chosse contacts to be shared

these contacts are then added to the roster of the new account

I am now embarrased that I didn’t think of Ad-Hoc commands.

sounds not too complicated to me

jonasw, :)

marc, sounds like a solid approach

jonasw, cool, thanks! So I'm going to further improve my POC

since the account will be on exactly that server, it can of course handle the presence subcsription, no need for PARS

lovely

yes

marc, I’ll be happy to proof-read things and guide you through the XEP process.

and I think there is no privacy implication

since the inviter could send the jids to the invitee later as well

there may be if the token is lost, in the sense that all contact information which was shared server-side is exposed.

yes, until the token expires

jonasw, thanks for the offer!

but even in this case there is only the information that somebody invited an unknown person and shared some contacts

I think all we need is an opaque token, the server can implement any amount of logic when it's passed on

well, shared contacts could be disabled by the provider if this is an issue

And we need a robust out of band mechanism to transport it

I use XMPP URI and QR codes at the moment

works like a charm

this enables me in-app invitation

as fallback it generates an URL

Maybe contact sharing should be separated

marc: what's the URI format?

Ge0rG, well, it's not "defined" but something like xmpp:example.com?account;invite_toke=TOKEN

Sounds reasonable

Could be integrated into the landing page

yep, together with the QR code

Might need some information about the inviter, but then that's easy to fake

Well, my idea was, if that's required, that the server provides a simple REST API to gather information about the invitation

This could be done via the token as well

Well, for the landing page, of course

Information included in the URI would be nice but could be faked

Invitation 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

The landing page and the REST stuff is all optional and out of the scope of this XEP

If the landing page web server is implemented in the xmpp server itself, no REST API etc. is needed

Just for the case the landing page uses another service like lighttpd

marc: then the ad hoc command needs a way to find out the landing page link

can simply be returned in the result IIRC

What happens if I send a "chat" message to the full proxy JID of a MIX participant?

Ge0rG, 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

cf. https://xmpp.org/extensions/xep-0369.html#usecase-user-private-messages

this appears to contains resource locking logic

Ge0rG, yes, the landing page is returned by the adhoc command

marc, how does the signup work?

in-band or out-of-band?

Ge0rG, the result of the adhoc command is a landing page URL (optional) and a token

I'd just do IBR with an additional field stuffed somewhere

jonasw, that's not implemented at the moment but I would like to send a field like a captcha

IBR itself doesn’t really allow for custom fields

really? I thought I've read something about it in the XEP

ah right

data forms may be used instead

lovely

:)

Am I right that with MIX, a MIX-capable user server needs to keep in memory a list of all participants of all MIXes of all its users, online or offline?

Ge0rG, why?

(I don’t think so)

gotta go