Kissaki

Given the announcement of edit replacing the old 32-bit MS-DOS edit.com with minimal footprint, I was surprised Microsoft considered multi-platform to even be in-scope.

I guess, given it's Rust, it was simple to say "sure, why not". But this ticket shows that you automatically have to discuss and handle multi-platform questions that arise.

Are these all YouTube videos?

A note on that would be helpful.

Thank you for sharing your experience. Sounds like it's like in any other field.

How do you experience good and bad reviews on your games? How much are you checking, looking at, and maybe hurt by reviews and negative reception? I've always wondered about impact of those on devs. Especially when I'm reviewing small indie games and they're subpar / no recommendation.

Or "a novel published as authored by Lena McDonald contains AI prompt"

Good to see an alternative to Anubis - with a reduced or configurable legitimate user impact

https://git.gammaspectra.live/git/go-away/

This tool started as a way to replace Anubis as it was not found as featureful as desired, and the impact was too high.

go-away may not be as straight to configure as Anubis but this was chosen to reduce impact on legitimate users, and offers many more options to dynamically target new waves.

The point is it makes them identifiable. If you block anything not authenticatable, and everything that auths via *.google.com, you are effectively blocking everything from Google.

If you fear they will evade to other domains, you'll have to use an allow-list.

Obligatory link to https://choosealicense.com/ - which gives some guidance and overview of license differences

I'd guess trying anything is fine if you keep a prototype and experimental mindset. You could try a CMS that looks interesting or viable. Maybe that helps getting a better idea of viability with specific products or approaches?

Personally, I'd try/experiment with what I laid out in my last comment - have data files (maybe json or markdown files) and generate and push and pull data from and to that. But that may be because of existing experience and expertise. Not necessarily the best approach for others.

Using a CMS means more integration, which has upsides and downsides.

For those building bots, we propose signing the authority of the target URI, i.e. www.example.com, and a way to retrieve the bot public key in the form of signature-agent, if present, i.e. crawler.search.google.com for Google Search, operator.openai.com for OpenAI Operator, workers.dev for Cloudflare Workers.

They're proposing the request will include public key source information and request target. Through the public key source, you can verify the origin via source domain name.

Makes me wonder if the main content source would not be better separately, from which you generate the other stuff - e.g. Hugo Markdown page source.

I'm still not sure I grasp the fundamental structure of your data and desired workflows.

Hugo being simple Markdown files for content, if they can not be used as the source of truth, maybe that can be elsewhere, maybe even in Markdown, and you copy to Hugo? Then you'd be less restricted in your form of data and doing other things with separate tooling like sync to other services.

If you already invested into Hugo theming I'd also be hesitant about switching to a CMS/hosted solution. Especially since I suspect there's no ready solutions for your integrations? I assume you'd have to do the integrations yourself. If that's the case, my intuition says to better be independent of a CMS (with unknown efforts or how long it will remain useful). Once you're in a CMS env as a primary source it owns the data and exporting won't be as easy as if you have the primary source separately in a simpler, independent manner.

You say you have contacts, newsletter, events. You said you have Hugo (yaml), Thunderbird, Google Contacts, CSV.

Is it a matter of synchronizing contacts between them? Or more? Sending the newsletters?

Git / TortoiseGit

Have you considered Hugo Data sources (data subfolder)?

Synchronising a data format in there, synchronising the data through APIs and some tooling, and then generate the Hugo website from that data may simplify the process - make it viable despite still having some variance and complexity.

in 4 different ways: Hugo yaml, Thunderbird, google contacts, CSV (from earlier days)

Are you still using CSV? If it's integratable into one of the other three that could reduce complexity by dropping this fourth case?

What do you want your defining state to be? Or should it synchronise across, and changes must be possible in any of the places?

Thunderbird can use Google contacts and calendar. Some tooling could sync to or from or both your Hugo data folder.