libera/#shirakumo - IRC Chatlog

9:26:01 Colleen <shinmera> :toot: https://aur.archlinux.org/packages/multiposter

9:27:37 Colleen <SAL9000__> shinmera: shouldn't that have sbcl in makedepends? also, quicklisp dist updates will break the b2sum

9:27:57 Colleen <shinmera> oh, right. forgot to add that back in because I had to remove it for my build

9:28:43 Colleen <shinmera> and no, the b2sum will only break if the quickstart installer changes

9:29:37 Colleen <SAL9000__> btw there is an actual package for quicklisp https://archlinux.org/packages/extra/any/quicklisp/

9:30:18 Colleen <shinmera> how odd.

9:31:23 Colleen <SAL9000__> also pushed some more weelichat fixes, channel-info was subtly broken among other things

9:32:29 Colleen <shinmera> nice!

9:34:02 Colleen <shinmera> the strip option in makepkg really fucks up sbcl

9:34:16 Colleen <shinmera> wonder what the heck it does. I guess just rips out the entire core?

9:38:07 Colleen <shinmera> anyway, also a bit surprised by how big the binary is for multiposter

9:38:12 Colleen <shinmera> even with compression it's almost 20 megs

9:38:13 Colleen <SAL9000__> maybe it sees non-standard sections & assumes they aren't needed

9:48:36 Colleen <shinmera> Also for multiposter thinking about a library to do document conversion

9:48:47 Colleen <shinmera> since a lot of backends have very different capabilities and requirements for the markup

9:49:03 Colleen <shinmera> so if I want to multipost blogs I'll have to convert

9:50:01 Colleen <SAL9000__> how did lichat handle PMs? if I recall correctly, "everything is a channel", right?

9:50:13 Colleen <SAL9000__> weechat hotlist expects different values for "message in channel" vs "message in PM"

9:50:30 Colleen <shinmera> you create an anonymous channel and then pull the other participants in

9:50:39 Colleen <shinmera> an anonymous channel is always prefixed by an @

9:50:58 Colleen <shinmera> I was also thinking about how to improve the UX of that recently, by introducing a "title" attribute for channels

9:51:13 Colleen <shinmera> so that the server can create a more human-readable title than the randomly generated channel id

9:51:32 Colleen <SAL9000__> hmmm... so do we treat "any anonymous channel" as PM, or only "anonymous channel with 2 participants"?

9:51:34 Colleen <shinmera> iirc weelichat implements /query in that way?

9:52:29 Colleen <shinmera> SAL9000__: dunno, I guess it depends on what weechat wants with it?

9:52:48 Colleen <SAL9000__> most people consider "I got a DM" more important than "someone said something in #big-channel"

9:52:54 Colleen <shinmera> the bug of when you /close a buffer it being reopened immediately to show the quit message is still there, too, btw

9:53:12 Colleen <shinmera> SAL9000__: ye but group DMs are also a thing in most services these days

9:53:21 Colleen <shinmera> so I'd just treat all @ channels as privmsg

9:53:26 Colleen <SAL9000__> ye, question is whether group DMs map as "big DM" or "small channel", conceptually

9:53:33 Colleen <shinmera> the latter

9:53:48 Colleen <SAL9000__> then they get "message" hotlist unless they have 2 participants?

9:54:06 Colleen <shinmera> oh, wait, I misunderstodo

9:54:13 Colleen <SAL9000__> basically, we have 3 cases

9:54:13 Colleen <shinmera> sorry, I meant that all @ channels should be message hotlist

9:54:23 Colleen <SAL9000__> normal channel: obviously maps to irc channels

9:54:32 Colleen <SAL9000__> anon channel, 2 people: obviously maps to irc query

9:54:38 Colleen <SAL9000__> anon channel, >2 people: ??

9:54:44 Colleen <shinmera> I say query

9:55:07 Colleen <SAL9000__> ok, so all @channels get "private" hotlist rather than "message" hotlist

9:55:23 Colleen <shinmera> Also, I just want to say, because this is a very unusual feeling for me, but I'm still really happy with the lichat protocol design.

9:55:29 Colleen <shinmera> I hate the clients, but the protocol is good

9:55:32 Colleen <SAL9000__> as for @channel titles - if it's a DM, the clients should probably render the other person's name rather than the internal title

9:55:37 Colleen <SAL9000__> :-)

9:55:51 Colleen <shinmera> I think it would be good to have a title attribute

9:55:56 Colleen <shinmera> so a user can set a more appropriate title

9:56:06 Colleen <shinmera> but using the other user's name as a default would be good, of course

9:56:23 Colleen <shinmera> though that's something the client has to do, too, since the server doesn't know about it

9:56:33 Colleen <SAL9000__> well the server *could* do it but it would be Weird

9:56:41 Colleen <SAL9000__> would create "split brain"

9:56:52 Colleen <shinmera> yea

9:57:00 Colleen <SAL9000__> user A opens DM with user B, user A receives title=B, user B receives title=A

9:57:23 Colleen <SAL9000__> title should be unset, then clients show the counterparty's name in the 2-party case

9:57:38 Colleen <shinmera> anyway, I'll add a :title to the channel-info spec.

9:57:40 Colleen <SAL9000__> >2 people + title unset gets a bit silly though, maybe server could autogenerate a 'human' name?

10:00:05 Colleen <SAL9000__> I'm thinking of those "show your private key as a sequence of words" things, but that shouldn't be in the spec :)

10:00:11 Colleen <SAL9000__> (non-normative recommendation, maybe)

10:00:47 Colleen <shinmera> okey, added the title field

10:00:53 Colleen <shinmera> also updated the edit spec to allow deletions

10:00:58 Colleen <shinmera> (by editing with an empty text)

10:01:14 Colleen <SAL9000__> that feels a bit weird, what happens if a "deleted" message is edited back to non-empty text? error?

10:01:24 Colleen <shinmera> it's *marked* as deleted

10:01:30 Colleen <shinmera> the client can just hide it

10:01:35 Colleen <shinmera> or show a 'deleted' notice

10:01:43 Colleen <SAL9000__> I mean does it stay deleted?

10:01:50 Colleen <shinmera> no

10:01:57 Colleen <SAL9000__> non-empty -> empty -> non-empty, does that cause un-deletion?

10:02:04 Colleen <shinmera> yes

10:02:07 Colleen <SAL9000__> hm

10:02:24 Colleen <shinmera> lichat doesn't have any actual editing, all the history is append-only.

10:05:08 Colleen <shinmera> jeez, looking through the spec, when did I have time for all this garbage

10:05:15 Colleen <shinmera> Well, i guess writing a spec is easy

10:10:52 Colleen <SAL9000__> I assume anon channels get automatically cleaned up when all participants leave/disconnect?

10:11:03 Colleen <shinmera> yes

10:11:11 Colleen <shinmera> since there's no way to join it again

10:12:03 Colleen <SAL9000__> right

10:25:19 SAL9000 *reloads lichat* boom, segfault

10:26:17 Colleen <shinmera> oof.

10:30:14 SAL9000 007 ??:? [function weechat_python_api_nicklist_remove_all]

10:30:21 SAL9000 I guess weelichat passed a bad pointer

10:31:55 SAL9000 huh, I can't destroy a channel I just created?

10:32:10 SAL9000 /lichat create nil -> oops, makes a channel called "nil" :p

10:32:36 Colleen <shinmera> you mean the server rejects the command, or?

10:32:46 SAL9000 permission denied

10:32:56 Colleen <shinmera> I guess default perms aren't right

10:33:16 Colleen <SAL9000__> and "@foo" was not auto cleaned up either ("this channel name is taken")

10:33:33 Colleen <SAL9000__> trying to fix the /close recreates bug

10:34:12 Colleen <shinmera> you can't create an anonymous channel with a manual name

10:34:20 Colleen <shinmera> it'll just be a default channel with an @ prefix.

10:35:00 Colleen <SAL9000__> right. that's a bit of a problem for clients & users though...

10:35:13 Colleen <SAL9000__> how do I identify an anon channel other than by the @ prefix?

10:37:35 Colleen <shinmera> the server is meant to reject you creating an @-prefixed channel

10:37:41 Colleen <shinmera> but obviously fails to do so

10:38:27 Colleen <SAL9000__> ah

10:39:38 Colleen <shinmera> Pushed fixes for both to the server (though they are not live yet as I still have not figured out how to hot-upgrade)

10:40:40 Colleen <shinmera> also you may want to check whether the /grant and /deny commands in weelichat work

10:40:46 Colleen <shinmera> I seem to remember them not :u

10:41:39 Colleen <SAL9000__> currently fighting with /close bs

10:51:07 Colleen <SAL9000__> shinmera: I think I've fixed at least the self-inflicted /close recreating buffers :-)

10:51:14 Colleen <shinmera> nice!

10:51:32 Colleen <shinmera> I did look at that myself forever ago and coludn't get it done

10:52:21 Colleen <SAL9000__> the key point is that close_cb seems to be run *after* the buffer is already closed

10:52:41 Colleen <SAL9000__> so approaches based around deferring the actual close don't work, we have to swallow or redirect updates

10:53:15 Colleen <SAL9000__> currently I only swallow responses to the leave update -- so other updates coming in could still recreate the buffer, which may or may not be a good thing

10:53:38 Colleen <SAL9000__> tbh with all the backfill stuff involved too this needs real state machines lol

10:54:03 Colleen <shinmera> yeah....

10:54:05 Colleen <SAL9000__> also, my testing with anon channels quickly ran into update throttling. we either need to raise that threshold or make the client a bit more polite

10:54:12 Colleen <shinmera> might be good to have that as part of the spec, too

10:54:40 Colleen <SAL9000__> half the pain of backfill is from weechat not permitting retroactive insertion

10:54:55 Colleen <shinmera> yeah the throttling is a bit... I think I need to distinguish between different types of updates on the server?

10:55:10 Colleen <shinmera> like, have more lenient limits for queries, and stricter for updates/posts

10:55:37 Colleen <SAL9000__> two axes: "visible to other people" or not, "expensive" or not

10:55:51 Colleen <SAL9000__> if it's not visible it doesn't create spam problems, if it's cheap to process it doesn't create denial of service

10:56:14 Colleen <SAL9000__> e.g. uploading emoji is "expensive" because the input can be large, even though it's not visible to other users directly

10:56:56 Colleen <shinmera> I think it's fine to just distinguish between updates that just return info (backfill, channel-info, etc.) and updates that change state (create, destroy, pull, message, etc)

10:57:15 Colleen <SAL9000__> that would help a lot already, yes

10:58:28 Colleen <shinmera> but back to the other point, having a general state flow diagram for a client's lifetime would be useful in general

10:58:36 Colleen <shinmera> I know scymtym did something like that for his client

11:09:16 Colleen <SAL9000_> did I break non-pm hotlist? sigh

11:17:23 Colleen <SAL9000__> shinmera: any particular reason for using " " (two spaces) as autojoin delimiter?

11:18:35 Colleen <shinmera> channels can contain spaces

11:18:43 Colleen <shinmera> but not two consecutive spaces

11:19:02 Colleen <SAL9000__> I guess they can contain commas and such too?

11:19:05 Colleen <shinmera> yep.

11:19:43 Colleen <shinmera> Colleen: look up lichat-protocol 2.2.1

11:19:43 Colleen <Colleen> Unknown archive "lichat-protocol".

11:19:43 Colleen <Colleen> Unknown archive "lichat-protocol".

11:19:46 Colleen <shinmera> :I

11:19:48 Colleen <SAL9000__> hm. tempted to go for shell-quoting instead to match convention but eh

11:20:55 Colleen <shinmera> https://github.com/Shirakumo/lichat-protocol/blob/master/spec/lichat.mess#L91

11:21:53 Colleen <shinmera> also the hotbar number thing is still present for me

11:22:12 Colleen <shinmera> like, I just navigated away from this channel and it then had 17 messages in the hotbar for me

11:22:48 Colleen <SAL9000__> I think there's a Fun Interaction between us setting 'notify' property & the weechat settings

11:22:57 Colleen <SAL9000__> check /fset notify.python

11:23:40 Colleen <shinmera> what am I meant to check

11:23:52 Colleen <SAL9000__> what is the notify value set for shirakumo?

11:24:00 Colleen <shinmera> highlight

11:24:35 Colleen <SAL9000__> ...oh right, we used to use hardcoded values 2/1 where we should have used constants, constants happen to be 1/0 respectively

11:25:09 Colleen <SAL9000__> so all our hotlist entries were 1 tick "hotter" than they should have been, so we dialed down the notify-level to "compensate"

11:25:13 Colleen <SAL9000__> whoops :D

11:25:51 Colleen <shinmera> whoops indeed

11:30:31 Colleen <SAL9000__> shinmera: pushed. when you update, make sure to reset the notify values in config so they go back to defaults again

11:30:43 Colleen <shinmera> thanks, will give it a try in a bit

11:31:20 Colleen <SAL9000__> nb: might be some edge cases where messages aren't high enough priority since I'm treating everything kind != "text" as a network-message

11:31:29 Colleen <SAL9000__> (= low hotlist)

11:37:52 Colleen <shinmera> thinking about the icons

11:38:05 Colleen <shinmera> and emotes, I guess

11:38:35 Colleen <shinmera> would it be worth it to allow the server to send URLs instead of base64 payloads?

11:38:54 Colleen <shinmera> for some clients it would force having an http client

11:39:10 Colleen <shinmera> but for others it would ease caching

11:39:38 Colleen <shinmera> and for at least weelichat it would let us present an URL instead of just a blob that the user has no context for

11:40:03 Colleen <shinmera> I mean, yes, ideally sixel and other silly business

11:40:11 Colleen <shinmera> but uh, probably not a great idea

12:00:18 Colleen <SAL9000__> aaaaa of course it's not enough to set notify_private and hotlist, you ALSO have to set buffer local var 'type' to private

12:00:34 Colleen <SAL9000__> and I bet that breaks other stuff that assumes private == 2 participants

12:37:44 Colleen <SAL9000__> shinmera: any ideas for how to disambiguate "dm with 'user'" vs "channel called 'user'" in the weechat buffer names?

12:38:08 Colleen <shinmera> Add a prefix like "DM> "

12:39:05 Colleen <SAL9000__> Hm. That's a valid user/channel name.

12:39:18 Colleen <SAL9000__> " user" isn't, though, because no prefix/suffix spaces

12:39:20 Colleen <shinmera> yea sure but it's just the buffer list

12:47:25 Colleen <SAL9000__> I've got all the bits for that cooperating, I think. The catch is that buffer name -- which affects logging, among other things -- is still @Stuff...

12:47:37 Colleen <shinmera> I think that's fine?

12:47:56 Colleen <SAL9000__> if we DM each other in two separate sessions they end up in two logfiles, which is "surprising"

12:48:33 Colleen <shinmera> Hmm.

12:50:30 Colleen <SAL9000__> ...oh ugh. logger defaults set case folding on -- all log file names are lowercase

12:50:38 Colleen <SAL9000__> I'm guessing that lichat channel names are case sensitive

12:50:52 Colleen <shinmera> no

12:50:59 Colleen <shinmera> all names are case insensitive

12:51:12 Colleen <shinmera> because of security

12:51:26 Colleen <SAL9000__> feels a bit weird that the autogenerated channel names have a mix of cases, then

12:51:40 Colleen <shinmera> it's just a generic random string generator

12:51:42 Colleen <shinmera> but sure

12:53:56 Colleen <SAL9000__> yeah not seeing a nice way to redirect @foo logs based on interlocutor name :\

12:55:37 Colleen <SAL9000__> I guess anon channels are a problem for logging in general

12:56:30 Colleen <shinmera> yes

12:56:39 Colleen <shinmera> especially if the names can change

12:56:40 Colleen <SAL9000__> oh wow, looks like I can /buffer set name & it actually survives?!

12:56:57 Colleen <SAL9000__> and the logger switches destinations

12:57:02 Colleen <shinmera> huh

13:07:18 Colleen <SAL9000__> shinmera: same disambiguation problem comes up in regards to buffer name (= log file name)

13:07:41 Colleen <shinmera> sure

13:07:55 Colleen <SAL9000__> filenames with ' ' inside are yuck

13:08:03 Colleen <shinmera> As always when you can't namespace, name collisions are an inevitable security issue

13:08:08 Colleen <shinmera> for now I think: don't worry about it

13:08:11 Colleen <shinmera> is the right way to go

13:09:32 Colleen <SAL9000__> if we're OK with a breaking change to buffer names, can do c.channel and u.user or something

13:09:53 Colleen <shinmera> I don't understand what you're suggesting?

13:10:04 Colleen <SAL9000__> buffer short_name is shown in the UI, that can collide all we want

13:10:11 Colleen <SAL9000__> buffer name must not collide or shit will break badly

13:10:42 Colleen <shinmera> right

13:10:44 Colleen <SAL9000__> currently, buffer name is lichat.tynet.shirakumo and lichat.tynet.shinmera for channels/dms respectively

13:11:00 Colleen <shinmera> I see

13:11:00 Colleen <SAL9000__> suggestion is something like lichat.tynet.c.shirakumo and lichat.tynet.u.shinmera respectively

13:11:10 Colleen <shinmera> what happens for the multi-user-dms?

13:11:20 Colleen <shinmera> do they just get the anon channel name?

13:11:23 Colleen <SAL9000__> current design means they transform back to .c.@foobar

13:11:26 Colleen <shinmera> ok

13:11:39 Colleen <shinmera> yeah that change is fine by me

13:11:46 Colleen <SAL9000__> logs involving lots of transitions across that boundary might get... interesting...

13:11:55 Colleen <shinmera> don't worry about it

13:11:57 Colleen <SAL9000__> i.e. if the 3rd person leaves, it switches back to dm mode

13:12:04 Colleen <shinmera> I wouldn't do that

13:12:16 Colleen <SAL9000__> then we need to store multiparty-dm state serverside

13:12:41 Colleen <SAL9000__> client can't tell that it has (re)joined a dm that was multiparty and it should use channel mode

13:13:00 Colleen <shinmera> hrmmm

13:13:20 Colleen <shinmera> could do that with the title, I guess?

13:13:25 Colleen <SAL9000__> yeah easy answer is that multiparty dms get a non-empty channel title

13:13:35 Colleen <shinmera> my issue especially with merging back is that if you have a dm channel with someone already, then that'll merge badly

13:13:40 Colleen <shinmera> right

13:13:53 Colleen <shinmera> the only issue is that the client that made the channel must ensure this

13:13:57 Colleen <SAL9000__> ...oh god you're right, nothing preventing multiple /q with the same person, just makes two anon channels

13:13:59 Colleen <SAL9000__> aaaaaaaaaaaaaaaaa

13:14:10 Colleen <shinmera> well, I wasn't thinking of that

13:14:14 Colleen <shinmera> more that you /q someone

13:14:19 Colleen <SAL9000__> "if you have a dm channel with someone already"

13:14:21 Colleen <shinmera> then you make an anon channel for, say, group gamin'

13:14:25 Colleen <shinmera> and then you pull in some folks

13:14:34 Colleen <shinmera> and then they leave safe for the dude you have a dm channel with already

13:14:38 Colleen <SAL9000__> then they leave, transmuting back to a dm... yeah

13:14:44 Colleen <shinmera> so that's no bueno

13:14:48 Colleen <SAL9000__> at which point weelichat go kaboom because collisions woooo

13:14:57 Colleen <shinmera> once a channel has more than two, it *has* to be permanently tainted

13:15:04 Colleen <SAL9000__> but does that have to stick serverside?

13:15:26 Colleen <shinmera> yyyyes because if you're the one being pulled in, then weelichat needs to know

13:15:45 Colleen <shinmera> whether to give it the unique DM name or not

13:16:04 Colleen <SAL9000__> tbh even if we ignore multiparty we have a simpler failure case - two anon channels with the same pair of people

13:16:24 Colleen <shinmera> I mean, yeah, that can happen too.

13:17:32 Colleen <shinmera> this kinda stuff is why I initially suggested only cosmetic alternations

13:17:42 Colleen <shinmera> the logging is... unfortunate

13:17:50 Colleen <SAL9000__> yeah the logging is kind of a big deal

13:17:51 Colleen <shinmera> but uh, I don't know a good solution

13:18:06 Colleen <SAL9000__> guess I'll leave the name shenanigans commented out for now?

13:21:02 Colleen <SAL9000__> the best part is that I can easily see an actual use case for multiple dms so locking it out would be bad

13:21:16 Colleen <SAL9000__> (with the same two parties, I mean)

13:21:26 Colleen <SAL9000__> obvious use is if you're about to set up a group

13:21:59 Colleen <SAL9000__> just confirmed - weelichat in its current incarnation (minus name munging) deals with it just fine

13:22:32 Colleen <shinmera> I'd just set the cosmetic name to something nice for DMs

13:22:39 Colleen <shinmera> but leave the logging internally to the anon name

13:23:00 Colleen <SAL9000__> yeah that's what it's currently set as

13:23:04 Colleen <shinmera> cool, greta!

13:23:05 Colleen <shinmera> *great

13:23:08 Colleen <SAL9000__> I left the code in but commented out + explanation of why

13:23:09 Colleen <shinmera> are you also handling :title?

13:23:29 Colleen <SAL9000__> not yet, haven't pulled in the spec changes for that

13:23:58 Colleen <shinmera> there's no changes to the schema

13:24:41 Colleen <SAL9000__> oh nice

13:24:41 Colleen <shinmera> it's just a recommendation for servers to allow the title key by default

13:25:52 Colleen <SAL9000__> I think currently it just lands as a "channel" topic, admittedly there's a race condition between that and update_multiplicity

13:26:00 Colleen <SAL9000__> (i.e. it doesn't affect the short_name)

13:26:29 Colleen <SAL9000__> durrr, title vs topic, weechat vs lichat terms

13:26:39 Colleen <shinmera> we do have a topic in lichat, too :v

13:26:44 Colleen <SAL9000__> yeah I got a bit mixed up :D

13:34:47 Colleen <SAL9000__> shinmera: implemented, but kinda hard to test it w/o server changes :p

13:34:53 Colleen <shinmera> yea I know

13:34:59 Colleen <shinmera> It's in the server, in theory

13:35:13 Colleen <shinmera> again, wish I could find literally anything that explained how to do hot upgrades

13:35:27 Colleen <shinmera> every time I've tried I've only found "lol read erlang docs" as if that fucking explained anything

13:35:35 Colleen <shinmera> or "don't do it", the classic internet wise guy advice

13:35:58 Colleen <shinmera> but then whenever you read about erlang/elixir in other contexts, hot reload gets touted as a hot cool feature

13:36:35 Colleen <shinmera> I *may* just be slightly annoyed about this situation

13:37:37 Colleen <SAL9000__> understandable

13:39:13 Colleen <SAL9000__> pushed

13:40:18 SAL9000 don't pull, I broke sth :(

13:41:12 Colleen <SAL9000__> fixed my goof

13:49:23 Colleen <SAL9000__> shinmera: regarding base64 & urls - could have the server optionally send urls alongside the base64? then the clients get to choose how to render

13:50:06 Colleen <shinmera> I guess, though it's also kinda dirty :v

13:50:16 Colleen <shinmera> especially because we're now not saving on the bandwidth of transmitting it

14:02:09 Colleen <SAL9000__> well the less dirty thing is e.g. weelichat runs a localhost httpd and transforms the base64 into a (shortened) url

14:02:23 Colleen <SAL9000__> or sixel, but that's cursed :p

14:02:27 Colleen <shinmera> that won't work for stuff (like me) where I'm going through tmux

14:02:34 Colleen <shinmera> or using the phone

14:02:37 Colleen <SAL9000__> true

14:02:44 Colleen <shinmera> it should also relaly be on the server

14:02:50 Colleen <shinmera> so it can be cached and all that

14:03:02 Colleen <shinmera> (and delivered more efficiently than b64 encoded)

14:03:06 Colleen <SAL9000__> you mean sending urls only, no b64?

14:03:22 Colleen <shinmera> No, I want to keep b64 around to support setups where there's no http server at all

14:03:39 Colleen <shinmera> but I *also* want to support setups that can take advantage of the better delivery http can give

14:03:43 Colleen <SAL9000__> ah

14:03:48 Colleen <shinmera> like, the link extension was a really nice solution imo

14:03:56 Colleen <shinmera> it's backwards compatible with the plain data

14:04:10 Colleen <shinmera> and servers that want can provide http fetches instead

14:04:22 Colleen <SAL9000__> makes sense

14:04:55 Colleen <shinmera> I *guess* these days forcing a http client onto a client is really not that egregious

14:05:12 Colleen <shinmera> and for simpler clients being able to throw an URL at the user is probably better than just dropping a b64 blob on the floor

14:05:16 Colleen <SAL9000__> there is a slightly cursed thing we could also do - https://chat.tymoon.eu/b64#blargh renders to a js page which decodes the suffix as b64 png

14:05:35 Colleen <shinmera> what would that solve?

14:05:41 Colleen <SAL9000__> advertise this to clients in some way, then they can replace the b64 blob with a link

14:05:51 Colleen <SAL9000__> a long link, admittedly, but still

14:06:04 Colleen <shinmera> it would exceed max link length easily

14:06:21 Colleen <shinmera> and again would not solve the b64 transmission inefficiency

14:06:32 Colleen <SAL9000__> yes

14:07:05 Colleen <SAL9000__> js page can be fully cached tho, reducing (http) load on the server

14:07:31 Colleen <shinmera> I think what I'm going to do is change the icon extension to allow sending either an http/s url or a base64:<payload>

14:08:15 Colleen <SAL9000__> no gopher:// ? :-)

14:08:26 Colleen <shinmera> lord I don't care, some url

14:08:29 Colleen <shinmera> or maybe... hold on

14:08:53 Colleen <SAL9000__> restricting the schemas keeps the clients saner

14:09:00 Colleen <shinmera> we can keep it compatible (sorta) if the value field stays the same, but an extra field is added to denote whether the value is b64 or url.

14:09:34 Colleen <shinmera> could then add a client extension cap that the server can track for whether it should send b64 or urls, too.

14:09:58 Colleen <shinmera> that seems neat?

14:10:34 Colleen <SAL9000__> remind me, was there a reason weelichat bothers to request emoji? some trick with glowing-bear?

14:10:46 Colleen <shinmera> tab completion

14:10:59 Colleen <SAL9000__> ...true

14:11:13 Colleen <SAL9000__> not sure if we can hook it up to do inline emotes but it does work for /react

14:11:16 Colleen <shinmera> and we thought about sixel for a bit

14:11:34 Colleen <shinmera> well, in the least we could add a command to look up an emote

14:11:46 Colleen <SAL9000__> yes

14:13:20 Colleen <shinmera> could also add a buffer that renders all available emotes with something that isn't sixels :p

14:15:15 Colleen <shinmera> on that note, sure wish alacritty had sixel support

14:16:50 Colleen <SAL9000__> shinmera: just did some grepping in #weechat, found this https://toxicfrog.github.io/osc-wrapper/

14:17:27 Colleen <shinmera> ouh

14:27:05 Colleen <shinmera> mh, a bit too much fiddling for me

14:27:13 Colleen <shinmera> plus I'm in a graphical setup anyway, so clicking links isn't a problem