Funny that you pointed this out. I didn’t actually know about the two distinct sites. The “missing” hyphen in my url was a confusing accident; I just assumed they revamped the website poorly 🤣. I had to check the install instructions and GitHub link before posting

Not to be confused with helix the TUI text editor

Age gated on YouTube. Anyone have a mirror?

I’m trying to build a small business that replaces SSO mass surveillance (think Sign In With Google, LinkedIn, etc) with a privacy respecting alternative where the technology makes it impossible for me, the service operator, to know what the users are signing into.

Honestly, I avoid helm charts as much as possible. My preference is raw manifests + kustomize, deployed by Argo

I absolutely understand not liking opt-out telemetry. Do people generally not like opt-in telemetry? Is this really why the community shifted to a different project?

That would be great. I frequently have to click the link and navigate to a home page for a meaningful description. Here’s the opening statement from Koto’s README on GitHub.

Koto is a simple and expressive programming language, usable as an extension language for Rust applications, or as a standalone scripting language.

This is the first thing I need to read to understand if I should or should not care about the project and its new release.

If you want client side security and trust, then you may want to consider wasm.

Honestly, I wouldn’t be surprised if the inclusion of some small AI feature is what justified the rest of this work being done. As in, someone got approval for tab groups only because they were smart enough to describe it as “AI powered tab groups“. Just speculation

There are many reasons to use k8s. Managing multiple nodes is one good one. But more importantly, k8s gives you an api-driven runtime environment. It’s really not comparable to docker compose.

Yea I’m not a fan of helm either. In fact, I avoid charts when possible. But kustomize is great.

I feel the same way about docker compose. If it wasn’t already obvious, I’m biased in favor of k8s. I like and prefer that interface. But that’s just preference. If you like docker compose, great!

There’s one point where I do disagree however. There are scenarios where a local k8s cluster has a good and clear purpose. If your production environment runs on k8s, then it’s best to mirror that locally as much as possible. In fact, there are many apps that even require a k8s api to run. Plus, being able to destroy and rebuild your entire k8s cluster in 30s is wonderful for local testing.

Edit: typos

Honestly, k8s is super easy and very lightweight to run locally if you know the rights tools. There are a few good options but I prefer k3d. I can install Docker/k3d and also build a local cluster running in maybe 2 minutes. It’s excellent for local dev. Even good for production in some niche scenarios

I spent several weeks thinking about this exact idea.

Federation is cool. You could set up each instance to only federate with instances for nearby towns and cities. Maybe a “2 district” radius. Users would only see content for their local communities. Local news stays local. Local government could officially participate if they wish. People you talk to are actually neighbors you might see in person. Larger regions like counties, states, provinces, or even countries, could also have dedicated instances and federate similarly. I think this is the big appeal and it sounds awesome!

There are a few problems 🙂

First is a little bit of confusion with posting. Let’s say that I see a post about a cool new restaurant in my town. I share it with a friend who lives a few towns away and that’s outside the “federation radius”. I can’t share the post with that friend very easily. Maybe the tools could be enhanced to make this viable?

Second is a matter of privacy. How do you know that new accounts belong to people associated with the geographic location of each instance? If you don’t validate, the system will certainly be abused. If you do validate, then users need to supply some real info! Home address, ID, etc. that’s a big deal for users and instance admins.

Third. What happens if you move? Do you have to abandon your old account and start over? Again, the system itself can be developed further to solve this. But that’ll take time and money.

Next is the operating costs. You would need to build thousands of instances to build this system up. And each one would have to be tied to a geographic region. You need new features to handle signups this way. You have the simple cost of running these servers. You probably need a lot of staff to manage it all. This is an expensive platform for one party to run. Alternatively…

It doesn’t have to be one party running this entire system. That’s the point of the Fediverse, right? The operational costs go way down if anyone can run their own instance. But how do you enforce the rules of federating with instances for geographically nearby locations? I don’t see a reasonable way to solve this one.

I could probably keep listing issues. But these are the big ones IMO. If you solve these, the system is viable and could be amazing.