IRC channel logs

2026-01-23.log

back to list of logs

<jfred>I like the Habitat Chronicles one for sure. I've also definitely found it hard to explain to other engineers in a concise way though
<dthompson>yeah it's difficult
<jfred>I think it probably comes across as really abstract in a way that isn't obviously valuable until you spend a lot of time thinking through the implications
<jfred>or until you see a really compelling example
<dthompson>in fact I'm having a hard time explaining capabilities to my wife
<dthompson>it just looks like passing arguments to things. okay, so where's the magic?
<dthompson>it's almost so obvious that it's hard to see
<jfred>One of the examples that's really stuck with me was the idea of a social network where your existing contacts can contact you immediately, but where "cold-calling" from strangers might go through a spam filter, or require hashcash-like proof-of-work, or something else that you could delegate, etc
<dthompson>yeah delegation is the key thing
<dthompson>it's hard for people to wrap their heads around, though
<jfred>I seem to recall Christine explaining that concept on a podcast episode at one point, I don't recall if it was early FOSS and Crafts or back during Libre Lounge - but that explanation made the value really clear to me at the time. That's something existing social networks/messaging systems tend not to support
<jfred>and I think I've had the most success explaining capabilities using spam/messaging/social networks as the concrete example
<dthompson>good to know!
<ridley>I think you're onto something with using more concrete examples
<ridley>One of the things that seemed to be a bit of a sticking point was trying to explain that distributed objects in this case meant distributed behaviour not distributed state
<ridley>(though one can build distributed state from distributed behaviour as Dave has demonstrated
<ridley>)
<dthompson>ridley: distributed behavior vs distributed data is a MAJOR sticking point
<dthompson>it's the biggest issue we have talking to people from other decentralized/p2p/local-first/etc. projects
<ridley>Yeah I can see that
<dthompson>almost all of them have a data-centric view
<ridley>That is what I have seen as well. I hope to see more blending of the two.
<dthompson>yeah me too
<dthompson>that was what I attempted to do at dweb seminar over the seminar
<dthompson>and what I will try to do at the local-first devroom at fosdem
<ridley>I also found Christine's example of spam/social network stuff helpful in understanding what capabilities could do. One idea I think about often is a capability-based improvement over phone and email where you can revoke access so if someone leaks/sells your contact info you know who did it and can cut off all downstream contact from that breach of
<ridley>trust.
<dthompson>yeah that would be great
<dthompson>I am on the verge of merging a massive hoot PR that adds a REPL that works in the browser
<dthompson> https://codeberg.org/spritely/hoot/pulls/821
<ridley>Very cool, congrats!
<dthompson>plenty of stuff left undone but I can connect to the browser from emacs now and that feels great
<dthompson>new release for a project I maintain personally, but one we use at spritely: https://dthompson.us/posts/guile-websocket-0-3-0-released.html
<dthompson>not officially released yet but I made a new repo for geiser-hoot https://codeberg.org/spritely/geiser-hoot
<dthompson>that's the elisp package for connecting to the hoot repl
<identity>somebody needs to throw together a Hoot nREPL server
<dthompson>would be cool, I don't know anything about nrepl
<identity>actually, there is already an nREPL server for Guile: <https://git.sr.ht/~abcdw/guile-ares-rs>
<dthompson>I'm aware of that project but I don't think it does what I need, at least not right now
<dthompson>but andrew is giving a talk at fosdem so I'll definitely be talking to him about it