IRC channel logs

<cow_2001>is there (or is there a plan for) a way to maybe turn off some optimisations in hoot so that compilation is faster during development?

<ArneBab_>cow_2001: a practical way to speed up some parts of development could be to run non-web parts in Guile (e.g. with srfi-64 testsuite) and only switch back to web after it works in Guile.

<dthompson>cow_2001: we have the -O flag for controlling optimization level

<dthompson>however, optimizations aren't really the biggest factor.

<dthompson>there's just simply a lot more code to deal with when doing whole-program compilation

<dthompson>the biggest improvement to dev productivity will be having a real repl so you don't have to recompile all the time

<dthompson>this is something I am going to start working on in earnest next week

<dthompson>btw folks, new blog post imminent!

<dthompson>okay, it's published!

<dthompson> https://spritely.institute/news/composing-capability-security-with-conflict-free-replicated-data-types.html

<dthompson>this one is all about composing CRDTs with capabilities to create a local-first chat prototype

<dthompson>oops, ignore that link. need to change the URL.

<dthompson> https://spritely.institute/news/composing-capability-security-and-conflict-free-replicated-data-types.html

<dthompson>there we go :)

<dthompson>I think this is the first time the spritely blog has covered CRDTs. hope folks find it interesting :)

<jboy>nice work dthompson!

<dthompson>thanks jboy :)

<jfred>oh this is so cool

<ridley>I especially appreciated the side-by-side-by-side interactive example

<ridley>Though I did only seem to get it to work on Firefox

<ArneBab_>dthompson: nice!

<ArneBab_>CRDTs are great -- the guarantee that when you only use these you won’t need to coordinate (with the most challenging part: knowing when you *do* need coordination)

<dthompson>ridley: I'd be curious to know the issues in other browsers. I tested on firefox, chrome, and safari.

<dthompson>spent awhile getting things to look decent in safari/webkit, too.

<dthompson>but alas, no amount of browser testing can defeat someone else's machine

<dthompson>jfred, ArneBab_, ridley: glad you all enjoyed the post :)

<kestrelwx>dthompson: I get illegal cast in Guix's QtWebEngine for the topmost demo.

<kestrelwx>It's based on Chromium 130.

<dthompson>kestrelwx: strange

<kestrelwx>And I see `No such method (fulfill)`, but it seems to work in Librewolf.

<dthompson>there are some expected error messages

<dthompson>that fulfill method error is a promise that is being resolved twice... which is expected but we're missing a way to suppress it currently

<dthompson>there will also be errors in the console when peers are disconnected due to connections failing

<dthompson>I have chrome 141 and it works

<kestrelwx>Probably just that it's old.

<dthompson>130 is pretty old but should be new enough for hoot. not sure what's going on there.

<jfred>This is definitely a post I'm going to be returning to later to try and understand it in more detail

<dthompson>the illegal cast means something crashed in the hoot runtime, so the binary itself was valid for that version of v8 to run, as expected.

<dthompson>jfred: :)

<dthompson>I know the post gets a bit dense in the middle

<dthompson>happy to chat about anything that was confusing/underspecified/glossed over

<sem>Hello, can I talk here? I just saw this blog post on Mastodon and I'm excited to try it out whatever it is!

<sem> https://social.coop/@spritely/115605346709107750

<dthompson>hi sem

<dthompson>yes of course :)

<sem>Ah this is your post, cool!

<dthompson>it's just a prototype but I hope it sparks some interesting conversation

<kestrelwx>Works fine in Chromium 140.

<sem>It works in Iron Fox on Android.

<sem>One thing I'm curious about is if Bob disconnects and sends message zero and Alice and Carol are talking back and forth with messages A through Z. When Bob reconnects his offline message zero will automatically insert in the timeline before A-Z, which doesn't seem ideal. This is the single only thing that I can think of that is potentially not optimized. Everything else about this blog post and this web app is absolutely amazing. I had no idea how fun it would b

<sem>to text back and forth between myself and toggle connections on and off.

<dthompson>sem: I don't know how to implement a different behavior for that scenario that would be deterministic

<dthompson>I think many things become UI issues. you need a way to signal to the user that you just synced a message from Bob that's further back in the chat log, etc.

<sem>I am not a programmer, but could Bob's client realize that since it's not connected to the chatroom owner, Alice, it should save its outgoing messages in a queue, and then when it reconnects to Alice it will send them with a now connected message. And then a timestamp when the message is actually sent? Yes, this could be all UI. Maybe the one thing the chat protocol should do is indicate whether Bob's message made it to Alice at that time or whether it was

<sem>offline at that time. ?

<sem>The technical background of this is somewhat beyond my current comprehension, but I think it is really cool.

<kestrelwx>Alice and Carol's clients could probably have the negotiated message displayed prominently until being read perhaps.

<kestrelwx>I said perhaps and probably to be double unsure...

<dthompson>sem: if bob was completely isolated then you could do something like that. once you commit to the crdt, though, it's a done deal

<kestrelwx>I think in Jami it also just silently puts the message where it'd be on timeline, provided the chats don't end up forever desynced in the first place...

<dthompson>sem: glad you liked the post :)

<sem>So cool!

<dthompson>:)

<jfred>dthompson: Agreed that many things become UI issues. Matrix has the same issue re: conversation forks, and historically has not handled them particularly well; the servers are aware of the causal chain of events, but the clients see newly-synced messages either backfilled into the timeline or splatted onto the end of the timeline

<jfred>It occurred to me that threaded messaging a la email or reddit might be more conducive to CRDT syncing, since the reply chain is explicit in the UI in those cases

<jfred>vs. chat where you're trying to linearize the messages received into a chronological timeline

<ridley>dthompson hmm, could be that I have out-of-date browsers

<ridley>Updated chrome and it works there now

<ridley>(I don't really use it much so it was on like 119

<ridley>On Safari after I hit "Start demo" I just get a screen filled with the background colour

<dthompson>ridley: that would do it :)

<dthompson>ridley: are you on safari 26?

<ridley>Do you happen to know what the oldest version of Safari that works is

<dthompson>26

<ridley>oh yeah that's it then

<dthompson>of all the major browsers, safari requires the freshest

<dthompson>they only recently shipped a bug fix that we needed

<dthompson>their wasm tail call validation was broken

<ridley>Okay well all taken care of then

<dthompson>cool :)

<ridley>Might be worth including a note somewhere so people know it's not your stuff that is broken

<ridley>Assuming I'm not the only one slow to update stuff

<dthompson>yeah I usually do but didn't this time because all the browsers support our stuff now

<dthompson>but I guess it's still too early for that

<dthompson>jfred: yeah I guess I'm okay with some seemingly odd behavior like that given the advantages of not having a central hub

<dthompson>I agree that threaded chat would probably have fewer issues generally

<dthompson>though the same issues would apply to concurrent replies to the same thread

<jfred>That's true, though I think it has less potential for confusion given that the chain of replies is visible. We're already used to concurrent replies being reordered via e.g. voting mechanisms on reddit/HN/etc

<jfred>Though now that I think about it, Facebook is a cautionary tale where the UI of supporting both top-level comments and replies to individual comments can be confusing

<av0n>with briar I was interested a while back in pursuing a zulip-like structure for the group chats (https://github.com/willow446/briar-desktop-ui-concept), as briar more deliberately had to design for the offline case where it could be days/weeks between syncs.

<av0n>other ideas include going a more bbs route and having a "live" ephemeral chat + the zulip-like "forum" within the same community.

<av0n>maybe with a way of easily converting an ephemeral message into a forum thread in the UI

IRC channel logs

2025-11-24.log