[Standards] Proto-XEP: Pre-Authenticated Roster Subscription
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...
More information about the Standards