-
Notifications
You must be signed in to change notification settings - Fork 9
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
Comments
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. |
Is the current list of two publishers correct? Is that really all there is? You can add |
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. |
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. |
Contact your favorite websites and tell them all about Tipsy! That is my plan. |
@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? |
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. |
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 $$$.
vs.
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. |
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. |
Three options:
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.
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.
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.) |
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?
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?
The text was updated successfully, but these errors were encountered: