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

Kevin Smith kevin.smith at isode.com
Wed May 10 20:27:05 UTC 2017

On 10 May 2017, at 21:08, Sam Whited <sam at samwhited.com> wrote:
> 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.

FWIW, as both a server and client dev, I feel pretty strongly that the server is the place for this, and I wouldn’t want to implement all the logic in a client.


More information about the Standards mailing list