Here's an example with a list of my favorite movies: https://noeldemartin.github.io/media-kraken/viewer?c=https%3A%2F%2Fdata.noeldemartin.com%2Ffavorite-movies%2F
@noeldemartin suppose Media Kraken accepted a URL param pointing to a static site that by necessity doesn't provide server-side support for SOLID but nonetheless contains publicly available, structured data.
I've got a sketch for how to achieve this; it also ameliorates frustration over how WHATWG is handling <https://github.com/whatwg/fetch/issues/878>. I'm pretty sure that a big source of friction for both SOLID and remoteStorage adoption is how unaccommodating the specs are to people with static sites.
@noeldemartin see this dev's remarks, for example, about trying to implement Webfinger (which remoteStorage uses) for their personal site: <https://github.com/konklone/jekyll-webfinger/tree/9bcb46bbabc08363b14fd8b41a944215539d7642> (Ctrl or Cmd+F for "static files".)
@colby I don't know much about remoteStorage or Webfinger, but as I understand it using a url to a "static" turtle document should work with Media Kraken. From the application's point of view, it cannot tell if it's static or not. As long as a GET request to the provided url returns a turtle document, it should work.
There may be an issue now because I'm assuming that the url to container documents end with a /, but I think you should be able to work around that with static assets.
@noeldemartin I didn't realize Media Kraken wasn't relying on the "advanced" parts of Solid's protocols, although even with workarounds, wasn't able to manage to get it to work in the brief (? kind of but not really) time I spent trying it. Those workarounds also seem to require clients ignore server-sent content type.
@colby Well it relies on authentication for the most part, but the Viewer only reads documents. My point in my previous comment is that the application doesn't really know if the url belongs to a static file or not, "static" is only a concept relevant to the server processing the request, but applications making requests don't know if the responses come from a static asset or have been generated by a backend script.
@noeldemartin, acknowledged. Problems arise if you don't have this use case in mind, though. It's easy to slip into a POLP-violating mindset and start relying on behavior that can't realistically be handled by static sites (e.g. WebFinger comments I linked). A SOLID-related example would be difficulty creating the content consumed by Media Kraken viewer if you assume the server is a full-fledged pod, because you don't have writeability—not an issue if you aim to accommodate from the start.
@colby What do you mean with POLP? I don't know what that means.
But yeah, I am assuming that the url belongs to a full-fledged Solid POD (or said differently, that it implements the Solid protocol following the spec). Although I'm not sure why that's a problem or the use-case you're trying to solve.
If you want maybe you can share a link of something you think should work with the Viewer that isn't working and I can take a look :). You can send me a DM if you don't want it to be public.
@noeldemartin making my first comment more explicit: I think if RS and/or SOLID were engineered so people could use GitHub Pages to act as their PDS, at least for the public-facing parts, we'd see more people using+creating <https://0data.app>-style apps.
POLP: <https://www.w3.org/DesignIssues/Principles.html#PLP> (POLA may be more correct)
If Dokieli couldn't author content without a writeable pod attached, for example, that'd violate POLP/POLA because it can and should just allow ordinary export.
@noeldemartin websites that badger you to install the app to do display content that your browser could do instead are other examples of things that violate POLP.
I have a proven (but less-than-prototype-quality, def. not production-quality) general solution to the "SOLID services for static sites" problem (for both SOLID *and* RS), so I know it's doable. (It's just that stopping to work on it without funding for the next ~2–3 months means it's out of the question.)
@noeldemartin I've been on the periphery of Solid for a while and am familiar with the forums
1. It's telling that it's been several years since Solid's conception, Solid Project is using a Discourse forum, linked here via Mastodon
2. I don't have a question that I need help with; I know what the solution looks like, I just don't have the budget to stop the world for the next ~3 months to bring it into existence. It's also not going to get discussed into existence in bikeshedding threads.
@noeldemartin I apologize if this sounds aggressive. It's not supposed to be.
@colby It's ok, nothing wrong with sharing your opinion :).
I kind of agree that it's advancing slowly, but I've been "in the loop" for 2 years and at least I can say it is advancing. I see a lot more people around today than I did at the beginning. And the project hasn't been going on that many years. Yes, "Solid" as a concept has existed for a while. But the Solid community and the intention to push it forward are not that old. It was a research project for a long time.
@colby And I pointed you to the forum because if you want to share your opinion with the Solid community, that's the best place to do it at the moment. And that's what I think you were trying to do with your comments, because it doesn't seem like the issues you're mentioning are unique to Media Kraken. Of course, I appreciate your feedback about my app and I'll look into it.
@noeldemartin neat, nice to hear/see (I clicked through and poked it). When I tested before, it was by serving static files with Python's SimpleHTTPServer. I'll prod some more and send patches if I narrow down discrepancies that should cause it to work with one and not the other.
(Autonomous Data as a conceptually distinct "movement" not necessarily tied to the particulars of Solid seems like a good idea.)
@colby Yeah Autonomous Data is not the same as Solid, but I have to say that I thought about it before I knew that Solid existed. Once I found about Solid, I thought the vision was so close that I'd focus my efforts on that instead of building my own thing. It's still useful to keep in mind though, maybe some day I'll do something more with it. But not in the foreseeable future.
This is an instance-of-one managed by Noel De Martin.