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 > http://www.xmpp.org/extensions/xep-0060.html#accessmodels) 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: > http://www.xmpp.org/extensions/xep-0060.html#subscriber-subscribe-error-payment Yes. > 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. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
