IRC channel logs

2026-08-21.log

back to list of logs

<trannus_aran_>Is it okay if I bounce some ideas off here re: goblins persistent storage? I figure it's at least „spritely adjacent” in nature, but I'll gladly take it somewhere more appropriate if need be
<stdh>trannus_aran_: i know nearly nothing about goblin's persistent storage, but i'd think this would be the best place to bounce ideas around. the Spritely folks are very much interested how and where their tech is used, and what could be improved wrt. usability
<trannus_aran>stdh: okay, good to hear! Lemme see here
<trannus_aran>(I have a persistent IRC running, so if people respond to this later, I'll still see it)
<trannus_aran>So, for the case of a forum, I'm trying to get a handle on what actors for sure need to be there and the cap(abilitie)s they have, respectively
<trannus_aran>And crucially, the content of any particular thread is content-addressed (similar to torrents, though using something different and better suited for this, ERIS)
<trannus_aran>Conceptually it's simple enough to assume that there's some content addressed blocks on some store on the network somewhere that results in a URN for each new comment in the thread and all previous ones
<trannus_aran>URN:foo shows comment 1, URN:bar shows comment 1 & 2
<trannus_aran>But end users shouldn't have to deal with generating the new URN and somehow communicating that to all other commenters/lurkers
<trannus_aran>So it sounds like some sort of state-holding "Head" or "Current" actor should exist that can manage that
<trannus_aran>An actor that can take new content submitted for a post, generate the updated URN, and then point to that
<trannus_aran>So from a user perspective, they'd only have to communicate with that one actor, right? But then that actor has to exist somewhere on the network in a *location*-addressed sorta way it feels like
<trannus_aran>Which...I guess it doesn't defeat the purpose (anyone with access to the content on their machine could conceivably have the URN to a snapshot of the thread and THAT will be durable)
<trannus_aran>But it feels like 3 steps forward 2 steps back :/
<trannus_aran>Doesn't brassica chat do some fancy future stuff where there is no central object and the "server" is made up by the connecting clients?
<ridley> trannus_aran brassica chat uses a CRDT for content syncing and certificate capabilities (ZCap IIRC) for permissions
<ridley>I don't know that there's one right format for all forum software and it'd depend on the specific needs
<ridley>I think various trust, safety, and availability requirements could significantly alter the shape
<ridley>Some of the ideas in here may or may not be relevant for what you want to do:
<ridley> https://codeberg.org/spritely/racket-crystal/src/branch/master/crystal/scribblings/intro.org