Open genseirin opened 5 years ago
Thanks for this idea. I'll check back with the team on the impact this could have. Until then I'd like to address your points:
Please note though that creators are unable to put the Flattr meta tag on various pages on which their content is shown (e.g. social networks such as YouTube or Twitter).
I'll pass this feedback on to the flattr.com devs because it sounds like this could be solved by making modifications to the dashboard UI.
The extension's algorithm is supposed to only flattr URLs which it considers valuable and only those are being sent to the server. If a page gets flattred against user's intentions we should first look into how we can improve the algorithm to alleviate the need to make manual adjustments from users or creators. Any information on cases of such misbehavior is therefore highly appreciated.
So keeping all of that in mind, what do you think about an optional meta tag that tells the extension not to flattr the current URL? (e.g. <meta name="flattr:enabled" content="blocked">
)
Thanks!
So keeping all of that in mind, what do you think about an optional meta tag that tells the extension not to flattr the current URL? (e.g.
<meta name="flattr:enabled" content="blocked">
)
Maybe that would help, although on WordPress (where I faced the situation) I wouldn't know how to insert a meta tag on a login page.
One addition:
I’d like to note that the opposite is also interesting: auto-include pages that do contain a Flattr meta tag. Especially pages that would otherwise be excluded because of their origin.
3. I see for example flattrs for lots of commercial (or public-funded) news sites. I think it would make sense to check if they are already on board - if not, it doesn't make much sense to count flattrs and report every page.
The extension doesn't know which flattrs are going to end up being paid out because that's being determined on the server at the end of the monthly cycle. Therefore that's a bit tricky to implement and potentially confusing or misleading because it could lead to the counter suddenly in- or decreasing if a creator claims or unclaims them until then.
Maybe that would help, although on WordPress (where I faced the situation) I wouldn't know how to insert a meta tag on a login page.
We have entries in our list that specifically prevent the extension from flattring "wordpress.com/log-in" as well as other non-content pages on multi-user platforms.
The meta tag could also be used to avoid flattring own pages (since it contains the user ID). Currently I need to disable flattring for my own sites manually.
That's a good point. While the extension doesn't determine who claims the current page, it could filter out at least those pages which have the user's own meta tag on them.
I’d like to note that the opposite is also interesting: auto-include pages that do contain a Flattr meta tag. Especially pages that would otherwise be excluded because of their origin.
That could be feasible for any pages that are not on our list. I'll look into that.
I’d like to note that the opposite is also interesting: auto-include pages that do contain a Flattr meta tag. Especially pages that would otherwise be excluded because of their origin.
That could be feasible for any pages that are not on our list. I'll look into that.
This includes 127.0.0.1, localhost, ipfs://example.com, and other origins that are currently unflattr'able. As long as there is a Flattr meta tag on the page, it should be Flattr-able. I didn't make that clear in my previous past-midnight comment.
The meta tag could also be used to avoid flattring own pages (since it contains the user ID). Currently I need to disable flattring for my own sites manually.
You don't actually have to do this. They're shown on the contributor dashboard but get filtered out at the end of the month. You can't actually Flattr yourself without involving two separate accounts.
That being said, I regularly delete my own self-flattering from the contributor dashboard.
I’d like to note that the opposite is also interesting: auto-include pages that do contain a Flattr meta tag. Especially pages that would otherwise be excluded because of their origin.
I also like that idea. People who sign up as creators won't have to wait until the list with domains is updated and reaches all the browsers. Earning automatic flattrs from the first day will be a huge motivation.
You don't actually have to do this. They're shown on the contributor dashboard but get filtered out at the end of the month. You can't actually Flattr yourself without involving two separate accounts.
That being said, I regularly delete my own self-flattering from the contributor dashboard.
I think that the user experience would be much better if that could be done immediately and automatically. But I agree that this problem should be solved on the web rather than in the extension.
PS: If automatic flattring can be decided by meta tag, you actually can get rid of the whitelist with all its issues about how to select the domains etc. The only exception will be podcasts, videos, Twitter and all sites that host multiple creators. Of course, Flattr will not get insights about sites that would have received flattrs if they were signed up, but I think it is more important to convince users with a consistent experience. Just my personal opinion.
Currently, when I enable flattring for a domain, all pages on that domain are being flattred. I would like to suggest an option in the extension so that web pages are only flattred if they contain the meta tag.
Benefits:
Creators could fine-tune which content can be flattred by omitting the Flattr meta tag
<meta name="flattr:id" content="foo">
on some pages. (For example on sign-in pages.)For contributors this options would help remove the clutter on their dashboards since they only see pages where their flattr actually counts.
This would also add an extra layer of opt-in privacy because not all URLs are sent over to the server.