France
I'm Simon Ser, I write open-source software.
Comment by ~emersion on ~emersion/goguma
Note, the real fix would be to add support for the soju.im/bouncer-networks extension in znc.
You can send unknown commands to the server, or make it an option.
I don't think sending unknown commands to the server is a good idea. There is already
/quote
.no options except "Join channel #*status"
Probably because znc doesn't reply to WHO on the virtual user.
Closing since this isn't actionable.
REPORTED
RESOLVED CLOSEDComment by ~emersion on ~emersion/goguma
Goguma is limited to only a single IRC network, right?
See https://todo.sr.ht/~emersion/goguma/139
send a /znc command
goguma doesn't implement this command (and won't, since it's znc-specific).
message a virtual *status user
Hm, what happens in that case? Does it complain that it's not a valid nick because of the "*"?
Comment by ~emersion on ~emersion/soju
This would be more complicated than the current implementation and I fail to see the benefits.
Comment by ~emersion on ~emersion/gamja
I am not sure link previews would be welcome in gamja, given the UX of the client. gamja is not designed to be a featureful fancy client.
I would not want to add anything more complicated than a global on/off switch in any case.
"~emersion" outgoing@sr.ht wrote:
I would say this is unlikely. This will break a lot of assumptions, supporting both IMAP and JMAP will introduce a lot of complexity, and I have very little time to allocate for reviews.
So the conclusion is that if somebody wanted to implement it they most likely would have to fork the project.
Thanks for the clarification!
Comment by ~emersion on ~migadu/alps
I would say this is unlikely. This will break a lot of assumptions, supporting both IMAP and JMAP will introduce a lot of complexity, and I have very little time to allocate for reviews.
Comment by ~emersion on ~migadu/alps
REPORTED
RESOLVED CLOSEDSoju currently does not resolve symlinks. At least it didn’t for me running in docker. Specifically:
docker-compose.yaml
configs: soju: file: soju-config services: soju: container_name: soju image: codeberg.org/emersion/soju:latest ports: - 6697:6697 configs: - source: soju target: /soju-config volumes: - /etc/letsencrypt:/etc/letsencrypt:ro - ./data:/opt/sojusoju-config
listen ircs:// listen unix+admin:// tls /etc/letsencrypt/archive/example.com/fullchain28.pem /etc/letsencrypt/archive/example.com/privkey28.pem hostname 127.0.0.1 db sqlite3 /opt/soju/soju.db message-store db enable-user-on-auth false
readlink /etc/letsencrypt/live/example.com/fullchain.pem
../../archive/example.com/live/fullchain28.pem
I can’t do
tis /etc/letsencrypt/live/example.com/fullchain.pem
or it will complain about being unable to load the cert because that file is a symlink. This makes it difficult to use certbot’s automated certificate renewal because the live certificate is a symlink to the latest certificate in the archive.Regarding reloading the certificates on its own; I didn’t know that a SIGHUP will reload everything (including certs), so that will resolve that problem. More than easy enough to just tack that onto my cron job.
On 3 Jan 2025, at 19:18, ~emersion outgoing@sr.ht wrote:
Not exactly sure what this entails. soju just opens the certificates without doing anything special (which means symlinks should work just fine…).
soju won't reload certificates on its own, it will reload them when its config file is reloaded (SIGHUP). I don't want to watch the certificates or config file, because this is dangerous in production (the files might be half-written, the administrator might want to double-check or make multiple changes before reloading, etc).
-- View on the web: https://todo.sr.ht/~emersion/soju/240#event-402678
Comment by ~emersion on ~emersion/soju
Not exactly sure what this entails. soju just opens the certificates without doing anything special (which means symlinks should work just fine…).
soju won't reload certificates on its own, it will reload them when its config file is reloaded (SIGHUP). I don't want to watch the certificates or config file, because this is dangerous in production (the files might be half-written, the administrator might want to double-check or make multiple changes before reloading, etc).