freenode/#shirakumo - IRC Chatlog
Search
14:41:53
Shinmera
Also Lichat has the same kinda thing with the channel trees extension, though in the form of (imo) a much nicer generalisation.
14:59:19
SAL9000
discord 'servers' were originally referred to as 'guilds', before their pivot from game-oriented communication
15:00:43
SAL9000
unless you want to pipe it through the server, welcome to NAT hole-punching, STUN, TURN etc. etc.
15:06:23
Shinmera
also wrt e2e group chat, it seems signal just multicasts your message by encrypting it for each member in turn.
15:08:18
Shinmera
https://security.stackexchange.com/questions/126768/which-protocols-exist-for-end-to-end-encrypted-group-chat
15:08:18
Colleen
security.stackexchange.com/... Website (HTML), Title: encryption - Which protocols exist for end-to-end encrypted group chat? - Information Security Stack
15:14:08
Shinmera
reading this and the linked post on the signal blog I'm gonna deem E2E in lichat "infeasible"
18:07:38
SAL9000
Shinmera: let's start shoving all the data into a class -- maybe a subclass of pylichat.Client -- so we're ready for multi-server
18:09:04
Shinmera
I'd go with composition. We're not really extending the client with anything here.
18:10:12
SAL9000
OK, so a "server" class representing one Lichat connection. Maybe a buffer class representing per-buffer state as well.
18:11:05
SAL9000
yeah, except for an unstaged my_buffers = CaseInsensitiveDict() but that'd be refactored anyway
18:11:35
SAL9000
buffer-to-Buffer mapping should *not* be case insensitive, but channel-to-Buffer should be.
18:13:08
SAL9000
if we want to be fancy, Python's "descriptors" let us make instance.foo = bar become a method call
18:14:14
SAL9000
If it wasn't expressly "forbidden" by a message on the script site, I'd suggest a py-weechat wrapper lib to hide away the C crap
18:17:51
SAL9000
while you're refactoring, you can dike out the redir_id_to_buffer mechanism now that we have that in py-lichat
18:19:13
SAL9000
also, I think we should store sent ids whether they have a callback or no -- for tracking lag in Client
18:19:43
SAL9000
the API can still be relatively clean if we delete the data *after* running the normal update callbacks
18:20:33
SAL9000
i.e. inside the handle-callback for a given update type, client.relatedUpdate(update) => the one you sent, or the one the failure is about
18:21:38
SAL9000
Currently, the library user has to explicitly request to be notified about the response to an update, right?
18:22:20
SAL9000
I'm suggesting a different API contract, where the library always tracks sent updates, and the library user can request that information up until it's deleted; which would occur at the very end of Client.handle
18:22:58
SAL9000
then, the library user can add a handler to Update, where the sent and received timestamps are compared -- thus giving lag estimates
18:26:16
SAL9000
the most common update -- message -- has to be tied back to the channel it was sent to, so the error message shows up in the right place
18:26:41
SAL9000
(well, in the right place or with the right text -- maybe errors should go to the server buffer rather than the channel)
18:29:01
SAL9000
This could be resolved on the server end, but I'm guessing you don't want to do that
18:29:23
Shinmera
I feel like the tracking has to be on the weechat side. Since some failures don't have a backref, the weechat side has to track which buffer the command was sent from.
18:31:08
Shinmera
failures without an update id backlink can happen on data uploads that are too large, for instance.
18:33:13
SAL9000
but that's more of a "client is badly coded" failure rather than a "user" failure, right?
18:33:28
SAL9000
if the server tells the client "here's my maximum update size", then the client should "never" send a too-large update
18:33:34
Shinmera
not quite. there's no 'limits' api, so the client can't know what the max size is.
18:33:53
SAL9000
on the other hand, the only way a too-large update can occur (currently) is uploads, right?
18:37:08
Shinmera
since then the update would (with quite a large payload!) remain forever in memory.
18:41:34
SAL9000
plus, it would be deleted even faster if the update-too-large handler gloms onto -- and deletes -- the biggest update in the cache
18:45:15
Shinmera
https://github.com/Shirakumo/py-lichat/commit/4e4be2dd9811fbc13f8994a9f1becbad4e36df24
18:45:15
Colleen
github.com/Shirakumo/py-lic... Website (HTML), Title: Add in flight update tracking. · Shirakumo/py-lichat@4e4be2d · GitHub
23:54:33
Shinmera
SAL9000: Pushed a big refactor. Because I was stupid and somehow didn't have some commits I force pushed it.
0:00:37
SAL9000
one thing I have already caught -- unfortunately, we can't pass Python pointers (other than strings) into weechat.
0:01:00
SAL9000
in this case, you're passing 'self' into 'hook_fd' data argument, which is not going to work :(