different hub for same topic if denied

[aaronpk]

6.2: “to indicate that the subscriber may retry subscribing to a different hub.topic”

For me, it would only make sense to indicate a different hub for same topic if denied.

---

From #127

[aaronpk]

hm, now that I'm re-reading this I'm not entirely sure of the intent of this.

Hubs may provide an additional HTTP [RFC7231] Location header to indicate that the subscriber may retry subscribing to a different hub.topic. This allows for limited distribution to specific groups or users in the context of social web applications.

@julien51 do you know what this sentence was intended for? Do you know if this feature has actually been used in the context of social web applications?

[julien51]

Basically think of it in the context of a social network where one distributes different data to different crowds. I have a profile on https://github.com/julien51.json that anyone could subscribe to, but Github may also "redirect" to say "https://github.com/public/julien51.json" if there is no way to identify the subscriber for example.

Yes I know it was used at some point but I cannot put my finger on it anymore 🙄 in exactly that context. By default the subscription would be to the "public" resource but if the subscriber was providing an API key, the hub was actually able to tell the subscriber to subscribe to a more complete resource.

I am not fully sure I understand the question by initial commenter. If the subscription was denied by the publisher, why would using a different hub be better?

[aaronpk]

Wait a second, does this mean the hub can send a GET request that contains a Location header? I don't think I've seen the Location header be used as a request header, just as a response header. I feel like this needs to be clarified in the spec if that's the case, since it took me several readings to finally realize that.

Also I don't have a test for this in https://websub.rocks since I didn't even notice this "feature". I'm not sure how to proceed here. Will need to bring this up on the next call.

[aaronpk]

We discussed this in today's call, and we need more information from anyone who has implemented a hub as to whether this is something they have implemented or would potentially implement. If you're tagged in this comment, it's because you submitted an implementation report for a hub.

@mblaney @barryf @julien51 @Gargron @hashinclude @marten-de-vries @twitch-jordanpotter

The scenario is the following: A subscriber attempts to subscribe to https://example.com/profile/aaronpk but that URL is only accessible to authenticated users. The hub rejects the attempt to subscribe to that URL, but indicates that the subscriber can subscribe to an alternate URL instead, https://example.com/public/aaronpk, which it does by sending a Location header in the request that tells the subscriber the subscription was denied.

There may be other uses for this mechanism as well. Have any of you either:

• implemented this feature in your hub?
• think this would be something you would be likely to implement if your hubs are used for private or limited-audience content?

[mblaney]

I haven't implemented this, but would like to implement private subscriptions at some stage. If I did, I don't see a compelling reason to redirect unauthenticated users to a public url.

[marten-de-vries]

[Have you] implemented this feature in your hub?

Flask-WebSub does not support redirection to alternative topic URLs.

[Do you] think this would be something you would be likely to implement if your hubs are used for private or limited-audience content?

If it matches someone's use case, I'd be happy to accept PRs. I do currently 'support' private content subscriptions in a (currently non-public) project by simply having the hub check if the user's session is authorized to access the topic url. This uses the same session logic of the rest of the application. I guess you could see it as an implementation of:

Subscriptions MAY be validated by the Hubs who may require more details to accept or refuse a subscription.

For this specific project, I do not redirect to public URLs if subscription validation fails. Automatically subscribing to the new URL would just lead to confusion as non-public data would be missing, and while I guess the subscriber could ask the user for confirmation before retrying, I don't need functionality like that in my application.

[nightpool]

Mastodon does not implement this. I generally concur with @marten-de-vries's points about this being a confusing user behavior. We currently only send public information over WebSub and don't really have any immediate plans for making private subscriptions work.

[barryf]

My hub doesn't support this alternative topic URL approach. I'd consider adding the feature if there were use cases, but right now it's intended for public URLs.

[twitch-jordanpotter]

Twitch's hub will support topics for public data (e.g. a user's online status) and private data (e.g. a user's private messages). Naturally, subscription requests for private data must be accompanied by an authorization token.

However, to be consistent with our API, there will be a few topics that act differently depending on whether an authorization token is provided when subscribing. Thus, the same topic can have multiple behaviors, depending on the existence of an authorization token!

For example, the https://api.twitch.tv/helix/users API endpoint returns a user's public data. However, if an OAuth token is provided with the user:read:email scope, the user's email is also included in the response. (documentation link)

To mirror our API, our hub must send different notifications for the https://api.twitch.tv/helix/users topic depending on whether authorization was provided when subscribing.

Thus, with our setup, I don't feel this feature matches Twitch's requirements. That said, I definitely appreciate the objective that's trying to be fulfilled!

[aaronpk]

Thanks for the feedback everyone, super helpful. On today's call, the group resolved to drop the feature with the following resolution:

Group does not think we need another PR / CR on #138 since it does not affect implementations by dropping the feature

[aaronpk]

The editor's draft has been updated to reflect this change. https://w3c.github.io/websub/