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

Sam Whited sam at samwhited.com
Wed May 10 20:08:52 UTC 2017


On Wed, May 10, 2017 at 2:29 PM, Daniel Gultsch <daniel at gultsch.de> wrote:
> IMHO the hypothetical service operators who maintain their own service which
> are self-branded are very welcome to step forward now and try to get their
> use case covered but keeping them in mind without knowing who they are is a
> waste of time.

As usual I'm still specifically thinking of the HipChat Server
perspective (although my work hat is firmly off right now), but maybe
it's wishful thinking to think we'll encourage larger "customers" like
this by designing for their use case from the start. Regardless, if we
can be flexible but not introduce unnecessary complexity, which I
think this does, it seems like a good idea to me.

> If we can agree (we don't necessarily have to) that my approach is simpler
> and easier to implement and covers *our* use case I don't see why would
> should add complexity for users who don't even bother to read the mailing
> list.

I don't think it is simpler though, is it? It requires a lot of "extra
stuff" even if it's relatively easy to implement to do all that
hmac-ing and hashing, and it's more places that clients could
accidentally break things and introduce incompatibilities. This may
mean they're not following the spec, and it might be "their problem",
but if we can make it less likely to happen that still feels better to
me. Doing it almost entirely on the server (with the client only
having to learn about a few new IQs) means the tokens could be as
simple as storing some random hex encoded data wherever they normally
store things. This sounds much simpler to me (though of course, the
option for more complex setups also exists).

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.

—Sam


More information about the Standards mailing list