Jsdelivr: CDN for gist.github

[dbauszus-glx]

Do you have a custom endpoint to load a gist from gist.github as script?

[MartinKolarik]

No.

[Mosney]

No.

So any plan to support gist raw file?

[MartinKolarik]

Not at the moment. Where would this actually be useful?

[dbauszus-glx]

We use gist for code examples in markdown. We use jadelivr to load scripts as script tags from GitHub.

[Mosney]

Not at the moment. Where would this actually be useful?

In China mainland, it's hard to touch Github and its relative services like gist, so in my personal, I need a method to get raw file for my little gist code.

[hifocus]

In China mainland, it's hard to touch Github and its relative services like gist, so in my personal, I need a method to get raw file for my little gist code.

jsDelivr shouldn't be a tool for you to access government-blocked online resources, because if the government blocked, say, GitHub Gist, then if jsDelivr setups a proxy or something to help you reach it, then it will also be blocked. At that time it will be the problem that millions of people lose access to the whole jsDelivr.

Just go buy yourself a proxy service.

[Mosney]

In China mainland, it's hard to touch Github and its relative services like gist, so in my personal, I need a method to get raw file for my little gist code.

jsDelivr shouldn't be a tool for you to access government-blocked online resources, because if the government blocked, say, GitHub Gist, then if jsDelivr setups a proxy or something to help you reach it, then it will also be blocked. At that time it will be the problem that millions of people lose access to the whole jsDelivr.

Just go buy yourself a proxy service.

Actually, raw.githubusercontent.com has been DNSpollution/blocked in mainland China long time, and as I know, some repo provide jsDeliver link as alternative way to access raw file.

[MartinKolarik]

Actually, raw.githubusercontent.com has been DNSpollution/blocked in mainland China long time, and as I know, some repo provide jsDeliver link as alternative way to access raw file.

That's right but in some cases, it's causing us problems. I'll keep this issue open for now to consider it later but in general, I think regular repositories cover most of the intended use cases and we do not want to encourage using jsDelivr as a proxy to access otherwise blocked content.

[hifocus]

In China mainland, it's hard to touch Github and its relative services like gist, so in my personal, I need a method to get raw file for my little gist code.

jsDelivr shouldn't be a tool for you to access government-blocked online resources, because if the government blocked, say, GitHub Gist, then if jsDelivr setups a proxy or something to help you reach it, then it will also be blocked. At that time it will be the problem that millions of people lose access to the whole jsDelivr.
Just go buy yourself a proxy service.

Actually, raw.githubusercontent.com has been DNSpollution/blocked in mainland China long time, and as I know, some repo provide jsDeliver link as alternative way to access raw file.

However this shouldn't be the reason for jsDelivr to add extra supports to things that only will benefit Chinese users - it's a global service to the open source community, we're already lucky enough to have a China-optimised CDN support, shouldn't ask for more, definitely not in a take for granted manner.

And I agree, to the official member's thoughts, even a release CDN shouldn't be provided because in that case people can host gigabytes of single files via release and serve it through jsDelivr - this will obviously increase the load and the traffic to the service, and add additional difficulties to its initial purpose: to simply serve front-end files like js and css.

[Mosney]

I think regular repositories cover most of the intended use cases and we do not want to encourage using jsDelivr as a proxy to access otherwise blocked content.

Yes, reasonable. I just list a possible reason for the original issue: add CDN for gist.

I said in above is hard not cannot, I think someone misunderstood my point, my point focous on CDN variety not break block. China authority only block raw.githubusercontent.com and few third-level .io pages domain for now, most of GitHub services are not unavailable, just slowly or unstable.

And additionally, I think whether blocked should not as a reason to decide whether gist support or not. GitHub repo and gist are equal standing, you can't say "I don't add gist support because it used to break the government block". Obviously, GitHub repo will definitely blocked too if gist has been blocked.

[hifocus]

I think regular repositories cover most of the intended use cases and we do not want to encourage using jsDelivr as a proxy to access otherwise blocked content.

Yes, reasonable. I just list a possible reason for the original issue: add CDN for gist.

I said in above is hard not cannot, I think someone misunderstood my point, my point focous on CDN variety not break block. China authority only block raw.githubusercontent.com and few third-level .io pages domain for now, most of GitHub services are not unavailable, just slowly or unstable.

And additionally, I think whether blocked should not as a reason to decide whether gist support or not. GitHub repo and gist are equal standing, you can't say "I don't add gist support because it used to break the government block". Obviously, GitHub repo will definitely blocked too if gist has been blocked.

Gist have no connectivity issues whatsoever other than in China, as far as I concerned.

Our govt blocked gist for a reason, same as raw.githubusercontent.com - there were used to spread content that is in fact illegal in China, perhaps like Shadowsocks installation scripts or other anti-govt stuff.

It's only the time matters if jsDelivr offers a gist CDN: it will be blocked, sooner or later, and it's also 'report' dependent.

CDN was meant to accelerate a website's loading progress; I cannot see how accelerating some plain texts will possibly help. Furthermore, you can fully use a GitHub repository as gist; quite simply just put gist files into the repository and jsDelivr acceleration will be available, though I would advise you to not to host any content that will potentially get jsDelivr's domain blocked in China.

OR just go buy yourself a proxy.

[Absolucy]

I have an actual use for jsdelivr supporting gists: userscripts, it's dumb to make an entire github repository for a single self-contained JS file that might be updated once every few months.

[radiantly]

I was looking at jsDelivr for the exact use case that @aspenluxxxy mentioned - userscripts. Linking the direct gist URL does not allow it to be updated.

[jimaek]

jsDelivr was built for production use. That means having a versioning system. Creating a Github repo and tagging your releases is not that hard but it allows us to offer a more stable service.

Supporting gists is simple but building the codebase to support gists in a reliable way is not so trivial. We have multiple levels of caching, we cache files permanently to make sure a deleted file won't break thousands of website, we do internal optimizations...

Lots of things come together to offer a reliable production service. Spending our limited dev resources on gists doesn't make sense for me for now, especially when using Github directly is just as simple.

If in the future we end up with a big full-time dev team then it's something I would consider doing.

Thanks all