If a subscriber doesn't visit any of our existing partners, then we don't pocket that money which was intended for websites. Instead, it's set aside as a fund for helping new websites to join, with a particular priority on those sites that our subscribers use the most.

It may not be so bad if all of a subscriber's money goes towards a single publisher. We measure rates in terms of RPM. In such a circumstance, that single publisher is receiving an excellent RPM, and that gives us a good argument for convincing new websites to join.

As you can imagine, there are many things on our to-do list -- but a list of participating sites seems to be frequently requested, so that needs to move up in priority.

A list of participating sites should be your absolute number 1 priority. Like, a call away.

It is what I buy on your page.

> If they have no partners, they still collect money, but have no one to give it to at the end of the month, so they'll have to keep it.

IANAL, but my suspicion is that the law of trusts will make this ugly, unless they write "we get to keep it" into their TOS.

My own approach is to levy a fixed percentage and only pay out to participating sites. Readability tried to do the whole accumulate-for-not-participants as a way to try and create dangling carrots for publishers.

It didn't work: it just tied up a bunch of cash, because finding out who to contact for a lot of websites is difficult. Add to that the relatively small amounts of cash held for a given website, spread across many sites, and it would've created a helluva mess.

Disclaimer: I'm working on a competing product.

Would you mind sharing the basic premise of your product. I'm also trying to create some partnerships for a similar product.

Well it's the same general premise everyone stumbles on when they think about the problem for more than a few minutes. I call it "microsubscription".

Pay a service a fixed monthly amount. That service follows you as you visit participating publishers. At the end of the month, the service divvies up your payment amongst publishers based on some kind of formula, typically proportional to visits, clicks, time-on-site etc.

As I said elsewhere, the major technical problem has typically been that it's very easy to attack such schemes at the browser or at the publisher in order to create "visit multiplication". The scheme I designed relies on each of three parties -- a browser, a publisher and an authentication server -- providing independent verification of a particular network transaction occurring. Lashings of crypto, essentially.

My first protocol design, the subject of an honours dissertation, was hilariously broken. My second design was a ground-up redesign and independently reviewed by a fairly decent cryptographer.

I generalised the design so that any application protocol with some kind of control channel could be fit into the model.

I intended to create a scheme where users could avoid ads, pay for sites they like, get an easy pass through paywalls, without cheating and without user trackability.

None of this solves the fact that there are non-technical considerations that will probably be far more influential on the final outcome, barring a dramatic uptick in fraudulent activity souring the pot for my competitors. Google can get around this with their existing talent and technology for sniffing out fraud. The rest of us must make do with better protocols.

> Google can get around this with their existing talent and technology for sniffing out fraud. The rest of us must make do with better protocols.

To defraud webpass etc, you need to be able to sign up as a creator, so if they're not interested in signing up the world (as most adtech players are), they can probably get pretty far just by partnering with reputable sites and forcing them to track and reveal which portions of their traffic is sourced vs organic.

At some point they'll probably want to sign up the entire web too, but by that point they should be large enough to warrant buying the tech from a 3rd party fraud verification provider or build their own in house.

I will say that, knowing what kind of fraud goes on in advertising, I am skeptical that a new protocol would do much besides adding an extra (static) hurdle for fraudsters.

You might have already considered it, but as a potential user I'd like to have the chance of adjusting the percentages at each billing period (month for example) to avoid rewarding sites that use tricks to increase page count or other metrics.

By default, percentages go to each visited site as determined automatically by your service.

I'd also like to veto certain publishers, to avoid giving them money when landing there from obscured redirections or by accident.

Of course, if I veto a site then I would not get privileged access to it. That's fine.

That might be at odds with your three-party verification scheme; this is just a suggestion in case it might be useful.

I hadn't considered adjusting percentages, but I had considered allowing people to complain about and/or exclude websites from payment (veto, in your term).

Otherwise my inclination is to stick to a formula, because you have to balance the interests of users and providers for a network effect to form.

I'm trying to do this too but I have a way in that doesn't involve too much capital... Maybe we should have a chat?