hckrnws

How does this model compare to the syndicated actor model of Tony Garnock-Jones?

(which, as far as I can tell, also supports capabilities and caveats for security)

Neat work!

The animation on the Syndicated Actors home page [0] does a pretty good job of showing the difference, I think. Goblins is much more similar to the classic actor model shown at the beginning of the animation. The "syndicated" part, as far as I understand, relates to things like eventually consistent state sync being built-in as primitives. In Goblins, we provide the actor model (actually the vat model [1] like the E language) which can be used to build eventually consistent constructs on top. Recently we prototyped this using multi-user chat as a familiar example. [2]

[0] https://syndicate-lang.org/

[1] https://files.spritely.institute/docs/guile-goblins/0.17.0/T...

[2] https://spritely.institute/news/composing-capability-securit...

Thank you, very helpful!

My 5 minute read is that the divergences are primarily in the communication model and in transactions:

- the SAM coordinates through the dataspace, whereas Goblins is focused on ("point-to-point") message passing

- SAM (as presented) doesn't contain a transactional semantics -- e.g. turns are atomic, and there's no rollback mechanism (I haven't been up to speed on recent work, I do wonder if this could be designed into SAM)

They also have a scheme to webassembly transpiler called Hoot. They do crazy interesting work!

Yeah those interested in Wasm topics might find https://spritely.institute/hoot/ interesting. It's not only a Scheme compiler but a full Wasm toolchain available as a library.

I've been an excited user of Goblins for several years now. So far only outside of $dayjob, which has limited the amount of time I've been able to spend with it, but it's very fun to work with if you like the actor model.

I think my brain naturally wants to think about things in terms of sending messages between smaller components of a program, so Goblins fits the way I think very well. It's also what introduced me to object-capability security, which is a lot more brain-bendy when you're first trying to understand it, but after a lot of reading and playing with Goblins I find myself wishing many more things used ocaps. :)

Spritely develops very interesting, high-level software.

Feels like there's a protocol missing: one that can be used by all parts of a persistent computing system without constraining the system as a whole

The protocol is OCapN

http://ocapn.org/

That's right! We are developing our own stack at Spritely but OCapN is a protocol to be implemented for any and all programming languages so we can have interoperable capability security over the network. Besides our Scheme implementation, there are JavaScript and Dart implementations in active development currently with hopefully many more to follow.

> Could dataspaces be a suitable system layer foundation, perhaps replacing software like systemd and D-Bus?

The animation and this statement with clear practical usage got me interested. Is there active work going on in this area? I'd like to see how that interacts.

Yep! Shepherd × Goblins

https://spritely.institute/news/shepherd-goblins-update.html

https://shepherding.services/

Interesting. I looked through the docs and couldn't find an FAQ or anything that would answer my question of why Spritely decided to develop Goblins. Is there a doc for that? What's its differentiation from something like Erlang, or is it just me missing the point, and comparing apples with bicycles?

We should have a FAQ! We get the Erlang question a lot. In short, Erlang actors are not capabilities because processes can be enumerated in Erlang. Capabilities require that the actors/processes have unforgeable/unguessable private addresses.

Thanks. That was helpful.

I still don't really understand what it's for, despite that it sounds interesting and gets linked here from time to time

but I think the difference is the "distributed" part, where I think they mean distributed over untrusted networks as opposed to distributed over nodes in a private cluster