I think I'm done with the base parts of Sele. There's still some parts that'll throw expections that I need to define guardrails around and I'm still annoyed with how WebAuthn absolutely requires a Web browser (not necessarily a user agent — whatever happened to those) for a neat integration. I'll figure that out later. For now, I'm going to start eating what I cook and cleaning it up around the rough edges. Ideally, the next post would be authorized by it!
Been debugging an issue in Sele for three hours, pulled in a mitm proxy tool only to finally see the issue in my tests once I bubbled up the error from another library I've written. The call's within the house!
Stuck on what kind of CSS framework I want to use across my set of apps. Bulma's great, but I want CSS variable support. I don't want to write something from scratch.
Got some good work done the other night. Need to figure out how to share Gulp configuration across projects, and then I can make a sharable configuration for a common frontend across my projects. Unintentionally “building” my own, but it works the way I want and need it to.
Lighthouse needs to be able to generate feeds to provide the baseline equivalency of support that Webmention.io does. I'm close to that—trying to make the feed item compilation generic enough, so I can render it in different formats.
Today's goals are the following:
- To get endpoint status reporting cooked into Lighthouse
- To add a means of checking a URL for a particular endpoint
- To add the basis of help docs into Lighthouse (so the above two can be explained)
I think baking in documentation this early will make the act of doing so easier going forward. I'm most likely going to use Rust's default approach to generating documentation with mdBook to make my life a bit easier. If it needs to change, I'll look into it then.
Okay so I got the endpoint status reporting done from the API, working on adding that into the frontend (Svelte and Web Components make this very easy). Now I'm working to associate a page to an endpoint, so the background jobs can then start computing availability statuses for endpoints. The fact that this can work locally for me is excellent. I should begin looking at hosting this somewhere. I know I'll do it solely for my site first, but I'd have to restrict sign-ups. Not only that, but I don't know how I want to do that just yet—might use an environment variable flag that has an override via the on-disk JSON configuration. All of this just so I can see reactions on my content (and send private Webmentions, of course).
Today's goals are the following:
- To get endpoint status reporting cooked into Lighthouse
- To add a means of checking a URL for a particular endpoint
- To add the basis of help docs into Lighthouse (so the above two can be explained)
I think baking in documentation this early will make the act of doing so easier going forward. I'm most likely going to use Rust's default approach to generating documentation with mdBook to make my life a bit easier. If it needs to change, I'll look into it then.
Going to muse on this more after work but some early hacking makes this feel like it's a bad idea. After $DAYJOB today, I'm going to attempt using the conventional Tera templating and figure out how to have Svelte components in this setup. I'd prefer to do it using Svelte because of what it provides with state management.
Ah, I figured it out! This is actually dope because now I have composable pages and a buildable frontend. Right now, it wouldn't work too well without the backend because it knows the 'final' paths to take. I could do some work to add that as an option by building a page manifest, but I don't need that right now. Feels fun to work on things that work.
There are aspects of Lighthouse that I could either spend time working on making into a proper SSR or I can work on using Web Components to build the UI components that I'd want. I wanted to use Svelte as I use it for other things (in Shock, Koype and Sele) but I don't see a simple way to do that using Gulp (using that for the build system). However, this is making me look into using something like Rollup now. I just want to be able to emit static HTML pages that have a bit of template code I can use to inject things from the server. I want to be able to provide a non-js;dr experience as much as possible.
What I'm going to do then is look into integrating something like Rollup for the JavaScript aspect of things. That way, I can still lean on using Web Components for more dynamic parts of the UI without having to go full js;dr.
Going to muse on this more after work but some early hacking makes this feel like it's a bad idea. After $DAYJOB today, I'm going to attempt using the conventional Tera templating and figure out how to have Svelte components in this setup. I'd prefer to do it using Svelte because of what it provides with state management.
There are aspects of Lighthouse that I could either spend time working on making into a proper SSR or I can work on using Web Components to build the UI components that I'd want. I wanted to use Svelte as I use it for other things (in Shock, Koype and Sele) but I don't see a simple way to do that using Gulp (using that for the build system). However, this is making me look into using something like Rollup now. I just want to be able to emit static HTML pages that have a bit of template code I can use to inject things from the server. I want to be able to provide a non-js;dr experience as much as possible.
What I'm going to do then is look into integrating something like Rollup for the JavaScript aspect of things. That way, I can still lean on using Web Components for more dynamic parts of the UI without having to go full js;dr.
Going with gulp.js for building the static site of Lighthouse. Trying to figure out Webpack is too much work and it seems to do the "take a file, process it and dump into a folder" thing really well.
And I found a bug in my code, lol. This is definitely a case to just implement a JF2 parser, to be honest.
Made excellent progress on this. I'm becoming more aware of the need to have JF2 support to support other places that things can be piped from. It'll also become more required as I begin working on the Microsub facets of Lighthouse. I've managed to not focus on it, just it. I can also see it simplifying the logic for my templates on my site if I use that, but I'll have to see.
I do think that I might entertain the idea of using @context in my MF2+JSON when rendering my feeds. It's a small change that promotes MF2 in the JSON form and it makes it discoverable when attempting to parse (outside of content type hints).
Today was quite productive! I just merged indieweb/koype!19 into indieweb/koype#develop so now I can use things like https://xray.p3k.io/ to interact directly with Twitter and GitHub. I think I'll add in Jamie's support for converting OGP information as well (although i have a very rudimentary setup for that, too.
Finally getting to adding a form of a pipe parsing system to my site on the Micropub side of things. There isn't any normalization on the output of these services, so I'm going to have them try first looking for a MF2 item, MF2 document, JF2 document and failing after that. It's not like we inject an
@contextin these documents, it'd be amazing with schema checking. I think I might do that myself.
Made excellent progress on this. I'm becoming more aware of the need to have JF2 support to support other places that things can be piped from. It'll also become more required as I begin working on the Microsub facets of Lighthouse. I've managed to not focus on it, just it. I can also see it simplifying the logic for my templates on my site if I use that, but I'll have to see.
Finally getting to adding a form of a pipe parsing system to my site on the Micropub side of things. There isn't any normalization on the output of these services, so I'm going to have them try first looking for a MF2 item, MF2 document, JF2 document and failing after that. It's not like we inject an @context in these documents, it'd be amazing with schema checking. I think I might do that myself.
I published a new version of the IndieWeb Rust crate that has logic for a passing implementation of the Webmention endpoint discovery flow. Aiming to work to decouple the explicit use of ureq, so people can bring their own HTTP client.
Using @eleven_ty to handle all the client pages to a browser for 🗒
posted
•
I've been spending about an hour a day or so working on my side projects. Right now, I got some great logic going for Lighthouse to take in and send Webmentions. But I just need an interface for it. I'm also working on serializing the tests described at webmention.rocks into the Rust library for IndieWeb, so I can be assured that anything using is compliant. I've also added some 'extension'-like logic, so it can support private Webmentions and Vouch (to a degree, I want to add some logic for handling Vouch resolution). With Lighthouse, I want to make it as simple as providing your RSS or Atom feed to Lighthouse and going from there - Webmentions should be automatically sent. Receiving them would be just adding a line of HTML to your site. I'm thinking about sneaking in a link that represents the endpoint but, when rendered as HTML on request, provide a form to submit Webmentions. And a tool to detect if a site supports Webmentions. Yeah so it looks like I ran into rusqlite/rusqlite!433 on GitHub. Very annoying and I need to find a way to either add a test for this or add an update trigger to fix up these values. I understand the former more, so I'll do that.Or rather, it's not able to show my main feed because of some SQL issue. "dbtax", anyone?