IRC channel logs

<kestrelwx>Hello! Does anybody see 'module not found (goblins)' with Guix and Hoot? I'll be right back.

<identity>kestrelwx: if you are doing something like guix shell guile-goblins then try guix shell guile guile-goblins instead

<kestrelwx>I have it in a manifest like this. https://paste.debian.net/1404777/

<kestrelwx>I can load it in a Guile repl, but `guild compile-wasm` fails.

<kestrelwx>Okay, it seems to work if I switch from `use-modules` to `import` at the top of my file.

<kestrelwx>Oh, nevermind, still doesn't.

<kestrelwx>I can't remember what I saw that made me think it'd be different.

<kestrelwx>I get this with a source file that is just `(use-modules (goblins))` or any other goblins module, in a `guix shell -Cm manifest.scm --pure` too.

<kestrelwx>``` guild compile-wasm -L`$(guix build guile-goblins)/share/guile/site/3.0` --bundle -o foobar game.scm` ``` works out.

<kestrelwx> Yippee! #<&message message: "Hello from vat!"> But I wonder what's exactly wrong.

<kestrelwx>I'll try a manifest from. https://codeberg.org/spritely/brassica-chat/src/branch/main/manifest.scm

<kestrelwx>This works!

<cwebber>hi!

<cwebber>kestrelwx: yay glad you got it workin'

<kestrelwx>Should we have `goblins-for-hoot` or maybe modify the package itself in Guix?

<kestrelwx>Hello!

<cwebber>hm interesting

<cwebber>well

<cwebber>there's certainly things that could be done to make compiling with libraries easier. I'm not fully sure myself what the right ways to solve them are but I think dthompson has ideas. not my area ;)

<cwebber>but yeah, the experience could certainly be improved. It has gotten better with the last release at least

<cwebber>now you don't need to point at the internal guile module load path anymore

<dthompson>kestrelwx: yeah you'll want to put the sources to the additional libraries you want to use on HOOT_LOAD_PATH or use the -L flag as you've done

<kestrelwx>Hello!

<jboy>here's a shell.nix file for a goblins+hoot dev environment: https://xi.pe/9zpX?h

<jboy>I haven't done much with it but I'm able to compile all the hoot-ffi-demo examples in it

<dthompson>jboy: oh cool, thanks for sharing that!

<jboy>brassica runs as well

<dthompson>oh neat :)

<dthompson>I just started pushing commits for a web ui for that yesterday

<dthompson>you're probably the first person other than me to build it

<jboy>haha, yes, I just played around with it. I had Alice create a room and invite Bob, but I couldn't get Bob into the room.

<jboy>but I have no idea how any of it works in the background, so I didn't troubleshoot anything :)

<dthompson>if you want to actually try it, do this:

<dthompson>"login" as alice first and create a room, as you've done

<dthompson>when creating bob, make sure you use bob's ocapn:// uri as output by the terminal

<dthompson>not sure if that's what you did or not

<dthompson>as in do *not* put the invite uri into the setup form

<dthompson>once bob is in the main chat ui, click "join room" and paste in alice's invite uri

<dthompson>then they should be able to send messages

<dthompson>those ocapn uris that get printed to the terminal are for connecting to the relay so that your browser tabs can communicate through that

<dthompson>though be warned they are currently only usable *once*. I'm hoping to fix that before I wrap up this demo project.

<jboy>ah, that's probably it. I kept retrying over and over.

<jboy>or I was being punished for my heretical vim+nix setup :)

<dthompson>yeah this is a very rough demo that I've been hastily putting together as fast as possible

<dthompson>trying to demonstrate that with goblins we can combine ocaps + zcaps + crdts!

<jboy>oh wow, it worked now! Bob can even see room history.

<dthompson>awesome!

<dthompson>yeah so alice and bob each have their own copy of the chat that they are syncing between each other

<dthompson>functionality is very limited, of course, but it's cool to see it working

<dthompson>there are some things that are invisible currently. alice, as the creator of the chat, has full admin powers in that she can edit/remove any message

<dthompson>bob, as invited by alice, has reduced capabilities that allow him to edit/remove his own messages only

<jboy>amazing. In like 1500 lines of code.

<dthompson>there's a mini-zcap certificate chaining thing going on that the interface currently does not show at all

<dthompson>yeah it's not so bad, code-wise. there are probably ways to golf it down but realistically there are many more lines of code needed to add robustness

<dthompson>it already has some of the most important foundational things, though.

<jfred>I'm gonna have to give brassica-chat a try soon

<jfred>sounds fun

<dthompson>temper your expectations but I hope you have fun :)

<dthompson>consider it like a game jam project. a fast, messy prototype.

<dthompson>but one with a purpose: look, we can do p2p slack/discord with goblins. anyone want to give us money to do it for real? :)

<jfred>The question of "I have this ocapn URI, what can I use it for?" feels like it could become a problem at some point. Maybe something that a combination of an interface API + UI support for exposing interfaces in something like Navi could help with

<jfred>feels like ideally users shouldn't see raw ocapn URIs very often if possible

<jfred>but making that a reality is complicated, haha

<dthompson>they really shouldn't see an ocapn:// uri, it's true

<dthompson>a qr code or something would be better for bootstrapping a new user

<dthompson>and I agree re: what is this capability for?

<dthompson>it's an important question

<dthompson>someone give us some funding to do UX research and implementation! :)

<jfred>QR code definitely, but even if scanning a QR code I think you'll want a way for the user's software to check "is the capability I got from this QR code what I expect it to be?"

<dthompson>given that ocaps are opaque there's really no other way that to send a message

<dthompson>than*

<jfred>That's true - I'm thinking back to cwebber's content addressed interfaces writeup from a few years back

<dthompson>yeah it would be good to have that

<dthompson>if the ocap speaks that protocol you could learn some things

<dthompson>from well-behaved parties

<jfred>ACTION nods

<dthompson>but if Mallet quacks like a duck...

<jfred>right, there's always the trust relationship involved between you and the person you got the capability from haha

<dthompson>yup!

<dthompson>the trust relationships with this p2p chat are verrrrry interesting/complicated

<jfred>IMO exposing interface info like that is more about enabling more clear UX when everyone involved isn't trying to be actively malicious

<dthompson>that chat is like an unum with presences on all peers. a capability to one is a capability to all.

<dthompson>jfred: I agree!

<jfred>And a capability to one presence being effectively a capability to all makes total sense. It's like the capability represents the ability to contact you, independent of the particular device you happen to be using

<jfred>higher level in a sense than a typical network address

<jfred>although I guess if it's a group context it's more a capability to contact everyone in the group

<dthompson>jfred: yeah exactly, it's a capability to send a message to the chat, but without a central, canonical actor that means the messages have to be distributed amongst all peers and some sense needs to be made out of that

<dthompson>capability attenuation cannot be achieved at the ocap level for such an actor, so we layer on certificate capabilities as the set of rules by which we can nterpret the message log.

<dthompson>interpret*

<kestrelwx>Okay, I finally got a little log running up the screen.

<dthompson>kestrelwx: congrats :)

<kestrelwx>dthompson: So for the Goblins package should we have that up in Guix upstream?

<kestrelwx>Maybe a symlink in the Hoot module directory?

<kestrelwx>So that Goblins+Hoot works ootb.

<dthompson>it would be good if the next goblins release adds the symlink on installation so it's not just part of a guix package build

<kestrelwx>Makes sense.

<dthompson>filed an issue about it https://codeberg.org/spritely/goblins/issues/899

<ridley>I don't know if you intend to make one but I would enjoy reading a blog post about this ocap + zcap + crdt combo

<dthompson>ridley: a blog post is planned

<ridley>oh yay!

<ridley>Of the three I've read the least about zcaps and am interested to see how that fills some of the gaps I've been thinking about with just the other two

<dthompson>it's the one I knew the least about, too.

<dthompson>everything I know is from the introduction section here https://w3c-ccg.github.io/zcap-spec/

<ridley>I will have to give it a read

<dthompson>the basics are not that difficult. the json-ld stuff kind of obscures it.

<dthompson>in a nutshell: a zcap is a signed certificate that has some "controllers" (the people who can use the cert; a set of public keys), some "caveats" that attenuate the capability (bob can only buy hot dogs on wednesday), and a "parent" pointer for the cert that the zcap is derived from.

<dthompson>the chain created from this process is verified by checking signatures. the signer of a cert must be a controller of the parent.

<dthompson>brassica chat has a very simple certificate system.

<dthompson>there is a root signer for the room, let's say it's alice.

<dthompson>alice signs a cert for herself to use with no caveats, granting her full privileges.

<dthompson>then alice signs certs for bob and carol with caveats saying that their edit and delete actions are only permitted for their own messages.

<dthompson>for every chat room action, the sender includes a reference to the certificate they are using.

<dthompson>when rendering the chat room we run some checks: is the user associated with this action one of the controllers of this cert? if so, does it satisfy the caveats?

<ridley>do you use zcaps for writing to the room as well as edit and delete?

<dthompson>yes, every action has a zcap associated with it

<dthompson>so you could say things like "bob can't emoji react to carol's messages"

<dthompson>well that's a bad example lol, because it's not a new post

<dthompson>you could have a zcap that says bob cannot post new messages

<dthompson>hopefully that makes some sense

<ridley>does that mean then that if I post, all peers receive a signed message such that even if I later try and delete said message, so long as someone simply chooses to not delete, they will always be able to prove through cryptography that I sent it?

<ridley>basically, does such a system eliminate deniability as an option?

<dthompson>you can't unsend a message, if that's what you mean

<dthompson>leaving zcaps aside, every "commit" written to the crdt is signed

<ridley>Got it

<ridley>I know you can't unsend something due to physics

<dthompson>haha yeah of course :)

<ridley>but systems in which messages are not signed can allow plausible deniability (I didn't say that! They just faked it!)

<dthompson>sure

<ridley>but I don't think you can accomplish the goals you had with this by not signing

<dthompson>yeah I'm struggling to think of how that might be possible...

<ridley>I think as soon as the CRDT comes into place you probably need it. I dunno, I've tried to think my way out of it a few times and it never goes anywhere.

<dthompson>the crdt at the very least needs content addressing to detect "byzantine faults" where Mallet sends Alice and Bob messages with the same id but different contents

<dthompson>and the signing is important because otherwise we can't validate zcaps

<ridley>makes sense

<dthompson>the relationship between ocaps and zcaps here are interesting. an ocap gives you permission to commit and the zcaps interpret those commits to produce the current state

<ridley>and presumably any commits with invalid zcaps are just thrown out

<dthompson>from the perspective of the user, yes. they remain as commits in the crdt.

<dthompson>I didn't mix crdts and zcaps together, so the crdt doesn't know anything about them. commits are basically signed blobs and as long the hash matches and the signature is valid then the commit is valid.

<ridley>I see.

<dthompson>the zcaps encode information that is specific to the application. the crdt is a dumb substrate.

<ridley>In a production system you'd have to be very careful about who gets crdt write permission then, yes?

<ridley>Because an adversary could make every node's crdt just massive

<ridley>if you're using an operation-based crdt at least

<dthompson>yes, Mallet can attempt to DoS you. revokable ocaps allow you to stop that once the activity is discovered.

<ridley>gotta go, thanks for telling me how you put these pieces together

<dthompson>nice chatting with ya ridley!

<kestrelwx>Alright, until tomorrow.

IRC channel logs

2025-11-06.log