<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-05-10 22:08 GMT+02:00 Sam Whited <span dir="ltr"><<a href="mailto:sam@samwhited.com" target="_blank">sam@samwhited.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
All this being said, I could sway either way at this point, and as an<br>
actual client developer you probably have a better perspective on what<br>
makes the most sense for the client ecosystem, so I defer to your<br>
knowledge on what's best here.<br></blockquote><div><br></div><div>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.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>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 both.<br><br></div><div>cheers<br></div><div>Daniel<br></div><div><br><br></div></div></div></div>