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]> 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]> 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 >
