todo.sr.ht

~gdamjan has linked https://paste.rs/IZ82z.txt and https://paste.rs/8jdhx.txt on IRC.

Closing because this is contrib/ material: patches welcome, but not officially supported.

REPORTED RESOLVED CLOSED

#173 Server password field disappears after accepting self-signed certificate 10 days ago

Comment by ~emersion on ~emersion/goguma

Correct, Goguma doesn't support server passwords.

REPORTED RESOLVED CLOSED

#173 Server password field disappears after accepting self-signed certificate 10 days ago

Comment by ~emersion on ~emersion/goguma

Probably because your server doesn't support SASL.

#248 Support configuring “default” network(s) for new users 14 days ago

enhancement added by ~emersion on ~emersion/soju

#248 Support configuring “default” network(s) for new users 14 days ago

Comment by ~emersion on ~emersion/soju

It seems like this issue is about both connecting new users to the network and adding some authentication mechanism between soju and an upstream server to automatically log in users?

There are multiple ways to implement the former:

Add some kind of "new user" event to the soju admin IPC so that a third-party daemon can configure the new user accordingly. This solution is the most flexible (the external daemon can do anything), but is somewhat racy (the external daemon can be out-of-sync) and new users aren't initially set up with the right configuration (the external daemon handles the event asynchronously).

Add a bouncer-wide mechanism to define the default configuration for a new user. Could be specified in the config file (but would duplicate a lot of the DB schema) or as a template user (a real, disabled user, duplicated when creating a new user).

Add a concept of "builtin" network: when no network is specified when connecting to the bouncer, the connection is bound to this network. The network cannot be disabled/removed by users.

The latter, I haven't thought about yet. I would be concerned about the security implications of forwarding automatically bouncer credentials to a server (option 1 could do it on its own, would be less of a concern with option 3).

#237 networks with same address but different name 14 days ago

Comment by ~emersion on ~emersion/soju

REPORTED RESOLVED CLOSED

#171 Hide /join /part messages 14 days ago

Comment by ~emersion on ~emersion/goguma

This is the opposite of what I meant: draft/event-playback disables the translation of events like JOIN and PART into NOTICE, instead causing them to be sent with their original commands.

Yeah, my wording was confusing here. What I meant was that enabling draft/chathistory while leaving draft/event-playback disabled is not a hint that the client wants join/part/etc turned into NOTICE.

As specified, CHATHISTORY only communicates the state of pagination via the size of the returned message window. If it is equal to the requested message limit, there may be more messages that can be retrieved by paging further; if it is less, then there are no more messages.

Oh, so this is a technical limitation about paging purely? I thought it was an intentional end-user feature from Ergo's point of view.

In the worst case, this degrades to a table scan.

We have indexes for the column indicating whether a message is a PRIVMSG/NOTICE so I don't believe this has a noticeable performance impact.

#247 Allow rate limits to be disabled per channel 17 days ago

Comment by ~emersion on ~emersion/soju

No, for that, the plan is the SAFERATE extension with no other mechanism to disable it.