Monica,
Thanks for the feedback. We're looking at Activity Streams as one form
of content across this hub and plan to have a modular place to plug in
aggregators and other queryable components, as you mention. But we do
still want PuSHEE to function as a basic PuSH hub as well, with the
OAuth2 protections and arbitrary content. We were planning on trying to
move forward based on your drafts, which get to many (but not quite all)
of our use cases. It was my hope that the PuSHEE team could help the
community finish and finalize these specs so that PuSHEE doesn't end up
off on its own fork of things.
I think a virtual meeting would be very useful to help kick things off.
We can host a phone bridge at MITRE fairly easily for people to call in
to, with some screen sharing capability. Who would be interested in
joining in? Let's try to pick a date and time and I can post connection
details back to the list here.
-- Justin
On 6/22/2011 6:21 PM, Monica Wilkinson wrote:
Hi Justin,
Thanks for sharing details about the PUSHee project.
I gave your spec some thought and have concluded that your use cases
more closely aligns to the requirements for an Activity Streams
Aggregator or Engine than a simple HUB
An activity streams aggregator or engine would allow clients to push
and fetch activities including subscribing to get fat pushes.
When pushing an activity, the source as well as other details such as
privacy would be stored in the AS Engine Store.
An AS Engine would also allow you to query the catalog of streams
available to you(based on your credentials) and add new streams(data
sources).
This is very close to how Socialcast works for example.
I outlined some of the concepts for this in a spec called activity-api
which relied on some basic enhancement to PuSH which I documented here
http://code.google.com/p/pubsubhubbub/wiki/Pshb_OAuth2 and
http://code.google.com/p/pubsubhubbub/wiki/ArbitraryContentTypes
Would there be interest in having a virtual meeting to discuss this ?
On Thu, Jun 16, 2011 at 2:36 PM, Blaine Cook <[email protected]
<mailto:[email protected]>> wrote:
I, for one, support replacing the hand-rolled token stuff with "OAuth
2"; it probably makes the spec a tiny bit more complicated to
implement in practice, but in theory (i.e., the long run) it probably
makes it easier, and certainly future-proofs things, at least compared
to the current PuSH spec.
b.
On Jun 16, 9:16 pm, Justin Richer <[email protected]
<mailto:[email protected]>> wrote:
> The PuSHEE project is getting to the point of us building in an
> authentication and authorization layer to the system, and we're
planning
> to build this around OAuth2. I would like to gather comments
from the
> PuSH community in how to move this forward. I saw an initial
draft on
> adding in OAuth support and a content-agnostic discovery
mechanism, and
> we'd like to help move both of these forward, since they're both
> problems that we need to solve.
>
> We're looking at several authentication points:
>
> * Client to hub: is this client allowed to read this feed?
> * Feed to hub: Is this hub allowed to ping this hub?
> * Hub to feed: Is this hub allowed to broadcast this feed?
>
> The first two are fairly easy, but the third gets tricky, and we're
> looking at using JWT formatted OAuth tokens to allow for easy remote
> checking on feed publisher's side, or by implementing the
proposed OAuth
> token check endpoint that's being passed around.
>
> How many of these can replace existing auth checks in the PuSH spec,
> like the hub reply nonce and secrets? Seems like we might be able to
> move some of this into a profile of OAuth instead of something built
> just for PuSH. This is to say nothing of the signing mechanism,
which
> could use EHL's OAuth2 MAC proposal or Magic Signatures.
>
> We're also looking at building an API for registering feeds to a hub
> which would require auth as well. The question here is whether this
> ought to be rolled into PuSH or just stand as a separate PuSHEE API.
>
> -- Justin
