Closed helmus closed 9 years ago
It would also be cool if the user can just click a user name in the comment section to block it immediately locally and then after review include it in the global blacklist.
I'm afraid the report button would be abused.
Sending a pr or opening an issue obviously doesn't scale that well...
Works quite nicely for now.
The best solution would be to have some kind of blacklist API where you could give permissions to some users to edit the list and the list would then be availabe in JSON format.
I could do something like that in PHP. El nov. 25, 2014 11:34 AM, "Primož Hadalin" notifications@github.com escribió:
Maybe you could set up some lightweight backend at heroku or something ?
What for?
It would also be cool if the user can just click a user name in the comment section to block it immediately locally and then after review include it in the global blacklist.
I'm afraid the report button would be abused.
Sending a pr or opening an issue obviously doesn't scale that well...
Works quite nicely for now.
The best solution would be to have some kind of blacklist API where you could give permissions to some users to edit the list and the list would then be availabe in JSON format.
— Reply to this email directly or view it on GitHub https://github.com/hadalin/chrome-hidefedora/issues/17#issuecomment-64407650 .
If it makes things easier I can host the json file on my server and we could setup some kind of submission page. Or simply it does a git pull every so often. On Nov 25, 2014 9:34 AM, "Primož Hadalin" notifications@github.com wrote:
Maybe you could set up some lightweight backend at heroku or something ?
What for?
It would also be cool if the user can just click a user name in the comment section to block it immediately locally and then after review include it in the global blacklist.
I'm afraid the report button would be abused.
Sending a pr or opening an issue obviously doesn't scale that well...
Works quite nicely for now.
The best solution would be to have some kind of blacklist API where you could give permissions to some users to edit the list and the list would then be availabe in JSON format.
— Reply to this email directly or view it on GitHub https://github.com/hadalin/chrome-hidefedora/issues/17#issuecomment-64407650 .
If it makes things easier I can host the json file on my server
What's the uptime of your server?
You would need some sort of backend if you would want to allow users to update the blacklist from the app.
I actually guarantee you the report button will be abused, heavily, that's why you need to review the reports. And only show them for review after 2 or more people report the same user name. But for the reporter, the block button should work immediately on his machine only.
Having a commit every time the resource file is updated just doesn't make sense. Your commit history is cluttered with commits that just say "Add fedoras", that's just impractical use of a git repo. This file needs to be out of the repo, or somewhere in a db, so that you can curate it in a more flexible way, even if you don't want to integrate a report button.
@helmus I agree about having the file outside the repo.
The best solution would be to have blacklist as a service. Something like myblacklist.something where you could create your own list, assign people to it who could edit it and whole review thing.
The service should have good uptime though. Maybe CloudFlare backed.
Here is my hosts uptime for the past 6 months:
The downtime there has always been caused by me doing some kind of maintenance on the server, never from my hosting provider itself.
My server is behind Cloudflare.
The app shouldn't be depended on a backend system to function. It should store the list locally and update it at a certain event / interval. That way functionality is retained if the service is not available.
Yes, it should locally store the json file and then maybe once or twice a day grab the latest json file from the server.
The profile id's could be stored in a MySQL database and could be retrieved via calling a PHP page that outputs to JSON. This would mean we could store the data in a well laid out manner and give it to the client anyway needed.
It should store the list locally
So you can update chrome extension's local resource files without updating the extension?
So you can chrome extension's local resource files without updating the extension?
I believe Adblock does this with its list. Stores locally and updates it every so often.
I don't know about that, but this seems like it should do the trick:
https://developer.chrome.com/apps/storage
Keep in mind, it's "a series of tubes".
Ok, will look into it.
I have made a Stackoverflow question about it.
Awesome
Neat
It'd be cool the update list whenever you open a youtube page. Nice thing about current approach is that once you push the changes the update is instant.
If the extension gets more popular I can see Github having some problems with them being used as the backend host :P.
Ok, if that happens, we'll use your server.
Updating the resource file doesn't feel like the right approach. Chrome.storage feels like a much better solution.
@hadalin You could still maintain that update interval when the list is curated somewhere else. Just use local storage as a cache you hit first, that will have a faster response time and it makes sure the app will continue to work if the backend is down.
Github will never complain about that. Not even sure who's trolling now...
Yeah I think @helmus is right about using the Chrome.storage. Wasn't trying to troll about the Github thing, but I feel like they may have a problem with it if it was really big, but it probably won't become a problem.
But the chrome.storage would definitely be faster than getting it from a url.
@helmus you could probably code this up and make a pull request for it I am assuming? That is of course if @hadalin would be for it.
I could look into it, NP.
@Fogest , Ok I see your point. The file size limit at github is 100MB, but it doesn't even matter because the file shouldn't be even be in the repo in the first place.
That's why the version is not 1.0 yet ;)
It's already released, so it probably should be 1.0 -> http://semver.org/spec/v2.0.0.html
@helmus I am not referring to file size, I am referring to bandwidth use. Github has a hosting option, and it is not being used. rawgithub is not to be used for hosting.
@Fogest, package managers like npm and bower ( and many more ) put a strain on githubs bandwith that is literally millions times bigger then what this single app will ever achieve, even with thousands of active users. Then again, the file shouldn't be in the repo, so this discussion isn't very useful...
Yes, I am just saying though, an alternate solution should be used.
Ok, the latest version now uses chrome storage to store the blacklist locally.
@hadalin nice!
The question remains though. Where to put the blacklist and how to simplify the process of adding new fedoras without getting spammed?
I have no problem with hosting this on my host. I can even make a little front end to submit, and a spot to review submissions. Then it can generate a json from that.
You said you use CloudFlare. When you update something on your site, how long does it take CloudFlare to update?
That depends on the caching options I set. Right now dynamic content such as a json page would be instantly updated. Only things like images and javascript is cached right now.
Neat. Well then I wouldn't mind you figuring out how to handle this reporting thing.
Okay I will start to work on the code and let you know when I have something to show. Can't promise it will look nice at the start. On Nov 25, 2014 3:46 PM, "Primož Hadalin" notifications@github.com wrote:
Neat. Well then I wouldn't mind you figuring out how to handle this reporting thing.
— Reply to this email directly or view it on GitHub https://github.com/hadalin/chrome-hidefedora/issues/17#issuecomment-64468029 .
My site is http, YouTube uses https, will there be mixed-security issues from Chrome that will block it?
Justin V
On Tue, Nov 25, 2014 at 3:52 PM, Justin Visser fogestjv@gmail.com wrote:
Okay I will start to work on the code and let you know when I have something to show. Can't promise it will look nice at the start. On Nov 25, 2014 3:46 PM, "Primož Hadalin" notifications@github.com wrote:
Neat. Well then I wouldn't mind you figuring out how to handle this reporting thing.
— Reply to this email directly or view it on GitHub https://github.com/hadalin/chrome-hidefedora/issues/17#issuecomment-64468029 .
Don't think so.
Are you sure? I believe I have had issues with this in the past but it could be different. You could try swapping where the getjson is pulling from to some non HTTPS URL and see. On Nov 25, 2014 4:24 PM, "Primož Hadalin" notifications@github.com wrote:
Don't think so.
— Reply to this email directly or view it on GitHub https://github.com/hadalin/chrome-hidefedora/issues/17#issuecomment-64473371 .
I can. Tomorrow.
Btw, how do you plan on reviewing on possibly quite large number of submissions?
There will be a list of users with links to Google profiles and ids and then you hit approve or reject like reddit. On Nov 25, 2014 4:30 PM, "Primož Hadalin" notifications@github.com wrote:
I can. Tomorrow.
Btw, how do you plan on reviewing on possibly quite large number of submissions?
— Reply to this email directly or view it on GitHub https://github.com/hadalin/chrome-hidefedora/issues/17#issuecomment-64474287 .
@Fogest you were right
Mixed Content: The page at 'blabla' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'blabla'. This request has been blocked; the content must be served over HTTPS.
I do not support https on my host right now :/.
@Fogest I can provide you with a valid wildcard certificate if you want one. ( Free of charge )
@helmus If that is something you'd like to do, then I would be happy to accept that offer.
I'll do it if you fix this typo:
@helmus haha, I have fixed that typo, thank you! Was up working on that late at night and just put it up a couple days ago.
A verification code has been sent to
Please forward it to:
Maybe you could set up some lightweight backend at heroku or something ?
It would also be cool if the user can just click a user name in the comment section to block it immediately locally and then after review include it in the global blacklist. Sending a pr or opening an issue obviously doesn't scale that well...
If I have some time I might look into it.