RTF editor may be part of WYSIWYG solution but it also might be used to edit text that on publication will be looking entirely differently or will be used in various places.
Astro is great, and is what I prefer on new “static-y” projects (for more dynamic stuff, SvelteKit).
But 11ty really was so much simpler if all you need is to put together some templates, and don’t want to deal with component stuff. That said, the docs really are lacking in some parts.
You can use 11ty with plain HTML pages/posts, I believe. [1] And it doesn’t handle deployment at all. What you get is the same dist/ directory that your Python script would happily upload to S3.
This was the beauty of 11ty. It just puts together HTML files from templates, and maybe handles sitemap and RSS if you need. That will probably change now.
This. The 11ty sites that I've built (all personal sites that will only ever be edited by me) are all plain HTML, no markdown. 11ty is lovely and bare-bones and un-opinionated.
I think it could be possible for the bottom half. The lid would be way, way trickier (unless you have one with a broken screen already and know how to put the new one together).
I’m wondering what custom colours you could do with that process btw!
Practically anything! Vibrant colours work best, and there are techniques to do transitions, fades, and masking to get multiple colours, though I’ve never done those myself.
All the big 3 cloud providers suck if you use them purely as VPS. I’ve tried AWS Lightsail (basically, slightly cheaper EC2) and it’s so much slower than what I’d expect from a similar spec VM from a normal hosting provider.
Hetzner, DigitalOcean, OVH, Vultr are some of the better-known ones. Personally, I’m very happy with SSD Nodes. Paying $90/yr for a 4 vCPU¹ / 16 GB / 320 GB SSD, had some downtime exactly once in two years (they’ve had to switch their IPv4 space in Tokyo). Affiliate link: https://ale.sh/r/ssdnodes
[1]: Intel Xeon E5-2650 v4 (4) @ 2.199GHz – not great, I know, but to reiterate: that’s for $90 a year.
The chatbot app initiates an OAuth flow, user SSOs, chatbot app receives tokens to its callback URL, then tool calls can access whatever the user can access.
If you use the official MCP SDK, it has interfaces you implement for auth, so all you need to do is kick off the OAuth flow with a URL it figures out and hands you, storing the resulting tokens and producing them when requested. It also handles using refresh tokens, so there's just a bit of light friendly owl finishing on top.
Source: I just implemented this for our (F100) internal provider and model agnostic chat app. People can't seem to see past the coding agents they're running on their own machines when MCP comes up.
I think this is the best of both worlds. Design a sane API (that is easy to consume for both humans and agents), then teach the agents to use it with a skill.
But I agree with the author on custom CLI tooling. I don’t want to install another opaque binary on my machine just to call some API endpoints.
Obviously opaque binaries are hardly an improvement over MCP, but providing a few curl + jq oneliners to interact with a REST API works great in my experience. Also means no external scripts, just a single markdown file.
Haven’t tried LittleSnitch, but from what I see it’s on par as far as features go. LuLu’s UI could use some improvements, but otherwise it’s perfectly fine for the job.
Just a quick question, and sorry if it might have been answered already... why preventing duplication is so important? I know it’s in the spec probably [1], but I can’t figure out the reason.
And a suggestion: add external HSM support at least? (e.g. things like NitroKey/YubiKey)
Preventing credential duplication is a requirement to achieve high level of assurance. One of its purpose is to limit the potential damage that can be done by attacks. If credentials are bound to hardware-bound keys, attackers will always need access to this key store to make any miss-use. If you don't prevent duplication, attackers may extract credentials and miss-use them at a 1000 places simultaneously.
Okay, but Google certifies phones which are not updates for the last several years.
They can be trivially rooted, then they spoof the signature and get a pass in Integrity while being wide open for malware (or cooying the ID, ID presume).
The documentation clearly outlines that there are multiple signals being analysed. Relying on play integrity alone is definitely not sufficient as you state.
I’ve just had another, completely stupid but not implausible, idea:
> a local internal WSCD, which is a component within the User device, such as a SIM, e-SIM, or embedded Secure Element,
So you could issue SIM-cards / eSIM profiles that only do signatures and nothing else. The app then connects to such eSIM (and you keep your main SIM/eSIM in another slot).
The less stupid variant is, of course, to get mobile operators to issue SIM cards with e-sign capabilities. Estonia has that, for example: https://www.id.ee/en/mobile-id/
> The less stupid variant is, of course, to get mobile operators to issue SIM cards with e-sign capabilities. Estonia has that, for example: https://www.id.ee/en/mobile-id/
It works great. Just keep in mind that newer phones are starting to deprecate physical SIM slots. At the same time certifying eSIM implementations to the same EAL level is an absolutely crazy task.
> At the same time certifying eSIM implementations to the same EAL level is an absolutely crazy task.
It probably is, but it does make sense. eSIM standards were built to solve pretty much the same problem (make cloning eSIM profiles impossible), so it should be a good anchor of trust for that.
Is that what they call WYSIWYG? :eyes:
reply