ergochat
Lua module support
What is this?
I've come to ask about potentially adding a Lua API on top of Ergo as a means of making Ergo as modular as something like UnrealIRCd, while having as low of a barrier of entry. Lua is also ideal due to how small it is, making it probably the best language to use in this case. It would also allow for anyone to use any language they please, so long as an .so file can be produced.
Why would you need it?
Firstly, I think it would allow for a community of Ergo users to enjoy adding new functionality without having to fork and maintain it, creating an ecosystem. Additionally, it would benefit bridged communities that add slowmode, or potentially plural communities who want a native way to change their identity, but don't have the people available to maintain Ergo with their features.
Is this urgent?
This is not something that needs to be implemented right now. I think it would be a bad idea to rush this kind of feature too.
Am I willing to add it myself?
Yes, but I am currently having to manage an IRC server and bridge for a community and don't have the opportunity to at the moment.
As cool an idea as this is, it's unlikely to happen because it would increase the maintenance burden and complicate other ambitious initiatives like #1532.
If I understand the suggested use cases correctly, they are slowmode (#2180) and being able to use grouped nicknames without sacrificing the benefits of always-on?
The last use cases are indeed slow mode and grouped nicknames and always on benefits indeed.
Just thought I'd throw another use-case, would be more customized, lower-level message filtering.
In my case - I use ergo with a custom web front-end with an emote picker, with a concept of custom emotes, similar to Owncast, Twitch, Discord, etc. Users can use this emote picker, and it will insert a shortcode into their chat input, and/or they can just type the shortcode. The client is responsible for parsing messages for said shortcodes and converting them into images, which isn't the most ideal. I could have a user type an invalid shortcode, and result in an necessary request to check if the image is real, or now I need the client to keep track of the latest emotes (say a new emote was added to the emote set while the client is still running), etc. I'd love to have server-side validation/verification.
One thing twich does is add tags to the message indicating which characters should be replaced by emotes, and which emotes to use. Something like:
@emotes=1234:0-6 [email protected] PRIVMSG #channel :HeyGuys how's it going?
Would indicate that characters 0-6 (HeyGuys) are an emote with the id 1234, once the client has that ID it can proceed to insert the emote.
There are a few ways I could go about implementing a feature like this:
- Clients generate a private client-only tag with the emote data.
- Maybe a bot scans messages for known emotes and responds with TAGMSG messages indicating which characters are emotes. Using a combination of
draft/replyand private tags. - The IRC server itself scans for known emotes and adds the private tags.
Something like a filter written in Lua to bring everything in-server would be pretty great.
One thing that would be complex with regards to #1532 is dependencies. The lua-only dependencies would be ~~simple~~ straightforward enough - you could write something like a custom package searcher so leaf nodes could request lua packages from the root node. Any compiled dependencies though - not sure how feasible that would be, say if you had a leaf node running on ARM and the root node on x86. Or alternatively, you just say "no compiled dependencies?"
EDIT: Apologies, I wrote "simple enough" when like, it's not "simple". I think "straightforward" may be the better term. Basically, Lua-only dependencies could be serialized as text, and loading Lua from text strings is a standard operation with the Lua api, so the issue to solve becomes distributing them. In theory there could be a custom package searcher that makes an API call to request a stringify'd lua package from the root node.
Another potential issue that could come up with horizontal scaling is Lua versioning. Say you have multiple hosts all running the same version of Ergo, but if one host built Ergo against LuaJIT, another builds against Lua 5.4 -- what happens if a lua module only works on one and not the other?
I believe there won't be too much of an issue as go-lua is itself a port of Lua 5.2. All you really need to do is just write Lua which is compatible with go-lua.