Privacy and PSHB
JoeCascio
(is it?), then does this obviate PSHB from delivering protected
content, for instance the equivalent of a Twitter DM?
Thanks,
JoeCascio
Pádraic Brady
It's an interesting question. The problem with protected content whether on the publisher side (Hub must be authorised) or the Hub side (publisher must be authorised), and the same for the subscriber. I don't think it's something Pubsubhubbub can easily address within a specification since it's out of the scope of the protocol. However, there's nothing to stop Pubsubhubhub implementations from being open to authorisation schemes.
If you take Twitter as an example. Now Twitter doesn't advertise any Hubs - so there's no point assuming it can be a push Publisher, but let's say it could be an indirect Subscriber. By that I mean, an actual Pubsubhubbub Subscriber will accept Hub updates, repackage them, and use a Twitter Client to tweet them to Twitter (as whatever). If on the other hand you mean Twitter publishing messages (DM) elsewhere, it's not possible to a Hub. But a Hub can poll Twitter (like any other Twitter client), and send any discovered updates to all the registered Subscribers to that Twitter feed. Now if you were to implement this in a Hub, you'd hit the Pubsubhubbub spec's lack of authorisation mentions - but there's a way out. Twitter uses OAuth authorisation to it's API. Most OAuth clients let you build a HTTP Client from a valid Access Token (which handles authorisation with OAuth internally). A suitable generic flexible implementation of Pubsubhubbub would allow you to set a custom HTTP Client (mine for Zend Framework/PHP does). Adding 1+1+1, you can attach an OAuth enabled HTTP client to the Hub, and the Hub can now poll for any private Twitter feeds. It would require more effort of course, but it is possible.
So, in short, PSHB doesn't obviate anything from my perspective. So long as the specification doesn't obviously prevent the use of an authorisations scheme, then thay authorisation scheme can be applied with a suitable implementation.
My 2c at least ;)
http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative
From: JoeCascio <joec...@gmail.com>
To: Pubsubhubbub <pubsub...@googlegroups.com>
Sent: Saturday, August 1, 2009 9:55:32 PM
Subject: [pubsubhubbub] Privacy and PSHB
JoeCascio
So the PS hub would be authorized by the Twitter user (the person
"publishing" the DMs) to access their account to poll for DMs, right?
That would work, but authorization aside, it seems like polling
Twitter for DMs or regular updates so you can then push them might
solve the distribution problem, but not the polling latency problem.
It's an interesting design challenge nonetheless. Of course, a better
answer is to have Twitter implement a hub or series of them. It's my
guess we will see pigs fly before that happens anytime soon, but it's
still an interesting question from a design point of view. How does
PSHB address a publisher that pumps out 100 new updates a second to
tens of millions of subscribers? Also consider an Ashton Kucher-scale
publisher. How would one design a hub, or a series of hubs to
distribute 1,000,000 notifications in a few seconds every time he
updates?
Getting back to authorization I think it bears some thinking to see
whether it could be cleanly incorporated into the spec, or whether
it's best to leave it outside and solve it along the lines you've
suggested. Perhaps by end-to-end encryption and leave the servers out
of it??
JoeC
On Aug 3, 7:33 am, Pádraic Brady <padraic.br...@yahoo.com> wrote:
> Hi Joe,
>
> It's an interesting question. The problem with protected content whether on the publisher side (Hub must be authorised) or the Hub side (publisher must be authorised), and the same for the subscriber. I don't think it's something Pubsubhubbub can easily address within a specification since it's out of the scope of the protocol. However, there's nothing to stop Pubsubhubhub implementations from being open to authorisation schemes.
>
> If you take Twitter as an example. Now Twitter doesn't advertise any Hubs - so there's no point assuming it can be a push Publisher, but let's say it could be an indirect Subscriber. By that I mean, an actual Pubsubhubbub Subscriber will accept Hub updates, repackage them, and use a Twitter Client to tweet them to Twitter (as whatever). If on the other hand you mean Twitter publishing messages (DM) elsewhere, it's not possible to a Hub. But a Hub can poll Twitter (like any other Twitter client), and send any discovered updates to all the registered Subscribers to that Twitter feed. Now if you were to implement this in a Hub, you'd hit the Pubsubhubbub spec's lack of authorisation mentions - but there's a way out. Twitter uses OAuth authorisation to it's API. Most OAuth clients let you build a HTTP Client from a valid Access Token (which handles authorisation with OAuth internally). A suitable generic flexible implementation of Pubsubhubbub would allow
> you to set a custom HTTP Client (mine for Zend Framework/PHP does). Adding 1+1+1, you can attach an OAuth enabled HTTP client to the Hub, and the Hub can now poll for any private Twitter feeds. It would require more effort of course, but it is possible.
>
> So, in short, PSHB doesn't obviate anything from my perspective. So long as the specification doesn't obviously prevent the use of an authorisations scheme, then thay authorisation scheme can be applied with a suitable implementation.
>
> My 2c at least ;)
>
> Pádraic Brady
>
>
> ________________________________
Brett Slatkin
I took a stab at what support for private and authenticated feeds
would look like in PubSubHubbub in this thread:
http://groups.google.com/group/pubsubhubbub/msg/3108fe7fdc740482
Otherwise, your best bet right now is to use obfuscated feed URLs.
These are URLs that are hard to guess (i.e., the URL is a password).
When accessed over SSL they are reasonably secure in keeping the
content private. These can be used right now with Hubbub for
non-public feeds. In the future we'd like to have a full authorization
scheme as I describe above.
Let me know what you think!
On Mon, Aug 3, 2009 at 8:14 AM, JoeCascio<joec...@gmail.com> wrote:
> How does
> PSHB address a publisher that pumps out 100 new updates a second to
> tens of millions of subscribers? Also consider an Ashton Kucher-scale
> publisher. How would one design a hub, or a series of hubs to
> distribute 1,000,000 notifications in a few seconds every time he
> updates?
This is the "fan-out problem" that people talk about. It's hard to
solve. The simple approach is to incrementally send the notifications
to any subscribers at a sustained rate. So say we did 10,000 per
second; for the 1M subscribe case we'd need ~100 seconds to push the
updates to all subscribers. This indicates that the primary pivot here
is load versus latency.
Theoretically we could push 100,000 updates per second and get this
done in 10 seconds, but the amount of load that puts on our servers
(and HTTP connections) is so high that it's really not worth it.
Instead, we pick a load level we're okay with and then eventually
replicate the data out to all subscribers. That means that as your
feed gains subscribers you sacrifice latency for volume. This is the
reality of the situation. I believe it's no different on existing
services out there. The good news is Hubbub can handle this case in
theory-- I plan to further load-test our hub with the 1M subscriber
case to see how fast we can go.
Otherwise, it's good to keep things in perspective. For the 10,000
subscriber case, we can deliver all notifications in 1 second at this
same rate. So for practical situations, this scales just fine for the
vast majority of users.
-Brett
Pádraic Brady
http://blog.astrumfutura.com
From: Brett Slatkin <bsla...@gmail.com>
To: pubsub...@googlegroups.com
Sent: Monday, August 3, 2009 4:29:52 PM
Subject: [pubsubhubbub] Re: Privacy and PSHB
Brett Slatkin
If you wanna write up a little doc on how OAuth and Hubbub can work
together, that would be great. We should get a few different
authentication proposals together before we move forward on the
private streams functionality. I'm still an advocate of the absurdly
stupid and simple basic-auth-over-SSL approach, but I'd love to see
how easy OAuth could be.
-Brett