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?