Support for PubSubHubbub on both publisher and Subscriber sides?

[superfeedr]

Hey,
It would be awesome if I could import all my other feeds... using PubSubHubbub!

[ozten]

I totally agree.

I've spent some time researching http://code.google.com/p/pubsubhubbub/wiki/Companies but I'm still not clear on SuperFeedr or the other's data retention policies. It's on my TODO list, but I'd love your help.

Design Goal:

1. default config uses
   1a) self-hosted PubSubHubbub or
   1b) 3rd party hosted that doesn't retain any data
2. Easy Config option to use SuperFeedr [1]

Config 1 is for someone who doesn't want to introduce an intermediary which caches/retains data.

I'm familiar with SuperFeedr and think it's awesome. However part of this experiment is working through FOSS cloud data/privacy control.

I'd love your take on this.

[1] http://superfeedr.com/documentation

[superfeedr]

Hey Otzen,

What do you call "data-retention"?
In both cases (subscriber or publisher), we allo you to export all your data from Superfeedr. What's the point of promoting an open protocol if you can't access/export your very own data?

I'm not sure what use case your describing here :(

If you want the Sudosocial app to publish content, well, you should ask anyone who install the app under their own domain to choose a hub. For now, it's either Google's Reference hub or a Superfeedr hosted hub. You know which one I prefer :D
Then, allow the user (in some kind of settings?) to enter their hub url. The app should then add the discovery part of the protocol to the feeds, and ping the hub whenever the feed(s) is(are) updated. Easy!

As for the "subscriber" use case. I guess you can only allow import from PubSubHubbub enabled feeds. (you fetch the feed once, get the link(s) to the hub, and subscribe to any feed mentioned). If you actually want to subscribe to other feeds (not PuSH enabled), that's a bit trickier, because this means somebody would have to open a Superfeedr subscriber account (and eventually buy credits for the notfications).

I hope this helps!

[ozten]

I think this concern is for non-PuSH and PuSH with a PubSubHubub site.

Data data-retention means that a PubSubHubub would keep the data from the feeds for later analysis and aggregation. Example:

So subscribers would register feeds X, Y, and Z. Once Updates were published to say X you'd ping all subscribers that X had some updates (with a diff or new entries).

If the PubSubHubub implementation kept the contents of the feed X, Y, and Z for later analysis and aggregation.... then they would be retaining the data. Examples of useful analysis would be "trending topics", correlating links popularity, or correlating the popularity of keywords to shopping verticals.

Purely exporting w/o any caching or data retention is totally cool if it's part of the privacy policy of a PubHubSubub provider. Of course a sudoSocial instance wold store the data so that it could be republished in a stream. This is because the sudoSocial app is under the control of the end-user and the PubHubSubHubub app is an intermediary ( or under the control of the end-user).

[ozten]

I think this concern is for non-PuSH and PuSH with a PubSubHubub site.

Sorry I mean non-PuSH feeds.

I realize the goal is to have only a few hubs polling non-PuSH feeds, so the network scales better. My question is... in practice (and TOS/License) do any hubs retain data?

What is a setup that meets this criteria?

[superfeedr]

So, I think there is a mis-conception here, hubs are not polling feeds. It's just the superfeedr one which does it. Again, as I told you, our hub doesn't retain any data.

You would need to have a superfeedr account for each installation of sudosocial to get this working fine :)

[ozten]

Again, as I told you, our hub doesn't retain any data.

Sorry, I missed this in your first comment. That is great news.