[jdev] pubsub and paid for content
stpeter at stpeter.im
Wed Apr 2 12:21:29 CDT 2008
Roelof Naude wrote:
> hi all,
> we are currently brainstorming about pubsub. some of the content that
> one may provide, needs to be paid for, e.g. live share price updates.
Cool, we'll finally get to use the <payment-required/> error. :)
> (most providers can provide a delayed feed for a fixed fee. but why
> settle for a delayed feed if we can get a live feed?)
> what would be the best practice to allow only paid subscribers access to
> such content?
In general I think you would associate someone's JabberID with your
database of paying customers. If someone attempts to subscribe to a
for-pay node but they have not paid for access to that node, you would
return a payment-required error. Probably you would use "leased
subscriptions" as outlined in XEP-0060 -- e.g., a subscription lasts for
1 year and then you must renew.
> one of the ideas we are floating currently is the following:
> 1. provide a bot/component so that users can register with it. component
> would be preferable, as most components (or gateway components provide a
> register functionality). additionally an out-of-band registration
> process may be provided, e.g. website.
> 2. this component/bot would be the node owner when creating pubsub nodes
> and can authorize subscription requests. (accessmodel = authorize
I don't see why you'd need to make such a bot the node owner, but
interacting with a bot might seem more natural to end users.
> 3. additionally such a component/bot could send notifications when funds
> are running low, e.g. only 5 messages left
That's the leased subscription concept. But you could certainly send
additional messages, poke the person via SMS, or whatever.
> 4. subscription requests to paid for content when funds are inefficient
> will receive the payment-require error message:
> topping up your virtual pubsub wallet could be handled by:
> 1. visit above website with your credit card
> 2. send a premium rated sms (mxit does the same thing)
> 3. provide some other out-of-band payment options (eletronic transfer
> etc. this of course will hardly be real-time).
> are any other options or caveats that we should be aware of?
Not that I know of. Good luck and let us know how it goes. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the JDev