General code audit #22

New Issue

2026-10-05T05:09:41+02:00

adam commented

2026-10-05 05:09:41 +02:00

This issue is for the need for an overall code audit, focusing in particular on:

Modules etc that could be removed as a result of being ported over from PL blog but not needed here
Potential barriers to deployment over IPFS

Please separate the results out into their own issues so they're easier to work - thanks!

This issue is for the need for an overall code audit, focusing in particular on: - Modules etc that could be removed as a result of being ported over from PL blog but not needed here - Potential barriers to deployment over IPFS Please separate the results out into their own issues so they're easier to work - thanks!

adam closed this issue

2026-10-05 05:09:41 +02:00

adam commented

2026-10-05 05:09:43 +02:00

@cwaring -- thank you for identifying any problems here as you find them! 🙏 I can separate into checklists or individual issues as need be.

@cwaring -- thank you for identifying any problems here as you find them! 🙏 I can separate into checklists or individual issues as need be.

adam commented

2026-10-05 05:09:43 +02:00

I'll report back with an evaluation within the next couple of weeks, and also my suggestions to #41.

I'll report back with an evaluation within the next couple of weeks, and also my suggestions to #41.

adam commented

2026-10-05 05:09:44 +02:00

@zebateira - per our conversation, are you able to work with @cwaring and @jdiogopeixoto to get this and #41 resolved? As we discussed, we might also want to look into establishing some sort of ongoing instrumentation for the blog to keep an eye on performance as the blog continues to expand over time. Thank you!

@zebateira - per our conversation, are you able to work with @cwaring and @jdiogopeixoto to get this and #41 resolved? As we discussed, we might also want to look into establishing some sort of ongoing instrumentation for the blog to keep an eye on performance as the blog continues to expand over time. Thank you!

adam commented

2026-10-05 05:09:45 +02:00

Note re instrumentation: @atopal recommends https://speedcurve.com/.

Note re instrumentation: @atopal recommends https://speedcurve.com/.

adam commented

2026-10-05 05:09:45 +02:00

Do we feel we can close this issue in favor of https://github.com/ipfs/ipfs-blog/issues/41?

Do we feel we can close this issue in favor of https://github.com/ipfs/ipfs-blog/issues/41?

adam commented

2026-10-05 05:09:46 +02:00

@jessicaschilling I would prefer to go forward with a separate code audit from the payload issue. Will leave an update here soon about this.

@jessicaschilling I would prefer to go forward with a separate code audit from the payload issue. Will leave an update here soon about this.

adam commented

2026-10-05 05:09:47 +02:00

Agree with @zebateira here. There is a lot more to be covered than captured in that issue, best keep this on the radar.

Agree with @zebateira here. There is a lot more to be covered than captured in that issue, best keep this on the radar.

adam commented

2026-10-05 05:09:47 +02:00

Initial list:

Blog post images need to be out of the public folder and required by webpack (follow up from discussion in #91, WIP in https://github.com/ipfs/ipfs-blog/pull/99)
Remove unused code and packages (addressed by #100)

Initial list: - [x] Blog post images need to be out of the public folder and required by webpack (follow up from discussion in #91, WIP in https://github.com/ipfs/ipfs-blog/pull/99) - [x] Remove unused code and packages (addressed by #100)

adam commented

2026-10-05 05:09:48 +02:00

I'll maintain a list of items here as I notice them:

Remove image crop route from blog config
Correctly exclude sitemap and feed items
Ensure generated page metadata is correct
Tailwind should be upgraded to 2.x (we can now use JIT mode to save build time)
404 should use a layout file (example: config 404.vue)
Tags and authors should have rel="nofollow" to stop url indexing
App metadata should be changed from "Protocol Labs"
Countly should not load in dev mode, as not to pollute analytics
bonus: card zoom hover is disorienting, try a subtle zoom on the image instead (eg https://protocol.ai/blog/)

I'll maintain a list of items here as I notice them: - [x] Remove image crop route from blog config - [x] Correctly exclude sitemap and feed items - [x] Ensure generated page metadata is correct - [x] Tailwind should be upgraded to 2.x (we can now use JIT mode to save build time) - [x] 404 should use a layout file (example: [config](https://github.com/ipfs/ipfs-docs/blob/main/docs/.vuepress/config.js#L326) [404.vue](https://github.com/ipfs/ipfs-docs/blob/main/docs/.vuepress/theme/layouts/404.vue)) - [x] Tags and authors should have `rel="nofollow"` to stop url indexing - [x] App metadata should be changed from ["Protocol Labs"](https://github.com/ipfs/ipfs-blog/blob/main/src/.vuepress/config/head.js#L27-L29) - [x] Countly should not load in dev mode, as not to pollute analytics - [x] bonus: card zoom hover is disorienting, try a subtle zoom on the image instead (eg https://protocol.ai/blog/)

adam commented

2026-10-05 05:09:49 +02:00

first two items from @cwaring list addressed in #98

first two items from @cwaring list addressed in #98

adam commented

2026-10-05 05:09:49 +02:00

Added a few more items above :)

Added a few more items above :)

adam commented

2026-10-05 05:09:50 +02:00

@cwaring regarding the 404, is it possible to make it work on a subpath? It doesn't seem to be working: https://ipfs.fleek.co/ipfs/Qmb4soPiemEeQoYWciwsZXaCBP3AYeojjrCFdCGHjsSgwe/asdf

Currently the script redirect to /404.html is not working, but we can tweak it to make it work quickly.

@cwaring regarding the 404, is it possible to make it work on a subpath? It doesn't seem to be working: https://ipfs.fleek.co/ipfs/Qmb4soPiemEeQoYWciwsZXaCBP3AYeojjrCFdCGHjsSgwe/asdf Currently the script redirect to `/404.html` is not working, but we can tweak it to make it work quickly.

adam commented

2026-10-05 05:09:51 +02:00

It's only possible by redirecting with the ipfsPathPrefix script. However in my mind the 404 is not really required when you're viewing a site from a CID gateway because that is a snapshot in time that will never change, so I'm ok with the compromise of using <base href="/"> to pin the 404 page to the root domain because a 404 is unlikely to be triggered unless that CID deploy happed to include internal dead links. Which should be a low probability.

The advantage of using a 404 layout means it's easy to capture the url for the 404 and report to analytics. If we redirect to a root /404 page perhaps this is also possible by checking the referer?

It's only possible by redirecting with the `ipfsPathPrefix` script. However in my mind the 404 is not really required when you're viewing a site from a CID gateway because that is a snapshot in time that will never change, so I'm ok with the compromise of using `<base href="/">` to pin the 404 page to the root domain because a 404 is unlikely to be triggered unless that CID deploy happed to include internal dead links. Which should be a low probability. The advantage of using a 404 layout means it's easy to capture the url for the 404 and report to analytics. If we redirect to a root /404 page perhaps this is also possible by checking the referer?

adam commented

2026-10-05 05:09:51 +02:00

The alternative that would work in both scenarios might be:

ipfs-404.html responsible for redirects -> {cid}/404 OR /404
/404 - responsible for displaying the 404 and reporting the referer path to analytics (so we can fix the 404)

Downside is this would only work if JS is enabled but who really browses with JS disabled these days?!

The alternative that would work in both scenarios might be: ipfs-404.html responsible for redirects -> {cid}/404 OR /404 /404 - responsible for displaying the 404 and reporting the referer path to analytics (so we can fix the 404) Downside is this would only work if JS is enabled but who really browses with JS disabled these days?!

adam commented

2026-10-05 05:09:52 +02:00

I just checked, this would work but then you would also lose the original referer link because of the interim redirect.

eg:
[article elsewhere on the web] -> ipfs-blog/post -> ipfs-404 -> 404 (document.referer = 'ipfs-blog/post')
[article elsewhere on the web] -> ipfs-blog/post -> 404 (document.referer = 'article elsewhere on the web')

This can be helpful for figuring out the original source link and fixing them. So you would have to pass on the original referer to the 404 page to capture everything correctly or do the analytics tracking before the redirect, but then you would have to wait for that to complete before redirecting to ensure it was captured. Simply using one 404.vue is the easiest solution for now.

Also I know there aren't any 404 analytics yet on this site but that should be added asap :)

I just checked, this would work but then you would also lose the original referer link because of the interim redirect. eg: [article elsewhere on the web] -> ipfs-blog/post -> ipfs-404 -> 404 (document.referer = 'ipfs-blog/post') [article elsewhere on the web] -> ipfs-blog/post -> 404 (document.referer = 'article elsewhere on the web') This can be helpful for figuring out the original source link and fixing them. So you would have to pass on the original referer to the 404 page to capture everything correctly or do the analytics tracking before the redirect, but then you would have to wait for that to complete before redirecting to ensure it was captured. Simply using one 404.vue is the easiest solution for now. Also I know there aren't any 404 analytics yet on this site but that should be added asap :)

adam commented

2026-10-05 05:09:53 +02:00

WIP PR for 404 here: https://github.com/ipfs/ipfs-blog/pull/106 (includes analytics as well :) )

WIP PR for 404 here: https://github.com/ipfs/ipfs-blog/pull/106 (includes analytics as well :) )

adam commented

2026-10-05 05:09:53 +02:00

@cwaring does this feel like it's complete? Or do you want another iteration after launch?

@cwaring does this feel like it's complete? Or do you want another iteration after launch?

adam commented

2026-10-05 05:09:54 +02:00

It looks like we've covered all the burning issues now but we should do another round to actually check over optimisations and configuration, I haven't had time to go much deeper in this sprint.

Calling this complete for now so we can move onto the pre-flight transition!

It looks like we've covered all the burning issues now but we should do another round to actually check over optimisations and configuration, I haven't had time to go much deeper in this sprint. Calling this complete for now so we can move onto the pre-flight transition!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/ipfs-blog#22