[Standards] Proto-XEP: Pre-Authenticated Roster Subscription

Daniel Gultsch daniel at gultsch.de
Wed May 10 20:45:47 UTC 2017

2017-05-10 22:08 GMT+02:00 Sam Whited <sam at samwhited.com>:

> All this being said, I could sway either way at this point, and as an
> actual client developer you probably have a better perspective on what
> makes the most sense for the client ecosystem, so I defer to your
> knowledge on what's best here.

I actually was trying to make this easier for the server developers. I was
assuming that managing multiple tokens in a database is more complicated
than doing some quick calculations on one.

One more argument for being able to generate new tokens based on a secret
in a PEP node is, that once I have that secret cached (because it was sent
to me at the beginning of the session) I can create tokens at any time
without needing a server connection right then. I can very easily come up
with a lot of scenarios in which I want to show a QR code to someone when I
don't have a connection to the server (session is hibernating) or only a
very lagging one. Or in other words I would like to avoid a spinning wheel
'generating QR code / requesting token' before being able to invite someone.

Anyway I think my arguments are made and now I guess it's up to Georg to
decide which way he likes to go with his XEP.

My main concern with current PARS is only that I strongly believe that this
should be a server side XEP and I think this thread has shown that at least
on this point there is a strong consensus. How exactly this becomes a
server-side XEP doesn't actually matter to me personally. I'd implement

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170510/8db1db56/attachment-0001.html>

More information about the Standards mailing list