Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Storing common publisher donation details #110

Open
tbranyen opened this issue Feb 16, 2017 · 10 comments
Open

Storing common publisher donation details #110

tbranyen opened this issue Feb 16, 2017 · 10 comments

Comments

@tbranyen
Copy link
Member

The publisher I use the most and would most likely want to give money to is Wikipedia. Turns out they already support the payment options we'd want to connect to. You can view them here: https://wikimediafoundation.org/wiki/Ways_to_Give

What if we stored this list of domains -> payment details and used in the case where we can't automatically detect the authorship?

{
  "wikipedia.org": {
    "paypal": "[email protected]",
    "coinbase": "44aa9355518928151be736fbd043236c"
  }
}

This would allow us to list ourselves in the Wikipedia donation section without them changing any code. We could also reach out to other content authors and try and prove to them this could be a great model for getting more frequent donations from causal users.

Thoughts?

@da2x
Copy link
Contributor

da2x commented Feb 16, 2017

Here is a theory …

If you want to attract thousands of publishers, all you need to do is to email the authors of some of these “how to monetize your website” blogs. They have large readerships of people wanting to monetize their websites of various levels of quality. Ask them to feature Tipsy, and ask them to “complete the simple setup process” (focus on the /tipsy.txt file, it’s way easier for low-skilled users) and then “ask their users to install the extension”. Should get the ball rolling.

Once Tipsy can claim to have “thousands of publishers signed up”, then it’s easier to attract new users as well as easier to get larger and more serious publishers to get in on action.

@da2x
Copy link
Contributor

da2x commented Feb 16, 2017

Is the current list of two publishers correct? Is that really all there is?

You can add ctrl.blog to the list if my website meets your quality standards for sites you wish to feature.

@tbranyen
Copy link
Member Author

Sure, but that is more of a long game right? If I wanted to start donating to Wikipedia today, I am unable to using this tool. If we don't want to store this kind of data, maybe allow the user to input their own values for the domain?

Basically I just re-installed Tipsy and I'm going to actively use it again, but I want to be able to do more with it than just look at my browser history.

@da2x
Copy link
Contributor

da2x commented Feb 16, 2017

If you want a built-in list, then store it on your own servers and download them periodically (over HTTPS, of course). Shouldn’t need to rebuild and redistribute the extension to update the list.

@da2x
Copy link
Contributor

da2x commented Feb 16, 2017

Basically I just re-installed Tipsy and I'm going to actively use it again, but I want to be able to do more with it than just look at my browser history.

Contact your favorite websites and tell them all about Tipsy! That is my plan.

@tbranyen
Copy link
Member Author

@da2x that is fine, you can bug users to drop the markup in their page, but some companies simply won't do this unless Tipsy has market-share and actual users. Do you have any objections to letting the end user configure payment details for a site?

@da2x
Copy link
Contributor

da2x commented Feb 16, 2017

Why would any user locate payment information themselves and plug it into Tipsy? Wouldn’t they just click on the PayPal button on the site in question?

The only value proposition would be if Tipsy curated a large list. Keeping that up to date would be time consuming.

@tbranyen
Copy link
Member Author

I was looking for objections to the idea, not necessarily alternative solutions. I, a user, would plug in information for sites I frequent that have donation information. Right now Tipsy is only useful for knowing how much to donate. If I don't remember the Wikipedia information off-hand that's an awful lot of steps to take to just send them a weekly $$$.

  1. Google the publisher + donation
  2. Find the page that has the info
  3. Go to PayPal and enter their information
  4. Go to Tipsy to find the amount to pay
  5. Send the payment
  6. Go back to Tipsy and mark the donation as complete

vs.

  1. Go to Tipsy and see how much to pay
  2. Information is already stored so go to paypal
  3. Pay and get redirected back to Tipsy

It's about user experience. Tipsy doesn't have much of that right now so it's not being used. We need to make it useful in order to get users.

@karger
Copy link
Member

karger commented Feb 16, 2017

This thread covers at least 2 distinct issues, one being alternative channels for distributing Tipsy info and another being how we market Tipsy. May be worth separating into 2 issues.

Regarding alternative channels: yes, we've always thought it would be great to have alternatives to editing a site file. Hard coding certain well known/important sites like Wikipedia makes a lot of sense as a way to rope them into the project involuntarily.

Another option we've discussed is to host a web site where people can enter their payment details. The challenge there is that we need to protect against lies---we don't want someone claiming payments from a popular site. So they have to prove they own the site. Of course, the normal way for them to do that is to place a specified token somewhere on the site. But if they can do that, they could presumably place the tipsy file too? So this might be silly. But perhaps there might be some cases where they can edit the site but can't put the tipsy file in the place where it is supposed to be? Are there other ways to prove site ownership?

Another option I could imagine would use DNS. Might it be possible to store payment info for a site in the DNS or MX record?

One place where the tipsy.txt file will have problems is on a multi-user hosted environment like old geocities. Then nobody owns the whole site so nobody can write tipsy.txt for it. Obviously people can use the meta tag but doing that for every page is a nuisance. Are there other cases where people own a "url prefix" e.g. wordpress.com/mysite and maybe have access to wordpress.com/mysite/tipsy.txt ? How might we know to check for that?

Turning now to marketing: the challenge in marketing Tipsy is chicken-and-egg. In my experience, the lack of any readers using tipsy undercuts the motivation for publishers to use it. And vice versa. I've approached quite a few publishers without much luck (thus only 2 signed up). So I'm all in favor of you all trying the same, but not confident it will work. Working from the other side, attracting people to use the extension, is also problematic when there is nobody to pay. I do think a database of known payment endpoints could help break open the vicious cycle---if we give people a way to pay wikipedia that doesn't require cooperation from wikipedia, then we may be able to draw in a significant user base without needing publisher buy-in (sic). And of course if we do get a large user population then publishers will become much more interested in participating.

I haven't tried the "monetize your site" blogs. Again, my big worry there is a backlash if publishers get excited about it then discover there are no payers. So maybe worth trying to build user based first with some hard-coded sites.

For this to really work, though, I think we need more than just one site. If tipsy only pays Wikipedia, then it isn't much more useful than me making my annual donation. Where Tipsy becomes really useful is in helping me to divide my payments, which is only interesting with more than one publisher.

@da2x
Copy link
Contributor

da2x commented Feb 16, 2017

Are there other ways to prove site ownership?

Three options:

  • DNS txt entry if DNSSEC is configured (it wouldn’t be)
  • Verification token over email to same-origin domain (assuming email was sent from a TLS server and received by a server with a valid certificate for that domain, almost no one has this)
  • Publish a verification code on the front page – for hosted CMS environment with access to publishing but not modifying the HTML (over HTTPS only, of course)

GitHub, Blogger, hosted WordPress.com, Tumblr, … they’d all work with the third option as they all give away subdomains.

Very few services host their user's content in subfolders of their main domain. This is a security risk (of course it is) as users and the service would share the same-origin; giving users access to more cookies and datastores than they should have.

Tipsy is chicken-and-egg.

Not really. It’s a higher cost proposal (litterally) to readers. If they don’t see their faovirte news paper and knitting blog, they loose interest. They’re ultimately who needs to be cared for as they’re the one bringing in the money. Propose to publishers first: then publishers should be asked to promote the extension to their audience. That way, readers who install it will have at least one website they like who accepts Tipsy. It’s not really chicken-and-egg, as the chicken will be displeased if there are no eggs to eat, but the egg can setup Tipsy and forget it for months before someone starts paying them every month.

I do think a database of known payment endpoints could help break open the vicious cycle

Luckily, PayPal has a subpage somewhere listing all the non-profits that accept PayPal donations. Knick the merchant IDs for those organizations off that page, and you should have a large list of non-profits, at least.

I think I can dig up a list of Bitcoin addresses and associated websites that should please the Bitcoin fanboys. (Though, it seems that all the Bitcoin community and news sites have signed up for Brave.com’s Bitcoin mincropayments in just the last month … so they’re already super-keen on any scheme that gets them more Bitcoin.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants