To some people, yes. To others, no. You’re replying to specific people who seem to be against the idea, and I’m guessing for them it detracts significantly from the experience.

At the end of the day all of the concepts we have in fantasy are derivative in some regard, so the line will vary just like it will vary for people that want to do total homebrew vs following a book.

My group dabbled with AI when it was at its peak buzz, and if I’m honest, my head cannon sort of ignores those bits. They don’t carry the same authenticity that I came to expect from my group. It detracts from my experience because I play ttrpgs primarily to learn about my friends and how they’ve interpreted a shared world, not to hear algorithmically mid fanfic. I’m also not crazy about following a book. With a book, at least I know someone willfully released the work into the world and is getting appropriately compensated.

These are not the same. Here are some of the ways someone may be fine with reusing existing material while being against AI:

• Someone may value thoughtful and coherent world building, while feeling like the AI generated amalgamation dilutes the cohesiveness of the material.
• Someone can be for public sharing of ideas, while simultaneously against AI companies disregarding licenses attached to those ideas to build AI products.
• Someone can value the personality and individual perspective that a content author or DM injects into material and feel that AI-generated material lacks this character.

Don’t reduce the use of AI down to the reuse of material. It also averages out material into some sort of lowest common denominator - sacrificing exactly the things that many niche fandoms value: personality and imagination.

For anyone who’s curious, this is the state of discussing this feature: https://github.com/helix-editor/helix/discussions/8572

I’m not an authority on the helix ethos, but I’ve contributed a bit and hung around long enough to have a good read on their stance on most topics. The project is still young and managing the growing pains of getting a lot of traction relatively early. I think the devs value keeping the maintenance footprint small to keep the project sustainable.

The philosophy of helix’s design is to be a more convenient kakoune, not necessarily a vim. vim is much more widely known, so that analogy springs up more often, but this idea of using piping out to an external command for most operations comes from kakoune.

For features that would introduce significant maintenance overhead, may jeopardize the performance of a more common workflow or where the design goals are still maturing, the team tends to push such suggestions toward being developed as plugins when that system is added. I get the impression that they see the value of this workflow, but would prefer to see it battle tested as a plugin first.

I’ve been there, but over the years I’ve gotten better at avoiding being in this situation.

If you are implementing something for yourself, and merging it back upstream is just a bonus, then by all means jump straight to implementing.

However, it’s emotionally draining to implement something and arrive at something you’re proud of only to have it ignored. So do that legwork upfront. File a feature request, open a discussion, join their dev chat - whatever it is, make sure what you want to do is valued and will be welcomed into the project before you start on it. They might even nudge you in a direction that you hadn’t considered before you started.

Be a responsible dev and communicate before you do the work.

The community-based project of passion to enhance lemmy is already here… it’s lemmy.

This isn’t reddit. There isn’t a big black box and company around the service that is preventing the community from making it what they want it to be.

Sure there can be flavors, but I’d guess if there’s the type of consensus around the usefulness as there is with RES, then why wait for a separate project to shoehorn features on top of lemmy when the folks behind lemmy seem quite receptive to contributions?