A nearly-unstyled, hackable, ultra-modern, ultra-clean scaffold for rich, interactive storytelling, journalism and blogging. Fork this repo and get to work.
So one of the core tenets of sbstr8 is that articles are code, which is why the graphql endpoint returns metadata about articles, but not the articles proper, which are currently statically linked against.
It would make sense if the graphql endpoint returned paths which were then used with import()
For bonus coolness, it would be awesome if it could accept arbitrary URLs as well.
There's an obvious security problem if these are loaded as modules, so let's not do that, but the convention could be something like iframes?
'local paths get treated as paths to give to import(), remote URLs get treated as content to present in an iframe'.
I think that makes sense.
Down the road if we implemented signing somehow, we could run remote code that is signed somehow, but this seems like way too much vuln to countenance at any nearby-adjacent level of complexity for sbstr8. Wait till we're older, if we get there
So one of the core tenets of sbstr8 is that articles are code, which is why the graphql endpoint returns metadata about articles, but not the articles proper, which are currently statically linked against.
It would make sense if the graphql endpoint returned paths which were then used with
import()For bonus coolness, it would be awesome if it could accept arbitrary URLs as well.
There's an obvious security problem if these are loaded as modules, so let's not do that, but the convention could be something like iframes?
'local paths get treated as paths to give to
import(), remote URLs get treated as content to present in an iframe'.I think that makes sense.
Down the road if we implemented signing somehow, we could run remote code that is signed somehow, but this seems like way too much vuln to countenance at any nearby-adjacent level of complexity for sbstr8. Wait till we're older, if we get there